Kürzlich hatte ich bei der Konfiguration meines VPN-Servers das Problem, dass ich keinen Internetzugang über meinen VPN-Server habe. Eigentlich verwende ich den VPS (Debian 8), auf dem ich ein VPN installiert habe. Der Client stellt die Verbindung normal her. Ich habe den Befehl „Trace Route“ verwendet, um festzustellen, wo der Datenverkehr endet, und offensichtlich endet er bei meinem VPN-Server. Ich weiß wirklich nicht, wie ich damit umgehen soll. Kann mir bitte jemand helfen? :) Hier ist meine Server- und Client-Konfiguration. Und ja, meine Client-Seite ist Windows 7 und 10.
Serverkonfiguration.
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key # This file should be kept secret
dh dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
Client-Konfiguration. Hinweis: Die IP des Servers ist verborgen.
client
dev tun
proto udp
remote 107.155.1x4.1x2 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca "C:\\OVPN\\ca.crt"
cert "C:\\OVPN\\client1.crt"
key "C:\\OVPN\\client1.key"
ns-cert-type server
comp-lzo
verb 3
Ich habe versucht, den DNS-Server 8.8.8.8 von Google clientseitig zu testen – er funktioniert immer noch nicht. Ich denke, das Problem liegt an einigen Schnittstellen auf der Serverseite, die zum Internet führen. Also, wer etwas vorschlägt, soll mir einfach mit nützlichen Ratschlägen helfen.
„Fügen Sie bitte die Ausgabe der folgenden Befehle hinzu: sysctl net.ipv4.ip_forward, iptables-save, ip route show. Auf dem Client evtl.: route print. – rda“
1) Die Ausgabe für sysctl net.ipv4.ip_forwardist
net.ipv4.ip_forward = 1
2) Die Ausgabe für ip route showist
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1
10.8.0.0/24 via 10.8.02 dev tun0
default dev venet0 scope link
3) Und Output für iptables-saveist
*mangle
:PREROUTING ACCEPT [241673:29858781]
:INPUT ACCEPT [232866:29385621]
:FORWARD ACCEPT [8803:472884]
:OUTPUT ACCEPT [250884:4018010]
:POSTROUTING ACCEPT [259688:40653794]
COMMIT
*filter
:INPUT ACCEPT [232866:29385621]
:FORWARD ACCEPT [8804:472884]
:OUTUPUT ACCEPT [250884:40180910]
COMMIT
*nat
:PREROUTING ACCEPT [20668:1262348]
:POSTROUTING ACCEPT [14826:1006759]
:OUTPUT ACCEPT [10970:791257]
COMMIT
*raw
:PREROUTING ACCEPT [241673:29858781]
:OUTPUT ACCEPT [250884:40180910]
COMMIT
11. Juni
Ich glaube, das Problem liegt in den Routing-Tabellen. Ich habe den Befehl - ausgeführt netstat -nrund überraschenderweise festgestellt, dass meine Routing-Tabelle seltsame IP-Adressen enthält, die nur für die VPN-Nutzung zugewiesen sind.**
Hier, schau mal:
Kernel-IP-Routingtabelle (Hinweis: Die Parameter der Routingtabelle lauten wie folgt in Spalte(!), Beispiel: Die IP der Routingtabelle übernimmt alle ersten Parameter aus der ersten Spalte. Und die letzten drei Parameter MSS Window irttsind für jeden Wert der Routingtabelle gleich.
Destination face 10.8.0.2 un0 10.8.0.0 un0 0.0.0.0 enet0
Gateway face 0.0.0.0 un0 10.8.0.2 un0 0.0.0.0 enet0
Genmask face 255.255.255.255 un0 255.255.255.0 un0 0.0.0.0 enet0
Flags face UH un0 UG un0 U enet0
MSS Window irtt face 0 0 0 un0 0 0 0 un0 0 0 0 enet0
15. Juni
Hey Kumpel! Danke nochmal für deine Antwort!
die Ausgabe ip route showlautet:
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1 10.8.0.0/24 via
10.8.0.2 dev tun0 default dev venet0 scope link
Die Ausgabe für den folgenden Befehl auf VPS ip route get 8.8.8.8lautet (Hinweis: Die IP-Adresse ist ausgeblendet):
8.8.8.8 dev venet0 src 107.155.1x4.1x2
cache mtu 1500 advmss 1460 hoplimit 64
Auf der Clientseite habe ich diesen Befehl verwendet route print. Ich habe eine verdammt große Seite mit IP-Adressen erhalten, aber ich weiß nicht, was hier wichtig ist, um dieses Problem zu lösen ...
Wie gehen wir weiter vor?
Nochmals vielen Dank für Ihre Hilfe, wirklich
Update 15. Juni
Hier ist die Ausgabe für den Befehl route printauf dem Windows-Client:
IPv4 Route Table
===========================================================================
Active routes:
Network address Subnet mask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.88.1 192.168.88.208 20
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
192.168.50.0 255.255.255.0 On-link 192.168.50.1 276
192.168.50.1 255.255.255.255 On-link 192.168.50.1 276
192.168.50.255 255.255.255.255 On-link 192.168.50.1 276
192.168.56.0 255.255.255.0 On-link 192.168.56.1 266
192.168.56.1 255.255.255.255 On-link 192.168.56.1 266
192.168.56.255 255.255.255.255 On-link 192.168.56.1 266
192.168.88.0 255.255.255.0 On-link 192.168.88.208 276
192.168.88.208 255.255.255.255 On-link 192.168.88.208 276
192.168.88.255 255.255.255.255 On-link 192.168.88.208 276
192.168.100.0 255.255.255.0 On-link 192.168.100.1 276
192.168.100.1 255.255.255.255 On-link 192.168.100.1 276
192.168.100.255 255.255.255.255 On-link 192.168.100.1 276
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 192.168.88.208 276
224.0.0.0 240.0.0.0 On-link 192.168.100.1 276
224.0.0.0 240.0.0.0 On-link 192.168.50.1 276
224.0.0.0 240.0.0.0 On-link 192.168.56.1 266
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 192.168.88.208 276
255.255.255.255 255.255.255.255 On-link 192.168.100.1 276
255.255.255.255 255.255.255.255 On-link 192.168.50.1 276
255.255.255.255 255.255.255.255 On-link 192.168.56.1 266
===========================================================================
Permanent routes:
Update 17. Juni
Hey Kumpel, ich habe versucht, diese Befehle zu verwenden, die NAT auf dem Server aktivieren, aber leider funktioniert es wieder nicht. Die Ausgabe ip route showist die gleiche wie zuvor:
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1
10.8.0.0/24 via 10.8.0.2 dev tun0
default dev venet0 scope link
Die Befehle, die Sie mir gegeben haben, liefen reibungslos, brachten aber keine Ergebnisse. Die neue IP-Route erscheint also einfach nicht in der Ausgabe! Ich habe versucht, dieselbe Route auf verschiedene Arten hinzuzufügen, habe sogar die Maske von /16 auf /24 geändert, immer noch nichts.
Der EinzigewichtigWas mir ein komisches Gefühl gab, war, dass ich meine OVPN-GUI auf der Clientseite ausgeführt habe und wusste, dass das Internet nicht funktionierte. Und was ich sehe, ist, dass meine Facebook-Seite von Anfang an geladen wird, aber andere wie google.com oder linkedin.com – oder irgendeine andere Website – öffnen sich einfach nicht …
Einige Kleinigkeiten zu meinem VPS-Anbieter. Auf der FAQ-Seite steht Folgendes:
**22
Do you support TUN/TAP? IPSEC?
Yes, TUN/TAP and IPSEC are enabled on all VPS by default.**
**2
What kind of virtualization is offered/used?
We utilize OpenVZ on our infrastructure. If you require KVM virtualization we recommend SpeedyKVM.**
Was könnte dieses Problem sein und wie können wir es überwinden?
Nochmals ein großes Dankeschön an Euch!
Antwort1
Sie müssen NAT auf dem Server aktivieren.
SNAT für statische IP-Adresse:
iptables -t nat -A POSTROUTING -s 10.8.0.0/16 -o <if> -j SNAT --to <ip>
Oder wenn Sie eine dynamisch zugewiesene IP-Adresse haben, verwenden Sie MASQUERADE(langsamer):
iptables -t nat -A POSTROUTING -s 10.8.0.0/16 -o <if> -j MASQUERADE
während
<if>ist der Name der externen Schnittstelle (alsovenet0)<ip>ist die IP-Adresse der externen Schnittstelle