Archiv verlassen und diese Seite im Standarddesign anzeigen : OpenVPN-Gateway hinter Router möglich?
Nasenbaer
2012-05-05, 18:57:23
Hi,
ich habe folgendes Problem: Wenn ich unterwegs bin und über fremde WLAN-Netze surfe, möchte ich meine Verbindung gerne durch ein VPN absichern. Dazu habe ich lokal, hinter ner Fritz-Box, ne Linux-Kiste mit OpenVPN laufen.
Von außen per VPN auf diese Linux-Kiste verbinden klappt wunderbar. Der Client nutzt dann den OpenVPN-Server auch als Default Gateway. Allerdings müsste ich jetzt dafür sorgen, dass Anfragen aus dem VPN-Netz über die Linux-Kiste und dann die Fritz-Box ins Internet weitergeleitet werden und Antworten auch zurück ins VPN-Netz gesendet werden.
Für den Fall ohne extra Router (also der Fritz-Box) dazwischen klappt mein Script, dass ich noch aus Zeiten habe, wo ich nen gemieteten vServer dafür verwendet habe. Durch den Router dazwischen gehts nun aber nicht mehr und ich bin echt kein IPTables-Kenner. :)
Kennt sich jemand damit aus und kann mir helfen?
Hier mein altes Script (für NAT zwischen VPN-Netz und INet ohne Router dazwischen):
#!/bin/bash
iptables -F
iptables -t nat -F
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP
export LAN=tun0
export WAN=eth0
iptables -I INPUT 1 -i ${LAN} -j ACCEPT
iptables -I INPUT 1 -i ${WAN} -j ACCEPT
iptables -I INPUT 1 -i lo -j ACCEPT
iptables -I FORWARD -i ${LAN} -d 10.8.0.0/255.255.255.0 -j DROP
iptables -A FORWARD -i ${LAN} -s 10.8.0.0/255.255.255.0 -j ACCEPT
iptables -A FORWARD -i ${WAN} -d 10.8.0.0/255.255.255.0 -j ACCEPT
iptables -t nat -A POSTROUTING -o ${WAN} -j SNAT --to 81.34.5.67 # <- WAN-Adresse des Servers
echo 1 > /proc/sys/net/ipv4/ip_forward
for f in /proc/sys/net/ipv4/conf/*/rp_filter ; do echo 1 > $f ; done
Lokadamus
2012-05-05, 19:22:05
mmm...
Wenn ich es richtig verstanden habe, willst du eigentlich nur Subnetze verbinden. Hier hast du das Problem, dass deine Fritzbox wahrscheinlich nichts von dem 10.8er Netz kennt und die Pakete verwirft.
Da muss eine Route drauf, damit sie weiß, dass diese Pakete zu der VPN- Kiste gesendet werden sollen. Dann dürfte das Verbinden des Subnetzes auch klappen. Ich weiß nur nicht, wie man Routen in der Fritzbox einträgt und ob diese auch gleich frei sind oder durch die FW noch geblockt werden.
tcpdump auf deiner Linux- Kiste dürfte dir weiterhelfen, wenn du weißt, wie man die Protokolle liest. Ping ist in diesem Sinne sehr einfach zu erkennen.
Was du mit dem IPTables- Skript rum hantierst, erschließt sich mir so nicht ganz.
Nasenbaer
2012-05-05, 19:33:17
Das Problem ist erstmal schon, dass die Pakete aus dem 10.8.er Netz ja schon nicht an die Fritzbox gelangen. (Das LAN, dass vom Fritzbox-DHCP verwaltet wird, ist im 192.168.0.0/24 Netz).
Das Script hatte dafür gesorgt, dass mein damaliger vServer (der direkt am Netz hing), die Daten aus dem 10.8.er Netz per NAT ins INet geschleust hat.
Es gibt ja auch noch die Möglichkeit das VPN-Netz mit Ethernet-Bridging mit dem 192.168.0.0/24 Netz zu verbinden. Weiß nur nicht ob mich das weiterbringt.
Nur mal zur Begriffsklärung: "LAN" ist das VPN-Netz und "WAN" dein Intranet?!
sei laut
2012-05-05, 20:02:08
Kannst du kurz ne Skizze davon machen, nur grob?
Nasenbaer
2012-05-05, 20:53:22
Also ich habe folgende Netze:
VPN 10.8.0.0/24
LAN 192.168.0.0/24
WAN 31.x.y.z (Dyn-IP-Addr vom ISP)
Mein Linux-Server (192.168.0.1) ist mit der Fritz-Box (192.168.0.2) verbunden. Der Linux-Server verwaltet zusätzlich ein VPN (und hat darin die IP 10.8.0.1). Mein Notebook verbindet sich von extern (z.B. von irgendnem Hotspot) übers Internet mit dem VPN-Server (da die Fritzbox den entspr. Port weiterleitet).
Das Notebook bekommt dadurch ne VPN-IP-Addr. 10.8.0.6 und zusätzlich wird vom Notebook das Default Gateway abgeändert auch 10.8.0.1 (also auf den VPN-Server). Somit wird sämtlicher Traffic über den VPN-Tunnel direkt zum VPN-Server geschickt.
Leider gehts von da noch nicht weiter ins Internet (dunkelblau in der Skizze) aber genau das will ich erreichen.
-------
Und um das nochmal klar zu machen: Das gepostete IPTables-Skript kommt aktuell nicht zum Einsatz. Das würde nur gehen, wenn die Fritzbox nicht dazwischen hängen würde und mein Linux-Server direkten WAN-Zugang hätte (sprich ein Netzwerk interface eine WAN-Adresse hätte).
Lokadamus
2012-05-05, 21:06:08
mmm...
Kann dein NB deinen VPN- Server pingen?
Kann dein VPN- Server dein NB pingen?
Ist die Variable, die per Skript gesetzt wird, zur Zeit auch auf 1?
Wie sieht ein Tracert aus, wenn du einen Client ansprichst?
Wie sieht ein Tracert aus, wenn ein Client dein NB anspricht?
Die sollten auf die Fritzbox gehen, welche es zum VPN- Server schickt.
Nasenbaer
2012-05-05, 21:55:48
mmm...
Kann dein NB deinen VPN- Server pingen?
Kann dein VPN- Server dein NB pingen?
Ist die Variable, die per Skript gesetzt wird, zur Zeit auch auf 1?
Wie sieht ein Tracert aus, wenn du einen Client ansprichst?
Wie sieht ein Tracert aus, wenn ein Client dein NB anspricht?
Die sollten auf die Fritzbox gehen, welche es zum VPN- Server schickt.
- Jojo die helle blaue Linie klappt einwandfrei, d.h. NB und VPN-Server sehen und pingen sich erfolgreich an.
- Welche Variable meinst du? Das Skript läuft wie gesagt aktuell nicht. Ergäbe auch keinen Sinn, da es mit dieser Netzwerkstruktur halt nicht kompatibel ist bzw. für diese nicht ausgelegt wurde.
- Traceroutes vom NB zum Server haben eine direkte Verbindung, also übers VPN halt. Da kommt die Fritzbox dazwischen nicht vor.
Lokadamus
2012-05-05, 22:08:56
- Jojo die helle blaue Linie klappt einwandfrei, d.h. NB und VPN-Server sehen und pingen sich erfolgreich an.
- Welche Variable meinst du? Das Skript läuft wie gesagt aktuell nicht. Ergäbe auch keinen Sinn, da es mit dieser Netzwerkstruktur halt nicht kompatibel ist bzw. für diese nicht ausgelegt wurde.
- Traceroutes vom NB zum Server haben eine direkte Verbindung, also übers VPN halt. Da kommt die Fritzbox dazwischen nicht vor.mmm...
1.) Ok, die grundlegende VPN- Verbindung besteht schon einmal.
2.) In der Datei /proc/sys/net/ipv4/ip_forward sollte eine 1 stehen, bei einer 0 wäre das Problem schon gelöst. Bei einer 0 ist das Routing für andere Geräte nicht vorhanden, die Kiste würde nicht als Router arbeiten.
3.) Darum die Frage, wie sieht es vom VPN- Server zum NB aus und wie sieht es mit einem Client aus? Das ist doch das Ziel, dass ein Client dein NB erreichen kann, oder? Wenn nicht, willst du vom NB aus auch nur deinen VPN- Server erreichen ...
Nasenbaer
2012-05-05, 22:11:36
Nein mein Ziel ist es vom Notebook aus einen VPN-Tunnel zum VPN-Server aufzubauen, der dann als Gateway ins Internet dient. Sozusagen soll der VPN-Server mein Internetproxy sein. Nur halt kein Proxy im eigentlichen Sinne (also über SOCKS5 oder sowas).
Sinn ist es in Ruhe (d.h. SSL-verschlüsselt) in öffentlichen WLANs surfen zu können.
Lokadamus
2012-05-05, 22:23:09
mmm...
:| Installiere dir Tor oder ähnliches, das ist sinnvoller als das, was du da bastelst.
Nasenbaer
2012-05-05, 22:47:13
mmm...
:| Installiere dir Tor oder ähnliches, das ist sinnvoller als das, was du da bastelst.
Tut mir leid aber das ist Schwachsinn. :biggrin:
Das ist genau das was Hotspot-Shield oder der OpenVPN-Service anbieten. Die sind aber lahm oder kosten Geld. Tor ist dank P2P-Traffic auch nur noch ne lahme Gurke mit mächtig vielen Timeouts seitens der Webserver.
Wenn ich meine Linux-Kiste in ne Demilitarized Zone hänge, sprich der Server wird nach außen hin komplett sichtbar, dann geht es ja (mit dem kleinen Problem, dass mein IPTables-Script mit jeder WAN-IP-Adressen-Änderung aktualisiert werden müsste).
Aber das will ich nicht, weil die Absicherung des Server dann noch aufwendiger wäre.
Lokadamus
2012-05-05, 23:31:26
Tut mir leid aber das ist Schwachsinn. :biggrin:mmm...
:| Entweder hast du von zu hause aus ein paar WLans, die schlecht gesichert sind oder es ist Blödsinn.
Wenn du eh eine Flatrate hast, macht der Aufwand keinen Sinn.
Wenn du deinen Verkehr verschlüsselt haben willst, so dass niemand dich zurückverfolgen kann, macht es auch keinen Sinn.
Mir fehlt irgendwie der Zusammenhang bei deiner Aktion.
Nasenbaer
2012-05-06, 00:10:00
Folgendes Szenario:
Ich sitze in nem Cafe oder in der Uni und bin mit dem Notebook in einem ungesicherten WLAN. Damit 1. niemand mitlesen/-loggen kann wohin ich mich so verbinde und ich 2. auch auf Seiten ohne HTTPS meine Logindaten guten gewissenseingeben kann, muss ne Verschlüsselung her.
Derzeit nutze ich dazu noch nen vServer von HostEurope auf dem OpenVPN läuft. Ich verbinde mit vom ungesicherten WLAN aus im Cafe zu meinem vServer per OpenVPN. Damit ist der Traffic zwischen diesen beiden Nodes per SSL gsichert. Damit ich nicht nur auf den vServer gesichert zugreifen kann, sondern auf beliebige Server im Inet, fehlt aber noch etwas.
1. Beim Client (aka Notebook) wird dessen Default Gateway auf den vServer (genau genommen auf seine VPN-interne IP-Adresse) umgebogen.
2. Der vServer betreibt zudem NAT-Routing zwischen dem VPN-Netz und dem regulären Internet. (Das funktioniert damit genauso als wäre das VPN-Netz ein ganz normales LAN und der vServer der Router)
Weil ich aber den vServer kündigen möchte, möchte ich das nun umstellen auf meinen lokalen Homeserver - die Leitung dahin ist dafür dick genug.
Klingt doch einleutend oder? HotspotShield arbeitet ebend genauso - die nutzen auch ein VPN und der Traffic kommt damit erst wieder aus irgendeiner Node in den USA raus. Dorthin kommt es per VPN-Tunnel SSL-gesichert. Tor und Hotspotshield wäre damit also Alternativen, wenn diese nicht so wahnsinnig lahm wären.
Lokadamus
2012-05-06, 00:24:36
Folgendes Szenario:
Ich sitze in nem Cafe oder in der Uni und bin mit dem Notebook in einem ungesicherten WLAN. Damit 1. niemand mitlesen/-loggen kann wohin ich mich so verbinde und ich 2. auch auf Seiten ohne HTTPS meine Logindaten guten gewissenseingeben kann, muss ne Verschlüsselung her.mmm...
:| Gehen wir gleich vom beliebtesten Szenario aus:
Du bist ein kleiner Kinderschänder (ich hoffe nicht).
Um deinen Verkehr zu verstecken, leitest du alles auf deinen kleinen Proxy um. Dieser Proxy steht bei dir zu hause in der Straße XY, Stadt YX. Egal, welchen Verkehr du erzeugst, alles geht erst Mal nach hause und von dort aus direkt in das Internet. Schön, du hast deinen Verkehr zwischen zu hause und Internet verschlüsselt. Aber danach?
Wenn du ein Kinderschänder bist, hoffe ich, dass sie dich bald haben, was auch nicht wirklich schwer sein dürfte (Internetanschluß ZYX ist mal wieder aktiv, mal schauen, was er heute macht).
Wenn du doch nur legal surfts, 2 Sachen:
1.) Es gibt mehrere anonyme Proxys, die so was anbieten.
2.) Ein tcpdump fehlt von deinem VPN- Server, um zu sehen, was mit dem Verkehr falsch läuft. OpenVPN hat keine Probleme damit Verkehr umzuleiten. Aber wenn nichts zurückkommt, dürfte die Route fehlen.
sei laut
2012-05-06, 00:27:20
Ich seh noch nicht, wozu du die iptables Firewall brauchst und du 2 Netze hast. Oder ist die Trennung irgendwo sinnvolll?
Im Grunde musst du dem VPN-Client doch nur sagen, dass die Fritzbox das Gateway ist, damit wird die Fritzbox zur default route in Internet - vorausgesetzt, du trennst dich vom 10er Netz.
Wenn du deine 2 Netze beibehalten willst, müsste man in der Tat ein komplett neues iptables Skript machen, das muss ich mir aber mal morgen anschauen. Im Grunde müsste das Skript nur mit Forward von 10er zu 192er Netz und 192 zu 10er Netz ausgestattet sein. Das Postrouting fällt dann weg, da der OpenVPN Server ja selbst hinter einer Firewall schon hängt (Fritzbox) und die den Traffic an den OpenVPN Server weiterleitet.
Nasenbaer
2012-05-06, 00:41:39
Ich seh noch nicht, wozu du die iptables Firewall brauchst
Nicht der Firewall wegen, sondern zwecks NAT.
... und du 2 Netze hast. Oder ist die Trennung irgendwo sinnvolll?
Naja das ist die Standard-Konfig bei OpenVPN. Benötigen tue ich sie nicht, aber normalerweise ist das VPN-Netz ungleich dem LAN in dem der VPN-Server steht.
OpenVPN soll wohl auch Ethernetbridging können aber das ist aufwendiger in der Konfiguration aber dann würde mein Remote verbundenes Notebook einfach ins LAN integriert werden und hätte dann bspw. 192.168.0.123 als IP-Adresse. Dann könnte man auch einfach die Fritzbox als Default-Gateway einstellen und fertig ist es. :)
ABER ich dachte eine leichte Anapssung bei der NAT-Konfig von IPtables wäre vielleicht einfacher und jemand hätte hier fix ne Lösung parat.
Also bevor du morgen deine Zeit opferst und dich durch IPTables/IPRoute wühlst, schau ich mir sonst lieber das Ethernet-Bridging an. Hatte gehofft, 4-5 Posts und jemand könnte mir sagen wie ich das Routing hinbekomme. :)
sei laut
2012-05-06, 10:06:25
Ich hab mir dein Skript oben nochmal angeschaut. Was macht es?
Es lässt zu, dass jeglicher Traffic aus dem OpenVPN Netz mit einer VPN IP in jedes andere Netz geroutet wird.
Es lässt weiterhin zu, dass Traffic aus dem LAN/WAN (eth0 Interface) ins OpenVPN Netz geschleust wird.
Nun noch "iptables -A POSTROUTING -t nat -o ${WAN} -s 10.8.0.0/24 -j MASQUERADE"
einfügen statt der SNAT Regel - wobei man einfach auch die SNAT Regel ändern könnte.
Ich seh nicht, wo sich durch die Fritzbox groß was ändert. Für deinen OpenVPN Client beginnt momentan das Internet am OpenVPN Server, selbst wenn dahinter erstmal ein privates Netz kommt.
Man könnte die Forward Regeln auch auf bestimmte Ports (80,443) beschränken, aber schau erstmal, dass du die Fritzbox pingen kannst.
Nasenbaer
2012-05-06, 11:47:16
Ich hab mir dein Skript oben nochmal angeschaut. Was macht es?
Es lässt zu, dass jeglicher Traffic aus dem OpenVPN Netz mit einer VPN IP in jedes andere Netz geroutet wird.
Es lässt weiterhin zu, dass Traffic aus dem LAN/WAN (eth0 Interface) ins OpenVPN Netz geschleust wird.
Nun noch "iptables -A POSTROUTING -t nat -o ${WAN} -s 10.8.0.0/24 -j MASQUERADE"
einfügen statt der SNAT Regel - wobei man einfach auch die SNAT Regel ändern könnte.
Ich seh nicht, wo sich durch die Fritzbox groß was ändert. Für deinen OpenVPN Client beginnt momentan das Internet am OpenVPN Server, selbst wenn dahinter erstmal ein privates Netz kommt.
Man könnte die Forward Regeln auch auf bestimmte Ports (80,443) beschränken, aber schau erstmal, dass du die Fritzbox pingen kannst.
Danke für deine Hilfe. Werde ich demnächst ausprobieren (ab morgen bin ich erstmal ne Woche nicht daheim) und mich dann wieder melden.
mmm...
:| Gehen wir gleich vom beliebtesten Szenario aus:
Du bist ein kleiner Kinderschänder (ich hoffe nicht).
Um deinen Verkehr zu verstecken, leitest du alles auf deinen kleinen Proxy um. Dieser Proxy steht bei dir zu hause in der Straße XY, Stadt YX. Egal, welchen Verkehr du erzeugst, alles geht erst Mal nach hause und von dort aus direkt in das Internet. Schön, du hast deinen Verkehr zwischen zu hause und Internet verschlüsselt. Aber danach?
Wenn du ein Kinderschänder bist, hoffe ich, dass sie dich bald haben, was auch nicht wirklich schwer sein dürfte (Internetanschluß ZYX ist mal wieder aktiv, mal schauen, was er heute macht).
Wenn du doch nur legal surfts, 2 Sachen:
1.) Es gibt mehrere anonyme Proxys, die so was anbieten.
2.) Ein tcpdump fehlt von deinem VPN- Server, um zu sehen, was mit dem Verkehr falsch läuft. OpenVPN hat keine Probleme damit Verkehr umzuleiten. Aber wenn nichts zurückkommt, dürfte die Route fehlen.
Also entweder hab ich dich mit dem Satz "das sei Schwachsinn" gekrängt - dann tut mir das leid, so war es nicht gemeint - oder du hast echt eine blühende Phantasie. *g*
Ich habe dir doch erläutert was das Problem ist. Wenn du in einem offenen LAN bist, dann kann jeder deinen Traffic sniffen, wenn du HTTP-Seiten ansurfst. Damit kann er loggen welche URLs du aufrufst (nicht so schlimm für mich, da ich nicht auf Kinderporno oder sonstiges in der Richtung abfahre). ABER er kann auch alle übertragenen Login-Daten (Nutzername+Passwort) sniffen. Loggst du dich im Cafe bei 3dcenter-forum.de ein oder bei web.de etc., dann kann jeder deine Daten klauen. Vielleicht ist dir dieses Szenario zu abstrus aber in Uni-WLAN einer Informatik-Fakultät laufen unzählige Möchtegern-Hacker rum und die brauchen meine Daten nicht sniffen. ;)
Zum Thema fertiger Alternative (Anonyme Proxies, Tor, etc.) - es geht nicht darum meine Identität im INet zu verschleiern (sonst wäre die Umleitung über meinen Home-Anschluss wahrlich doof), sondern, dass niemand im gleichen Ausgansnetz meinen Traffic sniffen kann. Die von dir genannten fertigen Lösungen sind langsam, sehr langsam. Glaub mir Tor etc. habe ich natürlich ausprobiert bevor ich mir diese Mühe hier mache.
Hier gibts ein kleines Video, dass das nochmal gut erklärt: https://www.privatetunnel.com/
Aber dieser Dienst kostet halt und darum will ichs selber umsetzen.
Du brauchst überhaupt kein NAT auf deinem Linux-Server.
1. IP-Forwarding auf dem Linux-Server aktivieren: sysctl -w net.ipv4.ip_forward=1
2. Auf der Fritzbox eine Route für das Netz 10.8.0.0/24 mit Ziel 192.168.0.1 (Linux-Server) eintragen.
3. Bei deinem DHCP-Server ebenfalls eine Route für das Netz 10.8.0.0/24 mit Ziel 192.168.0.1 eintragen.
Dann wissen die Fritzbox und alle anderen PCs im LAN (die sich ihre Netz-Informationen vom DHCP-Server holen) dass sie den Verkehr für die VPN-Clients zum Linux-Server schicken müssen. Wenn du die Netzkonfiguration der einzelnen PCs im LAN nicht über DHCP, sondern manuell durchführst, musst du die zusätzlich Route dort natürlich auch manuell hinzufügen.
Nasenbaer
2012-05-06, 21:51:17
Du brauchst überhaupt kein NAT auf deinem Linux-Server.
1. IP-Forwarding auf dem Linux-Server aktivieren: sysctl -w net.ipv4.ip_forward=1
2. Auf der Fritzbox eine Route für das Netz 10.8.0.0/24 mit Ziel 192.168.0.1 (Linux-Server) eintragen.
3. Bei deinem DHCP-Server ebenfalls eine Route für das Netz 10.8.0.0/24 mit Ziel 192.168.0.1 eintragen.
Dann wissen die Fritzbox und alle anderen PCs im LAN (die sich ihre Netz-Informationen vom DHCP-Server holen) dass sie den Verkehr für die VPN-Clients zum Linux-Server schicken müssen. Wenn du die Netzkonfiguration der einzelnen PCs im LAN nicht über DHCP, sondern manuell durchführst, musst du die zusätzlich Route dort natürlich auch manuell hinzufügen.
Ok werd ich testen, wenn ich wieder zurück bin. (3.) brauche ich gar nicht, da, wenn ich unterwegs bin, ja nicht gleichzeitig zu hause bin um dort was ins VPN-Netz funken zu können.
Nasenbaer
2012-05-27, 17:25:07
Du brauchst überhaupt kein NAT auf deinem Linux-Server.
1. IP-Forwarding auf dem Linux-Server aktivieren: sysctl -w net.ipv4.ip_forward=1
2. Auf der Fritzbox eine Route für das Netz 10.8.0.0/24 mit Ziel 192.168.0.1 (Linux-Server) eintragen.
3. Bei deinem DHCP-Server ebenfalls eine Route für das Netz 10.8.0.0/24 mit Ziel 192.168.0.1 eintragen.
Dann wissen die Fritzbox und alle anderen PCs im LAN (die sich ihre Netz-Informationen vom DHCP-Server holen) dass sie den Verkehr für die VPN-Clients zum Linux-Server schicken müssen. Wenn du die Netzkonfiguration der einzelnen PCs im LAN nicht über DHCP, sondern manuell durchführst, musst du die zusätzlich Route dort natürlich auch manuell hinzufügen.
Hab ich gemacht und ging sofort - danke nochmal für die Info. Dass ich nun komplett ohne NAT auskomme ist mir ganz recht. Die CCNA-Ausbildung liegt schon wieder 10 Jahre zurück und wenn man's nie braucht kann man auch nicht mit umgehen. :D
Danke an die andern beiden nochmal für die Ratschläge. Geht jetzt alles.
Und @Lokadamus keine Angst ich guck immer noch keine Kinderpornos und hatte das auch nie vor. Möchte einfach meine Login-Daten und Privatsphäre in öffentlichen WLANs schützen. ;)
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.