orcape
Goto Top

Fernwartung mit ssh über OpenVPN

Hi Leute,

ich mache per ssh über einen OpenVPN-Tunnel Fernwartung auf einem remoten Linux-PC.
Der Tunnel besteht zwischen meinem Router und dem remoten Router WRT54GL.
Auf dem remoten Router ist ein Portforwarding von Port 1194 (VPN) auf Port 22 des Linux-PC eingerichtet.
Trotzdem muß ich per Konsole immer den "Umweg" über den OpenVPN-Client (WRT54GL) wählen,
d.h. ssh <ip OpenVPN-Client) und dann erst ssh <ip Linux-PC>.
Gibt´s da eine andere Lösung oder habe ich da noch was übersehen.

Gruß orcape

Content-ID: 182542

Url: https://administrator.de/forum/fernwartung-mit-ssh-ueber-openvpn-182542.html

Ausgedruckt am: 22.12.2024 um 12:12 Uhr

aqui
aqui 25.03.2012 um 14:45:47 Uhr
Goto Top
Das ist ja Blödsinn was du da machst ! Wozu soll denn das überflüssige Port Forwarding gut sein ??
Wenn der OpenVPN Tunnel zwischen deinem Router und dem remoten Router aufgebaut ist hast du ja eine bestehende transparente Verbindung beider Netze denn das ist ja vermutlich eine LAN zu LAN Kopplung. Jeder kann also alles in den beiden gekoppelten netzen erreichen ! Logischerweise ja auch der tiefere Sinn einer VPN Kopplung !!
Dann musst du einfach nur den SSH Client aufmachen wie z.B. Putty und gibst die IP Adresse des remoten Linux PC in seinem Netz als Ziel an....fertig !
Wozu muss man da denn PFW machen und dann auch noch mit Translation von Ports die von Diensten in beiden Netzen aktiv genutzt werden, kein Wunder also das das in die Hose geht ?? Dafür hast du ja deinen VPN Tunnel und dafür sind VPNs ja da.
Irgendwas hast du da also völlig in den falschen Hals bekommen, oder falsch beschrieben hier oder dir ist nicht klar wie ein VPN bzw. SSH funktioniert ?!
orcape
orcape 26.03.2012 um 20:16:20 Uhr
Goto Top
Hi aqui,

nicht gleich schlechte "Noten" verteilen.
Ich bin nun mal kein Profi wie Du und was bei Dir nach ein paar Klicks erledigt ist, dauert bei mir etwas länger.
Entscheidend ist doch, das es am Ende funktioniert und man nicht bei jedem Problem gleich aufgibt.
Mag sein das ich hier einige blödsinnige Versuche gemacht habe, um das 100% ig zum laufen zu bringen.
Das die LAN-to-LAN Kopplung bei meiner Konstellation (DD-WRT-Client) auch anderen Kopfzerbrechen bereitet,
beweist folgende Seite.....
http://cyberdelia.de/2011/03/ddwrt-openvpn-nat-und-lan2lan-kopplung.htm ...
Ich melde mich wenn ich´s getestet habe.

Gruß orcape
orcape
orcape 31.03.2012 um 13:40:40 Uhr
Goto Top
Sorry, die kleine "Kunstpause".

Also definitiv liegt das Problem nicht beim DD-WRT OpenVPN-Client sondern bei der Config des ALIX pfSense.
Als erstes fehlte die Route vom Tunnel auf den remoten Client.
Obwohl im OpenVPN-Server das remote Netz eingetragen war, fehlte Sie als Eintrag in der Routingtabelle. ???
Nach erneutem speichern der Server-config jetzt i.O..
Obwohl ich in den Firewall-Rules des LAN alles freigegeben habe, sieht traceroute so aus......
root@orca:~#traceroute 192.168.55.2
traceroute to 192.168.55.2 (192.168.55.2), 30 hops max, 60 byte packets
1 skydive (192.168.155.1) 0.236 ms 0.264 ms 0.350 ms
2 * * *
3 * * *

...den DD-WRT-Router erreiche ich über EIngabe der Tunnel-IP...

root@orca:~#traceroute 10.10.8.6
traceroute to 10.10.8.6 (10.10.8.6), 30 hops max, 60 byte packets
1 skydive (192.168.155.1) 0.230 ms 0.245 ms 0.297 ms
2 10.10.8.6 (10.10.8.6) 74.449 ms 79.800 ms 82.679 ms

Ich häng mal die Routing-Tabelle des pfSense mit ran, vielleicht fällt Dir da was auf.
192.168.155.0/24 LAN
192.168.89.0/24 WLAN
172.16.7.0/24 DMZ
10.10.8.0/24 VPN
192.168.55.0/24 Remotes LAN

Destination Gateway Flags Refs Use Mtu Netif Expire
default 213.163.14.176 UGS 0 24833 1492 pppoe0
10.10.8.0/24 10.10.8.2 UGS 0 1370 1500 ovpns1
10.10.8.1 link#12 UHS 0 0 16384 lo0
10.10.8.2 link#12 UH 0 0 1500 ovpns1
62.109.123.197 213.163.14.176 UGHS 0 401 1492 pppoe0
78.50.118.123 link#9 UHS 0 0 16384 lo0
127.0.0.1 link#6 UH 0 131 16384 lo0
172.16.7.0/24 link#3 U 0 14 1492 vr2
172.16.7.1 link#3 UHS 0 8332 16384 lo0
192.168.55.0/24 10.10.8.2 UGS 0 179 1500 ovpns1
192.168.89.0/24 link#10 U 0 507 1492 ath0_wlan0
192.168.89.1 link#10 UHS 0 0 16384 lo0
192.168.155.0/24 link#1 U 0 63551 1492 vr0
192.168.155.1 link#1 UHS 0 0 16384 lo0
213.163.14.176 link#9 UH 0 4166 1492 pppoe0
213.163.14.19 213.163.14.176 UGHS 0 207 1492 pppoe0

Gruß orcape
aqui
aqui 02.04.2012 um 10:14:44 Uhr
Goto Top
Ist 192.168.55.2 die lokale LAN IP des remoten DD-WRT Routers ??
Du solltest immer die LAN IP dieses Routers pingen um Firewall Problematiken aus dem Wege zu gehen !
Ist VOR diesem DD-WRT noch ein anderer Router oder hat der direkt ein Modem angeschlossen ?
Übrigens den NAT "Vorwurf" des Cyberdelia Kollegen kann man nicht nachvollziehen. Das stimmt de facto nicht wie ein laboraufbau hier zeigt !
orcape
orcape 02.04.2012 um 13:31:52 Uhr
Goto Top
Die 192.168.55.1 ist die lokale LAN IP des remoten DD-WRT Routers. (192.168.55.2 ist ein Debian_Client)
Du solltest immer die LAN IP dieses Routers pingen um Firewall Problematiken aus dem Wege zu gehen !
Hatte ich auch schon probiert... face-smile
Ist VOR diesem DD-WRT noch ein anderer Router oder hat der direkt ein Modem angeschlossen ?
Der DD-WRT hängt mit WAN direkt am Modem. Einziger Router im remoten Netz.
Übrigens den NAT "Vorwurf" des Cyberdelia Kollegen kann man nicht nachvollziehen. Das stimmt de facto nicht wie ein laboraufbau hier zeigt !
Diese Config hat bei mir nur zu einem Abbruch der Tunnelverbindung geführt, wenn ich die Firewall eingeschaltet habe.
Ich tippe mal immer noch auf einen Fehler in meiner pfSense config, die Routing-Tabelle dürfte doch passen.
aqui
aqui 02.04.2012 um 13:38:45 Uhr
Goto Top
Routing Tabelle ist soweit ok. 192.168.55.0/24 wird via 10.10.8.2 geroutet was ja stimmt. Allein die 1500 Byte MTU Size ist kritisch, denn die ist für ein VPN zu groß. Ping sollte aber klappen.
Was passiert denn wenn du die 192.168.55.1 anpingst, das sollte in jedem Fall klappen !
orcape
orcape 02.04.2012 um 14:57:12 Uhr
Goto Top
Wie gesagt, es funktioniert weder ping noch Traceroute auf 192.168.55.1, nur auf die 10.10.8.6 . (DD-WRT-Tunnel)
Die MTU-Größe war auch schon mein Gedanke, auf dem DD-WRT läßt sich die Einstellung ja ändern, nur auf pfSense habe ich bei der Servereinstellung nichts gefunden. Wenn ich die MTU-Größe im DD-WRT auf 1492 stelle bricht mir aber der Tunnel ab.
Dürft aber eigentlich auch nicht die Ursache sein, sonst würde ich ja normalerweise auch Probleme haben wenn ich per ssh von 10.10.8.6 anschließend auf 192.168.55.2 gehe.
Ist schon sehr seltsam. Ich werde mal versuchen den ganzen Traffic über den Tunnel zu leiten. Mal sehen was da passiert.

Hab´s probiert, Keine Änderung.
orcape
orcape 02.04.2012 um 20:23:23 Uhr
Goto Top
...so nun komme ich der Sache schon näher.
Ich habe mal auf einer pfSense-Seite im Netz eine Routing-Tabelle eines Clients mit meiner DD-WRT verglichen.
Es fehlt folgender Eintrag....

Destination>>>>>>>>>>>>>Gateway>>>>>>>>>>>>>>>>>>>>Netif

10.10.8.6>>>>>>>>>>>>>>>>link#8>>>>>>>>>>>>>>>>>>>>>lo0

im DD_WRT Client.

Da kann ich nicht direkt auf das LAN kommen. Nur wie krieg ich das gebogen.

Gruß orcape