ubuntuusers.de

Hi,

habe einen Ubuntu Server zuhause, der über openvpn mit einem VPN Betreiber verbunden ist.

Zusätzlich habe ich 2 Netzwerke via Fritzbox LAN to LAN gekoppelt - quasi Eltern mit mir. Ich kann also in meinem Netzwerk 192.168.0.1/24 alle Geräte im entfernten Netzwerk 192.168.178.0/24 steuern und auch umgekehrt. Nur das mit dem Server der ja direkt neben mir steht macht ein Problem:

Ich komme via ssh aus meinem Netzwerk via putty also ssh drauf und auch interne connects zu Anwendungen auf diesem PC funktionieren ohne Probleme über die interne IP. Das "entfernte" Netzwerk kann dies nicht mit einer internen IP - nur über das VPN.

Kann man das so einrichten, da das entfernte Gerät ja quasi auch ein INTERNES Gerät ist, nicht den Umweg über die VPN Adresse nehmen muss? Sonst würden meine Eltern ja quasi über Timbuktu connecten müssen, obwohl sie sich doch in meinem lokalen Netzwerk befinden.

Das ist halt der Nachteil von IPv4 mit privaten Adressen. Diese sind nicht eindeutig.

ip route

skatehouse schrieb:

Ich kann also in meinem Netzwerk 192.168.0.1/24 alle Geräte im entfernten Netzwerk 192.168.178.0/24 steuern und auch umgekehrt.

Das "entfernte" Netzwerk kann dies nicht mit einer internen IP - ...

Dann hast Du den sshd und den Server, nicht richtig konfiguriert.

Starte auf dem Server tcpdump mit dem geeigneten Filter und mach aus dem entfernten Netzwerk, einen TCP-Portscan auf die interne IP vom Server und den lauschenden Port des sshd.

pi@ubuntu2:~$ ip route
0.0.0.0/1 via xx.xxx.81.5 dev tun0
default via 192.168.0.1 dev ens18 proto dhcp src 192.168.0.96 metric 100
xx.xxx.81.1 via xx.xxx.81.5 dev tun0
xx.xxx.81.5 dev tun0 proto kernel scope link src xx.xxx.81.6
xx.xx.225.81 via 192.168.0.1 dev ens18
128.0.0.0/1 via xx.xxx.81.5 dev tun0
192.168.0.0/24 dev ens18 proto kernel scope link src 192.168.0.96 metric 100
192.168.0.1 dev ens18 proto dhcp scope link src 192.168.0.96 metric 100

lubux schrieb:

skatehouse schrieb:

Ich kann also in meinem Netzwerk 192.168.0.1/24 alle Geräte im entfernten Netzwerk 192.168.178.0/24 steuern und auch umgekehrt.

Das "entfernte" Netzwerk kann dies nicht mit einer internen IP - ...

Dann hast Du den sshd und den Server, nicht richtig konfiguriert.

Starte auf dem Server tcpdump mit dem geeigneten Filter und mach aus dem entfernten Netzwerk, einen TCP-Portscan auf die interne IP vom Server und den lauschenden Port des sshd.

😢 Das übersteigt mein Verständnis gerade ☺

skatehouse schrieb:

pi@ubuntu2:~$ ip route
0.0.0.0/1 via xx.xxx.81.5 dev tun0
default via 192.168.0.1 dev ens18 proto dhcp src 192.168.0.96 metric 100
...
192.168.0.0/24 dev ens18 proto kernel scope link src 192.168.0.96 metric 100
192.168.0.1 dev ens18 proto dhcp scope link src 192.168.0.96 metric 100

Wiw sind auf dem PI (Server?) die Ausgaben von:

sudo iptables -nvx -L -t nat
sudo netstat -tlpena | grep -i ssh
ps aux | grep -i [s]sh

?

skatehouse schrieb:

😢 Das übersteigt mein Verständnis gerade ☺

Naja, ... wer zuhause einen Server betreiben kann, OpenVPN installieren/konfigurieren bzw. mit einem VPN-Provider benutzen kann, sollte m. E. auch in der lage sein, tcpdump zu benutzen bzw. einen Portscan zu machen, oder?

lubux schrieb:

skatehouse schrieb:

pi@ubuntu2:~$ ip route
0.0.0.0/1 via xx.xxx.81.5 dev tun0
default via 192.168.0.1 dev ens18 proto dhcp src 192.168.0.96 metric 100
...
192.168.0.0/24 dev ens18 proto kernel scope link src 192.168.0.96 metric 100
192.168.0.1 dev ens18 proto dhcp scope link src 192.168.0.96 metric 100

Wiw sind auf dem PI (Server?) die Ausgaben von:

sudo iptables -nvx -L -t nat
sudo netstat -tlpena | grep -i ssh
ps aux | grep -i [s]sh

?

Ist kein pi..der User heisst nur so ☺

So wie ich das verstehe gehen über iptables ALLE Verbindungen zum VPN Dienst, oder? Warum komme ich dann mit meiner normalen internen IP trotzdem drauf? Rede nicht von ssh...sondern von meinen Anwendungen.

pi@ubuntu2:~$ sudo iptables -nvx -L -t nat
[sudo] password for pi:
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination

tcp        0      0 0.0.0.0:1194            0.0.0.0:*               LISTEN      0          21091      858/sshd: /usr/sbin
tcp        0    144 192.168.0.96:1194       192.168.0.69:64037      ESTABLISHED 0          21438      2052/sshd: pi [priv

pi@ubuntu2:~$ ps aux | grep -i [s]sh
root         858  0.0  0.2  15436  8740 ?        Ss   17:51   0:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
root        2052  0.0  0.2  17184 11076 ?        Ss   17:55   0:00 sshd: pi [priv]
pi          2182  0.0  0.2  17320  8104 ?        S    17:55   0:00 sshd: pi@pts/0

lubux schrieb:

skatehouse schrieb:

😢 Das übersteigt mein Verständnis gerade ☺

Naja, ... wer zuhause einen Server betreiben kann, OpenVPN installieren/konfigurieren bzw. mit einem VPN-Provider benutzen kann, sollte m. E. auch in der lage sein, tcpdump zu benutzen bzw. einen Portscan zu machen, oder?

Ja vermutlich....aber ich muss mir immer alles von irgendwoher zusammensaugen....und wer sich auskennt, der macht das in 2 Min. Ich will es halt nur verstehen können. Hab auch bei der Installation den Standard ssh Port versemmelt...der tront jetzt, wie man sieht, auf 1194....schön, dass es ein anderer ist und bestimmt förderlich - aber auch das war keine Absicht ☺

skatehouse schrieb:

}}}

tcp        0      0 0.0.0.0:1194            0.0.0.0:*               LISTEN      0          21091      858/sshd: /usr/sbin
tcp        0    144 192.168.0.96:1194       192.168.0.69:64037      ESTABLISHED 0          21438      2052/sshd: pi [priv

Versuch mal auf dem Server mit:

sudo iptables -t nat -I POSTROUTING 1 -o ens18 -j MASQUERADE
sudo iptables -t nat -I POSTROUTING 2 -o tun0 -j MASQUERADE

und

sudo apt install tcpdump

sudo tcpdump -c 50 -vvveni ens18 dst port 1194 and src net 192.168.178.0/24

und jetzt ein Zugriff aus dem fernen Subnetz 192.168.178.0/24 auf dem sshd (IP 192.168.0.96, Port 1194).
Z. B.:

nc -zv 192.168.0.96 1194
sudo nmap -sS 192.168.0.96 -p1194
sudo nping -c 1 --tcp --flags syn -g 12345 -p 1194 192.168.0.96

(oder gleichwertig, je nach OS im fernen Subnetz).

lubux schrieb:

skatehouse schrieb:

}}}

tcp        0      0 0.0.0.0:1194            0.0.0.0:*               LISTEN      0          21091      858/sshd: /usr/sbin
tcp        0    144 192.168.0.96:1194       192.168.0.69:64037      ESTABLISHED 0          21438      2052/sshd: pi [priv

Versuch mal auf dem Server mit:

sudo iptables -t nat -I POSTROUTING 1 -o ens18 -j MASQUERADE
sudo iptables -t nat -I POSTROUTING 2 -o tun0 -j MASQUERADE

und

sudo apt install tcpdump

sudo tcpdump -c 50 -vvveni ens18 dst port 1194 and src net 192.168.178.0/24

und jetzt ein Zugriff aus dem fernen Subnetz 192.168.178.0/24 auf dem sshd (IP 192.168.0.96, Port 1194).
Z. B.:

nc -zv 192.168.0.96 1194
sudo nmap -sS 192.168.0.96 -p1194
sudo nping -c 1 --tcp --flags syn -g 12345 -p 1194 192.168.0.96

(oder gleichwertig, je nach OS im fernen Subnetz).

pi@ubuntu2:~$ sudo iptables -t nat -I POSTROUTING 1 -o ens18 -j MASQUERADE
pi@ubuntu2:~$ sudo iptables -t nat -I POSTROUTING 2 -o tun0 -j MASQUERADE
pi@ubuntu2:~$ sudo apt install tcpdump
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
tcpdump ist schon die neueste Version (4.99.1-3ubuntu0.2).
tcpdump wurde als manuell installiert festgelegt.
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 2 nicht aktualisiert.
pi@ubuntu2:~$ sudo tcpdump -c 50 -vvveni ens18 dst port 1194 and src net 192.168.178.0/24
tcpdump: listening on ens18, link-type EN10MB (Ethernet), snapshot length 262144 bytes

entferntes netz:

openhabian@ioBroker:~$ nc -zv 192.168.0.96 1194
192.168.0.96: inverse host lookup failed: Unknown host

skatehouse schrieb:

lubux schrieb:

skatehouse schrieb:

}}}

tcp        0      0 0.0.0.0:1194            0.0.0.0:*               LISTEN      0          21091      858/sshd: /usr/sbin
tcp        0    144 192.168.0.96:1194       192.168.0.69:64037      ESTABLISHED 0          21438      2052/sshd: pi [priv

Versuch mal auf dem Server mit:

sudo iptables -t nat -I POSTROUTING 1 -o ens18 -j MASQUERADE
sudo iptables -t nat -I POSTROUTING 2 -o tun0 -j MASQUERADE

und

sudo apt install tcpdump

sudo tcpdump -c 50 -vvveni ens18 dst port 1194 and src net 192.168.178.0/24

und jetzt ein Zugriff aus dem fernen Subnetz 192.168.178.0/24 auf dem sshd (IP 192.168.0.96, Port 1194).
Z. B.:

nc -zv 192.168.0.96 1194
sudo nmap -sS 192.168.0.96 -p1194
sudo nping -c 1 --tcp --flags syn -g 12345 -p 1194 192.168.0.96

(oder gleichwertig, je nach OS im fernen Subnetz).

pi@ubuntu2:~$ sudo iptables -t nat -I POSTROUTING 1 -o ens18 -j MASQUERADE
pi@ubuntu2:~$ sudo iptables -t nat -I POSTROUTING 2 -o tun0 -j MASQUERADE
pi@ubuntu2:~$ sudo apt install tcpdump
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
tcpdump ist schon die neueste Version (4.99.1-3ubuntu0.2).
tcpdump wurde als manuell installiert festgelegt.
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 2 nicht aktualisiert.
pi@ubuntu2:~$ sudo tcpdump -c 50 -vvveni ens18 dst port 1194 and src net 192.168.178.0/24
tcpdump: listening on ens18, link-type EN10MB (Ethernet), snapshot length 262144 bytes

entferntes netz:

openhabian@ioBroker:~$ nc -zv 192.168.0.96 1194
192.168.0.96: inverse host lookup failed: Unknown host

-

sudo tcpdump -c 50 -vvveni ens18 dst port 1194 and src net 192.168.178.0/24

Dankeschön ☺

skatehouse schrieb:

entferntes netz:

openhabian@ioBroker:~$ nc -zv 192.168.0.96 1194
192.168.0.96: inverse host lookup failed: Unknown host

Funktioniert der Ping bzw. das routing?

ping -c 3 192.168.0.96
ip r g 192.168.0.96

?

--- 192.168.0.96 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2028ms

openhabian@ioBroker:~$ ip r g 192.168.0.96
192.168.0.96 via 192.168.178.1 dev ens18 src 192.168.178.89 uid 1000
    cache

Geht nicht....andere Geräte ja. Ist da was in der Lan to LAN Kopplung schiefgelaufen in fritzbox?

skatehouse schrieb:

Geht nicht....andere Geräte ja. Ist da was in der Lan to LAN Kopplung schiefgelaufen in fritzbox?

Hast Du auf diesem source-Gerät, das MASQUERADE konfiguriert? Kannst Du andere IP-Adressen via AVM-VPN per ping erreichen?