ubuntuusers.de

Hallo,

vor einigen Jahren habe ich mit eurer Hilfe hier einen VPN-Server passend konfiguriert, und mit iptabels so eingerichtet, dass bestimmte Rechner immer durch das Tor-Netz nach draußen gehen (https://forum.ubuntuusers.de/topic/frage-zu-iptables-3/3/).

Bisher hat immer alles, was ich benötigt habe, funktioniert. Nun möchte ich einem Freund, der mit mir zusammen ein Programm entwickelt, SSH-Zugriff auf einen Rechner in meinem Netzwerk ermöglichen, damit er seinen Code testen kann. Er kommt in mein Netzwerk, kann den Rechner anpingen, aber das Passwort wird abgelehnt. Unser Verdacht, soweit wir bisher durchsteigen konnten, ist, dass die Verbindungsanfrage mit SSH nie wirklich auf dem gewünschten Rechner ladet. Hier meine iptables:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

root@TestPC:/home/pi# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
REDIRECT   tcp  --  anywhere             anywhere             tcp dpt:ssh redir ports 22
REDIRECT   tcp  --  192.168.178.220      anywhere             redir ports 9040
REDIRECT   udp  --  anywhere             anywhere             udp dpt:domain redir ports 5353
REDIRECT   tcp  --  anywhere             anywhere             tcp dpt:12000 redir ports 9040
REDIRECT   tcp  --  anywhere             anywhere             tcp dpt:46984 redir ports 9040

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  anywhere             anywhere            
MASQUERADE  all  --  anywhere             anywhere 

Für Tips wäre ich sehr dankbar!

Gerdchen03 schrieb:

Unser Verdacht, soweit wir bisher durchsteigen konnten, ist, dass die Verbindungsanfrage mit SSH nie wirklich auf dem gewünschten Rechner ladet.

Das kannst Du auf deinem Rechner (wo sshd aktiv ist) testen, mit z. B. tcpdump (oder gleichwertig):

sudo tcpdump -c 30 -vvveni <Interface> port 22 and host <source-IP-Adresse-Freund>

(Interface und source-IP-Adresse-Freund anpassen und ohne spitze Klammern).

Hallo,

Ich hab es wie folgt probiert: sudo tcpdump -c 30 -vvveni enp2S0 port 22 and host 10.8.1.11

Der Rechner ist mit dem enp2S0 angeschlossen. Die vom VPN zugewiesene Tunnel-IP meines Freundes lautet 10.8.1.11 Die Antwort sieht wie folgt aus: tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

Teste ich die Verbindung von meinem im lokalen Netz befindlichen Rechner mit der IP 192.168.178.20 erhalte ich eine Ausgabe, sobald ich die Verbindung versuche aufzubauen. sudo tcpdump -c 30 -vvveni enp2S0 port 22 and host 192.168.178.20

Auf den Raspberry komme ich übrigens per SSH über den VPN, falls das wichtig wäre.

Dann habe ich noch etwas probiert. Ich habe meinen lokalen Rechner über mein Handy und den VPN ins Heimnetz geleitet. Dieser hat die VPN-IP 10.8.1.15.

sudo tcpdump -c 30 -vvveni eth0 port 22 and host 10.8.1.15 auf dem Raspberry bringt auch keine Ausgabe, obwohl ich mich hier wohlgemerkt verbinden kann.

Gerdchen03 schrieb:

Dann habe ich noch etwas probiert. Ich habe meinen lokalen Rechner über mein Handy und den VPN ins Heimnetz geleitet. Dieser hat die VPN-IP 10.8.1.15.

sudo tcpdump -c 30 -vvveni eth0 port 22 and host 10.8.1.15 auf dem Raspberry bringt auch keine Ausgabe, obwohl ich mich hier wohlgemerkt verbinden kann.

Du solltest tcpdump vor dem herstellen der ssh-Verbindung starten.

BTW: Was ist richtig, enp2S0 oder eth0?

tcpdump wurde jeweils vor dem Versuch die ssh-Verbindung herzustellen, gestartet. eth0 ist das Interface des Raspberry, mit dem ich ebenfalls getestet habe, enp2S0 ist das Interface des Ubuntu-Rechners, auf dem mein Freund letztlich laden soll.

Gerdchen03 schrieb:

tcpdump wurde jeweils vor dem Versuch die ssh-Verbindung herzustellen, gestartet.

Dann poste von deinem PI die Ausgabe von:

sudo netstat -tlpena | grep -i 22

wenn Du per ssh mit deinem PI verbunden bist.

EDIT:

BTW: Wenn Du die IP-Adresse des VPN-Tunnels im Filter von tcpdump benutzt, dann musst Du mit tcpdump auch das Interface des VPN-Tunnels benutzen (statt eth0).

BTW: Wenn Du die IP-Adresse des VPN-Tunnels im Filter von tcpdump benutzt, dann musst Du mit tcpdump auch das Interface des VPN-Tunnels benutzen (statt eth0).

Das war natürlich dämlich, sorry. Jetzt klappt es auch mit der Ausgabe. Das andere teste ich nachher.

root@Raspberry:/home/pi# netstat -tlpena | grep -i 22
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          8741        778/sshd        
tcp        0      0 192.168.178.4:22        192.168.178.20:49979    ESTABLISHED 0          234734      18038/sshd: pi [pri
tcp        0      0 10.8.1.5:22             10.8.1.7:58917          ESTABLISHED 0          236830      18742/sshd: pi [pri
tcp6       0      0 :::22                   :::*                    LISTEN      0          8748        778/sshd

Gerdchen03 schrieb:

root@Raspberry:/home/pi# netstat -tlpena | grep -i 22
tcp        0      0 10.8.1.5:22             10.8.1.7:58917          ESTABLISHED 0          236830      18742/sshd: pi [pri

Kann dein Freund im VPN, mit ssh auf deinen Rechner zugreifen?

Sorry, die Frage versteh ich nicht 😉 Er kann sich ja eben gerade nicht per ssh mit dem Rechner verbinden

Gerdchen03 schrieb:

Er kann sich ja eben gerade nicht per ssh mit dem Rechner verbinden

Kann dein Freund, im VPN den Port 22 scannen? Z. B.:

nc -zv 10.8.1.5 22

oder

sudo nmap -sS 10.8.1.5 -p22

oder gleichwertig (... abhängig vom OS das dein Freund hat).

Er hat sich mit dem VPN in mein Netzwerk verbunden und kommt per ssh auf den Raspberry. Dann hat er in seinem Terminal nc -zv 10.8.1.5 22 eingegeben.

PC1:~ user$ nc -zv 10.8.1.5 22
Connection to 10.8.1.5 port 22 [tcp/ssh] succeeded!

Ich nehme mal stark an, dass er auf den Raspberry kommt, weil er ja auch eine Tunnel-IP hat (10.8.1.5). Der Rechner, auf den er kommen will hat ja eine lokale IP, wie 192.168.178.12

Gerdchen03 schrieb:

Der Rechner, auf den er kommen will hat ja eine lokale IP, wie 192.168.178.12

OK, und welchen Dienst bzw. welchen Port will er via IP-Adresse 192.168.178.12 (in deinem W/LAN), erreichen? Wie sind auf dem Rechner deines Freundes, wenn er per VPN mit deinem PI verbunden ist, die Ausgaben von:

ip a
route -n

?

Er möchte den 192.168.178.12 auf dem Port 22 erreichen

root@Raspberry:/home/pi# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:6b:6a:cb brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.4/24 brd 192.168.178.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 169.254.7.85/16 brd 169.254.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2a02:6d40:39cb:c400:8f1c:e1af:3001:1bbd/64 scope global noprefixroute dynamic 
       valid_lft 7106sec preferred_lft 3506sec
    inet6 fe80::67d5:7d33:3871:35d3/64 scope link 
       valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether b8:27:eb:3e:3f:9e brd ff:ff:ff:ff:ff:ff
    inet6 fe80::5279:d158:576f:6f75/64 scope link tentative 
       valid_lft forever preferred_lft forever
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none 
    inet 10.8.1.5 peer 10.8.1.4/32 scope global tun0
       valid_lft forever preferred_lft forever
root@Raspberry:/home/pi# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.8.1.4        128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.178.1   0.0.0.0         UG    0      0        0 eth0
10.8.1.0        10.8.1.4        255.255.255.0   UG    0      0        0 tun0
10.8.1.4        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
128.0.0.0       10.8.1.4        128.0.0.0       UG    0      0        0 tun0
134.255.237.208 192.168.178.1   255.255.255.255 UGH   0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     202    0        0 eth0
192.168.178.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0

Gerdchen03 schrieb:

Er möchte den 192.168.178.12 auf dem Port 22 erreichen

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:6b:6a:cb brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.4/24 brd 192.168.178.255 scope global eth0
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none 
    inet 10.8.1.5 peer 10.8.1.4/32 scope global tun0
       valid_lft forever preferred_lft forever

root@Raspberry:/home/pi# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.8.1.4        128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.178.1   0.0.0.0         UG    0      0        0 eth0
10.8.1.0        10.8.1.4        255.255.255.0   UG    0      0        0 tun0
10.8.1.4        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
128.0.0.0       10.8.1.4        128.0.0.0       UG    0      0        0 tun0
134.255.237.208 192.168.178.1   255.255.255.255 UGH   0      0        0 eth0
192.168.178.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0

Das (W)LAN-Subnetz bei dir und deinem Freund sind identisch (.178). Wenn er kein Gerät mit der IP .12 in seinem WLAN hat, dann soll er mal als test, versuchen mit:

sudo route add -host 192.168.178.12 gw 10.8.1.5 dev tun0
nc -zv 192.168.178.12 22