5
Linux keine Verbindung zwischen TAP und TUN Devices
Hallo,
ich bin zwar kein Linux-Anfänger mehr, aber ich kriege auf meinem vServer keine Verbindung zwischen TAP und TUN Devices hin.
Meine Situation:
Ich habe einen vServer gemietet. Dieser baut mittels Shrew VPN Verbindungen zu 4 Fritzboxen auf und erstellt für jede Verbindung ein TAP-Device. Zusätzlich stellt er mittels OpenVPN die Verbindung zu Clients zur Verfügung. Dafür nutze ich ein TUN-Device. Die Verbindungen vom Server zu den einzelnen Gegenstellen funktionieren tadellos. Ich habe auch schon IP Forwarding aktiviert. Von der Einrichtung einer Netzwerkbrücke habe ich bis jetzt Abstand genommen, da hierfür das phys. Interface benutzt werden muß. Da es das einzige Beinchen ist und ich nicht den Ast absägen will, auf dem ich sitze.
Ziel ist es, von einem OpenVPN Client Zugriff über den vServer auf die hinter den Fritzboxen liegenden Netzen zu bekommen.
Woran kann es liegen? Habt ihr Ideen?
P.S. Ich weiß, was TAP- und TUN-Devices sind.
ich bin zwar kein Linux-Anfänger mehr, aber ich kriege auf meinem vServer keine Verbindung zwischen TAP und TUN Devices hin.
Meine Situation:
Ich habe einen vServer gemietet. Dieser baut mittels Shrew VPN Verbindungen zu 4 Fritzboxen auf und erstellt für jede Verbindung ein TAP-Device. Zusätzlich stellt er mittels OpenVPN die Verbindung zu Clients zur Verfügung. Dafür nutze ich ein TUN-Device. Die Verbindungen vom Server zu den einzelnen Gegenstellen funktionieren tadellos. Ich habe auch schon IP Forwarding aktiviert. Von der Einrichtung einer Netzwerkbrücke habe ich bis jetzt Abstand genommen, da hierfür das phys. Interface benutzt werden muß. Da es das einzige Beinchen ist und ich nicht den Ast absägen will, auf dem ich sitze.
Ziel ist es, von einem OpenVPN Client Zugriff über den vServer auf die hinter den Fritzboxen liegenden Netzen zu bekommen.
Woran kann es liegen? Habt ihr Ideen?
P.S. Ich weiß, was TAP- und TUN-Devices sind.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 211709
Url: https://administrator.de/contentid/211709
Printed on: April 23, 2024 at 21:04 o'clock
5 Comments
Latest comment
- Open VPN funktioniert soweit problemlos ? (Grundlagen erklärt dieses Tutorial )
- Können OVPN Client den Server pingen ?
- Benutzt du iptables ? Wenn ja hast du das Forwarding angepasst ?
- Wie sieht deine Routing Tabelle aus bei aktiven TUN und TAP Interfaces also aktiven Tunnels ?
- Was sagt ein traceroute vom Client ?
Ja, OpenVPN funktioniert. Über den Tunnel sind sowohl Server als auch Client erreichbar.
Iptables sind im Einsatz und Forwarding wurde aktiviert.
Kernel IP Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 xxxxxxxxxxxxxx 0.0.0.0 UG 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
172.27.1.0 172.27.1.2 255.255.255.0 UG 0 0 0 tun0
172.27.1.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.3.0 192.168.3.200 255.255.255.0 UG 0 0 0 tap1
192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 tap1
192.168.11.0 192.168.11.200 255.255.255.0 UG 0 0 0 tap2
192.168.11.0 0.0.0.0 255.255.255.0 U 0 0 0 tap2
192.168.14.0 192.168.14.200 255.255.255.0 UG 0 0 0 tap0
192.168.14.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0
192.168.21.0 192.168.21.200 255.255.255.0 UG 0 0 0 tap3
192.168.21.0 0.0.0.0 255.255.255.0 U 0 0 0 tap3
C:\>tracert 192.168.3.250
Routenverfolgung zu 192.168.3.250 über maximal 30 Abschnitte
1 45 ms 78 ms 65 ms 172.27.1.1
2 172.27.1.1 meldet: Zielhost nicht erreichbar.
Ablaufverfolgung beendet.
Iptables sind im Einsatz und Forwarding wurde aktiviert.
Kernel IP Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 xxxxxxxxxxxxxx 0.0.0.0 UG 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
172.27.1.0 172.27.1.2 255.255.255.0 UG 0 0 0 tun0
172.27.1.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.3.0 192.168.3.200 255.255.255.0 UG 0 0 0 tap1
192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 tap1
192.168.11.0 192.168.11.200 255.255.255.0 UG 0 0 0 tap2
192.168.11.0 0.0.0.0 255.255.255.0 U 0 0 0 tap2
192.168.14.0 192.168.14.200 255.255.255.0 UG 0 0 0 tap0
192.168.14.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0
192.168.21.0 192.168.21.200 255.255.255.0 UG 0 0 0 tap3
192.168.21.0 0.0.0.0 255.255.255.0 U 0 0 0 tap3
C:\>tracert 192.168.3.250
Routenverfolgung zu 192.168.3.250 über maximal 30 Abschnitte
1 45 ms 78 ms 65 ms 172.27.1.1
2 172.27.1.1 meldet: Zielhost nicht erreichbar.
Ablaufverfolgung beendet.
Mit Forwarding meinst du da das IP Forwarding im System (Server) ??
Also sudo nano /etc/sysctl.conf und dort die Variable net.ipv4.ip_forward=1 entkommentieren.
Oft ist auch noch ein sudo echo 1 > /proc/sys/net/ipv4/ip_forward vonnöten (Beispiel Debian/Ubuntu)
Der Netzwerk Stack muss dann reloaded werden !
Vermutlich ist das aber schon geschehen ?! Das ist essentiell sonst routet der Server nicht !
Wenn du per SSH am Server angemeldet bist oder als OVPN Client kannst du ALLE IP Interfaces des Servers anpingen ?
Ansonsten sieht die Routing Tabelle OK aus. Das 172.27.1er Netz ist das interne OVPN Netz, richtig ? die .1 dann die interne Server IP.
Kannst du diese OVPN Server IP aus einem der IPsec Netze anpingen ?
Was die OVPN Clients anbetrifft hast du alle IPsec Netze 192.168.3, .11, .14 und .21 mit dem "push route..." Kommando in der OVPN Server Konfig an die Clients distribuiert ?
Hier wäre mal ein "route print" Output sinnvoll sofern es Winblows Clients sind.
Irgendwie fehlen dem OVPN Server die Routen in die IPsec VPNs, sei es das die iptables da zuschlagen oder er die Routen nicht erkennt...
Also sudo nano /etc/sysctl.conf und dort die Variable net.ipv4.ip_forward=1 entkommentieren.
Oft ist auch noch ein sudo echo 1 > /proc/sys/net/ipv4/ip_forward vonnöten (Beispiel Debian/Ubuntu)
Der Netzwerk Stack muss dann reloaded werden !
Vermutlich ist das aber schon geschehen ?! Das ist essentiell sonst routet der Server nicht !
Wenn du per SSH am Server angemeldet bist oder als OVPN Client kannst du ALLE IP Interfaces des Servers anpingen ?
Ansonsten sieht die Routing Tabelle OK aus. Das 172.27.1er Netz ist das interne OVPN Netz, richtig ? die .1 dann die interne Server IP.
Kannst du diese OVPN Server IP aus einem der IPsec Netze anpingen ?
Was die OVPN Clients anbetrifft hast du alle IPsec Netze 192.168.3, .11, .14 und .21 mit dem "push route..." Kommando in der OVPN Server Konfig an die Clients distribuiert ?
Hier wäre mal ein "route print" Output sinnvoll sofern es Winblows Clients sind.
Irgendwie fehlen dem OVPN Server die Routen in die IPsec VPNs, sei es das die iptables da zuschlagen oder er die Routen nicht erkennt...
Denk daran die Routen für den Rückweg eines Paketes hinzuzufügen. Sprich auf alle deiner 4 Fritzboxen muss ein Routing für das Open VPN Netz eingetragen werden.
@kn0rki
Jein....! Die internen IPsec Netze terminieren ja direkt an der Fritzbox. Die FB "kennt" somit alle IPsec Netze die direkt an ihr angeschlossen sind.
Das einzige Netz was sie NICHT kennt ist logischerweise das OVPN Netz und da hast du Recht, das muss zwingend statisch als Route via VPN Tunnel der FB in den remoten Fritzboxen nachgetragen werden !
Die AVM Seite sagt wie:
http://www.avm.de/de/Service/Service-Portale/Service-Portal/VPN_Praxis_ ...
bzw. unter "Praxis & Tips".
Zusätzlich muss der OVPN Server natürlich alle diese lokalen LAN Netze an den FritzBoxen mit dem push Kommando in der Server Konfig an die Clients senden. Auch da hast du Recht.
Das der Server im Kernel IPv4 Forwarding aktiviert haben muss und der Netzwerk Stack neu gestartet werden muss ist selbstverständlich und hat der TO (hoffentlich) ja auch gemacht ?
Ob er auch die fehlenden Routen entsprechend eingetragen hat er hier noch nicht gepostet ?!
Jein....! Die internen IPsec Netze terminieren ja direkt an der Fritzbox. Die FB "kennt" somit alle IPsec Netze die direkt an ihr angeschlossen sind.
Das einzige Netz was sie NICHT kennt ist logischerweise das OVPN Netz und da hast du Recht, das muss zwingend statisch als Route via VPN Tunnel der FB in den remoten Fritzboxen nachgetragen werden !
Die AVM Seite sagt wie:
http://www.avm.de/de/Service/Service-Portale/Service-Portal/VPN_Praxis_ ...
bzw. unter "Praxis & Tips".
Zusätzlich muss der OVPN Server natürlich alle diese lokalen LAN Netze an den FritzBoxen mit dem push Kommando in der Server Konfig an die Clients senden. Auch da hast du Recht.
Das der Server im Kernel IPv4 Forwarding aktiviert haben muss und der Netzwerk Stack neu gestartet werden muss ist selbstverständlich und hat der TO (hoffentlich) ja auch gemacht ?
Ob er auch die fehlenden Routen entsprechend eingetragen hat er hier noch nicht gepostet ?!
