OpenVPN ist nicht das Standard-Gateway für den gesamten Datenverkehr

Ich versuche, meinen Client dazu zu bringen, den gesamten Datenverkehr über einen VPS weiterzuleiten, auf dem OpenVPN ausgeführt wird. Wie Sie sehen können, werden Pings sowohl für Domänen als auch für unformatierte IP-Adressen zugelassen, aber es wird kein Datenverkehr wie der durch curl und traceroute verursachte zugelassen, der nichts hervorbringt. Der Datenverkehr funktioniert ordnungsgemäß, wenn keine Verbindung zum VPN besteht.

Alle Informationen finden Sie hier: https://pastebin.com/tGspNefn

Vielen Dank.

Funktionierende Konfigurationen dank der folgenden Lösung:

Server:

port <integer>
proto udp
dev tun
ca ca.crt
cert vpnserver.crt
key vpnserver.key  # This file should be kept secret
dh dh4096.pem
tls-auth ta.key 0
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway autolocal"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
keepalive 10 120
cipher AES-256-CBC
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3

Klient:

client
dev tun
proto udp
remote x.x.x.x <port number>
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert vpnclient.crt
key vpnclient.key
tls-auth ta.key 1
ns-cert-type server
cipher AES-256-CBC
comp-lzo
verb 3

Die Lösung besteht aus zwei Teilen:

1. Leiten Sie den gesamten Verkehr in den Tunnel um

Die einfachste Lösung: Verwenden Sie die OpenVPN- --redirect-gateway autolocalOption (oder fügen Sie sie in die Konfigurationsdatei ein als redirect-gateway autolocal.

2. Behandeln Sie den Datenverkehr auf dem OpenVPN-Server

Nachdem der Tunnel geöffnet ist, wird der gesamte Datenverkehr in den Tunnel geleitet und am Ende des Servers von der tun0Schnittstelle abgerufen.

Sie müssen zwei Dinge konfigurieren, damit es funktioniert:

ein. Aktivieren Sie die Paketweiterleitung

In den meisten Distributionen ist die Paketweiterleitung standardmäßig deaktiviert, daher gelangen Pakete von der Tunnelschnittstelle niemals zur öffentlichen Schnittstelle. Sie müssen die Weiterleitung aktivieren mit:

~ # sysctl net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1

Einmal getestet, machen Sie die Änderung dauerhaft in /etc/sysctl.conf

Stellen Sie außerdem sicher, dass iptablesder weitergeleitete Datenverkehr nicht blockiert wird:

~ # iptables -I FORWARD -j ACCEPT

Dies ist gut genug zum Testen - in der Produktion möchten Sie die Firewall-Regeln ein wenig präzisieren, aber das ist hier nicht möglich.

b. NAT die ausgehenden Pakete aus dem Tunnel

10.8.0.6Wenn die Weiterleitung aktiviert ist, werden die Pakete standardmäßig mit unveränderter Quelladresse weitergeleitet. Dies ist in Ihrem Fall der Fall. Solche Pakete werden entweder auf dem ISP-Gateway abgelegt oder selbst wenn sie das Ziel erreichen, findet die Antwort nie den Weg zurück. Diese privaten Adressen können im Internet nicht weitergeleitet werden.

Die Lösung besteht darin, den ausgehenden Datenverkehr zu NAT, dh die private 10.8.0.6Adresse durch die öffentliche IP des VPN-Servers zu ersetzen . Dadurch wird sichergestellt, dass die Antworten den VPN-Server erreichen und dort zurück in den Tunnel geleitet werden.

~ # iptables -t nat -I POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

3. Testen Sie es

Versuchen ping 8.8.4.4Sie es jetzt mit Ihrem VPN-Client. Sie sollten eine Antwort sehen. Lass es uns wissen wenn nicht :)