Ich versuche, einen OpenVPN-Server und -Client einzurichten, wobei der gesamte Client-Verkehr über den Server geleitet wird. Derzeit kann ich über den Client auf den Server zugreifen, aber wenn ich auf dem Server „push „redirect-gateway def1““ aktiviere, kann der Client keine Verbindung mehr zum Internet herstellen, weder über VPN noch auf andere Weise. Außerdem kann er keine Verbindung mehr zum Server herstellen, obwohl die LAN-Konnektivität noch einwandfrei ist. Meine Serverkonfigurationsdatei lautet:
local ***.***
port 1194
proto tcp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway local def1"
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3
und hier ist der Client:
client
dev tun
proto tcp
remote ***.*** 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert laptop.crt
key laptop.key
ns-cert-type server
comp-lzo
verb 3
Auf dem Server habe ich die IP-Weiterleitung aktiviert und das Routing über iptables aktiviert:
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
Der Client kann jedoch immer noch keine Verbindung über das VPN oder das Internet herstellen.
Antwort1
Zur Referenz finden Sie den entsprechenden Abschnitt des HOWTOHier, obwohl ich vermute, dass Sie das verstanden haben.
Als erstes würde ich versuchen, das 'local' zu entfernen, das heißt, der Befehl sollte
push "redirect-gateway def1"
und nicht
push "redirect-gateway local def1"
Das lokale Flag funktioniert nur, wenn sich alle Ihre Clients im selben Subnetz befinden.
Ein paar weitere Dinge, die Sie beachten sollten, sind, dass DNS-Verkehr über das VPN geleitet wird, sodass Sie Adressen nicht auflösen können, wenn Sie sich nicht darum gekümmert haben. DHCP kann auch weitergeleitet werden, obwohl es in Ihrem Fall nicht so aussieht, als ob das passieren sollte, da Sie ein geroutetes und kein überbrücktes VPN verwenden, aber es könnte sich trotzdem lohnen, dies zu überprüfen.
Antwort2
Wenn Sie ein neues Gateway zum Client „pushen“, müssen Sie auch einige Routen pushen, insbesondere die Route zum Subnetz, in dem sich dieses Gateway befindet. Dadurch erhalten Sie über das VPN Internetzugang. Wenn sich das Netzwerk, in dem sich das Gateway befindet, von dem unterscheidet, in dem sich der VPN-Server befindet, benötigen Sie auch zusätzliche Routen, damit der Client auf diese anderen Netzwerke zugreifen kann. Außerdem möchten Sie möglicherweise auch DNS-Server zum Client pushen, da der Client sonst die Namen der Ziele im Netzwerk, mit dem er jetzt verbunden ist, nicht auflösen kann.
Hier ist ein Auszug aus unserer OpenVPN-Serverkonfigurationsdatei:
# Push-Route zum Client, um ihn an unseren lokalen # virtueller Endpunkt. # pushen Sie "Route 10.180.0.1 255.255.255.255" # Schieben Sie alle Routen, die der Client benötigt, # zum lokalen Netzwerk. # pushen Sie "Route 10.171.0.0 255.255.0.0" pushen Sie "Route 10.172.0.0 255.255.0.0" pushen Sie "Route 10.173.0.0 255.255.0.0" pushen Sie "Route 10.174.0.0 255.255.0.0" pushen Sie "Route 10.175.0.0 255.255.0.0" pushen Sie "Route 10.176.0.0 255.255.0.0" pushen Sie "Route 10.177.0.0 255.255.0.0" pushen Sie "Route 10.181.0.0 255.255.0.0" pushen Sie "Route 10.182.0.0 255.255.0.0" pushen Sie "Route 192.168.61.0 255.255.255.0" # DHCP-Optionen an Windows-Clients übertragen. # push "dhcp-option DOMAIN unsere-interne-domain.com" push "dhcp-option DNS 10.abc" pushen Sie "dhcp-option WINS 10.bcd"
Dies sind alles interne Netzwerke, und wir drängen nicht einmal auf ein neues Gateway (da die meisten unserer Benutzer sich von weit her verbinden, ist es für sie besser, über ihr Standard-Gateway auf das Internet zuzugreifen, und wir sind keine Kontrollfreaks).
Antwort3
Das Problem bestand eigentlich darin, dass NAT nicht richtig eingerichtet war. Das wurde behoben und das VPN funktioniert jetzt.