OpenWRT + OpenVPN

OpenWRT + OpenVPN (9 Beiträge, 265 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

23.02.2015, 22:30 Uhr - Editiert von sir_clive, alte Version: hier

0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 br-wan
10.16.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tun314

Du hast nur eine Route für 10.16.*.* Adressen die übers VPN rausgehen soll, alles andere geht ganz normal raus... Nachdem orf.at aber nicht in dem Segment liegt (194.232.104.139), versteh ich nicht, warum das da rausgehen sollte?

willst du alles über das VPN routen oder nur bestimmte Segmente?

das mit dem config forwarding kenn ich nicht, ich hab das bislang über iptables masquerading gelöst, siehe
http://www.revsys.com/writings/quicktips/nat.html

Hi,

ich gebe zu, ich bin netzwerketechnisch leider nicht sehr bewandert, meistens befolge ich Kochrezepte, ohne alles bis ins letzte Detail zu verstehen.

Für den Anfang wäre ich schon froh, wenn ich *alles* übers VPN schicken könnte. Das Netz schaut so aus:

UPC <-> UPC Modem (192.168.0.1) <-> (192.168.0.10) TP-Link Router (192.168.1.1) <-> 192.168.1.0/24 (LAN + WLAN)

10.16.*.* entsteht "automagisch" wenn ich OpenVPN anwerfe. Lt. Anleitung reicht es ein Forwarding (das ist dann eigentlich eh eine iptables Einstellung) von der "lan" Zone in die "vyprvpn" Zone einzurichten, und es sollte schon funzen.

Wenn man sich jetzt aber meine Routing Tabelle noch mal anschaut:

0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 br-wan
10.16.0.0       0.0.0.0         255.255.0.0     U     0      0        0 tun314
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 br-wan
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 br-lan

sieht man, dass br-lan und br-wan auch nicht am selben Segment sind (richtig?). Ein Forward lan -> wan führt aber dazu, dass ich aus dem LAN in den WAN komme. Ein Forward von lan -> tun314 (VPN) führt leider zu gar nichts. Könnte es sein, dass hier nur die Standard Route (0.0.0.0) für tun314 fehlt?

Ich werde mal versuchen herauszufinden was verschiedene forwarding Einstellungen beim OpenWRT an den iptables verändern, aber könntest Du mir vielleicht einen tipp geben, wie Du die Einstellung direkt mit iptables Mitteln vornehmen würdest?

Ich werde mal versuchen herauszufinden was verschiedene forwarding
Einstellungen beim OpenWRT an den iptables verändern, aber könntest Du mir
vielleicht einen tipp geben, wie Du die Einstellung direkt mit iptables
Mitteln vornehmen
würdest?

Bin jetzt auch nicht soo bewandert, bin da mit den Kochrezepten ganz bei dir. Aber soweit ichs versteh:

Die Zeile hier schaltet mal prinzipiell die Forwarding Funktion ein. Mal temporär zum Testen:
echo 1 > /proc/sys/net/ipv4/ip_forward

Das überlebt aber keinen Reboot, hat aber den Vorteil dass wenn du was falsch machst jetzt beim Probieren, du das Kastl einfach rebootest.

Ebenso temporär und nicht reboot überlebend:
sudo iptables -t nat -A POSTROUTING -i br-lan -o tun314 -j MASQUERADE

Hoff ich hab jetzt keinen Gedankenfehler drin. Das sollte dann eigentlich deinen ganzen Traffic da rausleiten...

Falls du dich vertippt hast:
sudo iptables -F -t nat
löscht den Eintrag wieder

bin da letztens auch ewig drübergestolpert und Patentantwort hab ich auch keine - irgendwann hat sich's dann eingerenkt (*wtf*)?!?

Um schrittweise der Ursache näherzukommen geht man normal folgende Schritte bzw. verifiziert bestimmte Informationen (und ich hoffe, ich hau jetzt keine dummen Fehler rein):

*) mach eine 2. Shell auf und verfolg das openvpn-Log (tail -f), dreh verbose auf 5 (da wird's schon aussagekräftig, weil du jedes geroutete Paket als w + Antwort als r gemeldet bekommst)

*) fallst du noch wo unabhängig davon eine SSH zum Gateway starten kannst/darfst ... dort detto.

*) bei Serverdiensten kann es unglaublich praktisch sein, diese im Vordergrund zu starten (üblicherweise -D (Dont daemonize, -F o.ä., in diesem Fall aber --inetd und --daemon weglassen), weil man den Logoutput dann direkt sieht und Parameter schnell ändern kann - leider macht das OpenVPN auf OpenWRT schwer, weil luci diese mühsame eigene Parameterformat erst zusammenpfriemelt = müßte man manuell nachbilden.
Falls du aber ein übliches configfile hast, kannst du es auf den Router kopieren und damit (--config ...) anfangen + --verb overrulen.

*) ping schön und gut - aber aussagekräftiger ist traceroute = jeweils eigenen, gegnerischen Tunnelendpunkt (10.16.0.1 oder so) und dann eine IP im Zielnetz dahinter austesten um zu sehen, wie weit die Pakete kommen bzw. on/wie sie geroutet/geforwarded werden.
statt dem -I von ping muß man aber traceroute -s 10.16.0.?!?!? (eigenen Tunnelendpunkt) angeben.
Dobald das vom Router aus werkelt, selbiges von einem der internen, gerouteten Clients = dann sollt eben nur der Router-hop dazukommen und man sieht, im Log dazwischen ob es rausgeht (w) und wieder retour kommt (r)

*) du willst net-to-net-VPN? falls nicht masqueriert werden soll, muß dein heimisches Segment auf der anderen Seite bekannt und entsprechend geroutet sein, sonst kommt keine reply zurück.
(btw: das ip_forward_ipv4-sysctl-Setting ist bei Routern zwangläufig immer gesetzt)

*) die Firewall-Regeln bei vpn sind so eine Sache, weil sie in's masquerading reinspielen = testweise ausschalten (sonst ein Tipp bei Verbindungsproblemen) geht nicht

Mein Eindruck bei meinem Problem war, daß sie nach Änderungen nicht sauber geflusht wurden.

*) DNS-Auflösung und VPN-für-Adressen-ausserhalb-probieren würd ich beim Testen mal weglassen, sonst derhängt man sich vor Informationen.

*) eine Reihe von Parametern werden vom Server gepusht, u.a. auch routen und redirect-gateway => im Log verifizieren, was da kommt.

mehr fällt mir für den Moment nicht ein

AAAAAAH!!!!! ENDLICH!!!!

Ich bin dem Hinweis doch noch nachgegangen (Schlafen ist überbewertet!

) und bin auf die "pull" Option gekommen.

Weiters bin ich drauf gekommen, dass ich in meinem /etc/config/openvpn ein

option route_nopull '1'

hatte (warum auch immer - ich habe die Config von irgendwo blind übernommen

). Diese Zeile durch ein

option pull '1'

ersetzt, und schon hat es geklappt, auch ohne manueller iptables Manipulation und eigentlich ziemlich genau so wie im Link in meinem ersten Posting beschrieben!

Nochmals herzlichen Dank für die Hilfe!

25.02.2015, 01:26 Uhr - Editiert von sir_clive, alte Version: hier

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung