tl;dr(nach stundenlangem Debuggen mit @krisFR): Verwenden Sie zumindest unter Debian 8 niemals virtuelle Schnittstellen (eth0:1) für OpenVPN, sondern wenden Sie stattdessen die iproute2hier beschriebenen neuen Debian-Methoden (manueller Ansatz) an:https://wiki.debian.org/NetworkConfiguration#iproute2_method. Es wird den Verkehr gut umleiten.
Ich habe versucht, OpenVPN auf einem Rechner einzurichten, auf dem der gesamte Client-Verkehr über den Tunnel gesendet werden sollte. Dies ist also ein Teil meiner Serverkonfiguration:
local x.x.x.243
port 443
proto udp
dev tun
server 172.31.1.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
Und meine Client-Konfiguration:
pull
resolv-retry infinite
mute-replay-warnings
redirect-gateway def1
script-security 1
Der Client kann eine Verbindung zum VPN herstellen und den VPN-Host unter anpingen 172.31.1.1. Wenn ich jedoch versuche, google.com per Domäne oder IP anzupingen, erhalte ich eine Request timeout for icmp_seq 0Meldung ...
Was kann die Ursache dafür sein? Randbemerkung: Ich habe alle Firewalls deinstalliert und stelle IPTables derzeit wie folgt ein:
iptables -A INPUT -i eth0:1 -m state --state NEW -p udp --dport 443 -j ACCEPT
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -o eth0:1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth0:1 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -s 172.31.1.0/24 -o eth0:1 -j MASQUERADE
iptables -A OUTPUT -o tun+ -j ACCEPT
Danke schön.
Also habe ich versucht, den Client anzupingen 213.30.5.46(eine der IPs von Google), was nicht funktionierte. Allerdings habe ich folgendes Ergebnis erhalten:
Abhören der ausgehenden VPN-IP (eth0:1):tcpdump -i eth0 -t host x.x.x.243
IP [CLIENT_IP x..].51060 > vpn.exampledomain.com.https: UDP, length 113
IP [CLIENT_IP x..].51060 > vpn.exampledomain.com.https: UDP, length 145
IP vpn.exampledomain.com.https > [CLIENT_IP x..].51060: UDP, length 81
IP [CLIENT_IP x..].51060 > vpn.exampledomain.com.https: UDP, length 145
IP [CLIENT_IP x..].51060 > vpn.exampledomain.com.https: UDP, length 145
IP [CLIENT_IP x..].51060 > vpn.exampledomain.com.https: UDP, length 145
Gleichzeitig bekam ich beim Abhören auf tun0 Folgendes:tcpdump -i tun0
23:40:39.864798 IP 172.31.1.10 > cache.google.com: ICMP echo request, id 17942, seq 0, length 64
23:40:40.925951 IP 172.31.1.10 > cache.google.com: ICMP echo request, id 17942, seq 256, length 64
23:40:41.886679 IP 172.31.1.10 > cache.google.com: ICMP echo request, id 17942, seq 512, length 64
23:40:42.906125 IP 172.31.1.10 > cache.google.com: ICMP echo request, id 17942, seq 768, length 64
Hier ist die Ausgabe von iptables -L -n -v:
Chain INPUT (policy ACCEPT 34772 packets, 2265K bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- eth0:1 * 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:443
13 1092 ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
1437 96985 ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- tun+ eth0:1 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT all -- eth0:1 tun+ 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
Chain OUTPUT (policy ACCEPT 32574 packets, 7919K bytes)
pkts bytes target prot opt in out source destination
13 1092 ACCEPT all -- * tun+ 0.0.0.0/0 0.0.0.0/0
Notiz: /proc/sys/net/ipv4/ip_forwardist eingestellt auf 1.
tcpdump -i eth0:1 -t host 213.30.5.46Beim Pingen des Ziels als Ziel ausgewählt :
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0:1, link-type EN10MB (Ethernet), capture size 262144 bytes
IP 172.31.1.10 > cache.google.com: ICMP echo request, id 16920, seq 0, length 64
IP 172.31.1.10 > cache.google.com: ICMP echo request, id 16920, seq 256, length 64
IP 172.31.1.10 > cache.google.com: ICMP echo request, id 16920, seq 512, length 64
IP 172.31.1.10 > cache.google.com: ICMP echo request, id 16920, seq 768, length 64
Auf dem Client wird nichts angezeigt, der Ping läuft schließlich ab.
Die von OpenVPN verwendete IP-Adresse wird wie folgt local x.x.x.243eingerichtet :\etc\network\interfaceseth0:1eth0
auto eth0:1
iface eth0:1 inet static
address x.x.x.243
gateway x.x.x.129
netmask 255.255.255.128
dns-nameservers x.x.x.4 x.x.x.104
Antwort1
Wie Sie sagten, verbringen wir Stunden damit, das Problem zu beheben ...
Unter Berücksichtigung aller Tests, die wir durchgeführt und aller Spuren, die wir abgerufen haben, scheint es letztendlich so, als hätten wir ein seltsames Verhalten in Bezug auf die virtuelle Schnittstelle festgestellt eth0:1.
z.B :http://lartc.org/howto/lartc.iproute2.html
Die meisten Linux-Distributionen und die meisten UNIX-Systeme verwenden derzeit die bewährten Befehle arp, ifconfig und route. Diese Tools funktionieren zwar, zeigen jedoch unter Linux 2.2 und höher unerwartetes Verhalten. Beispielsweise sind GRE-Tunnel heutzutage ein integraler Bestandteil des Routings, erfordern jedoch völlig andere Tools.
Bei iproute2 sind Tunnel fester Bestandteil des Tool-Sets.
Wir haben uns entschieden, dazu überzugehen iproute2(es zumindest zu versuchen), /etc/network/interfacesdie Datei zu ändern, um die Art und Weise zu ändern, mit der der eth0Schnittstelle mehrere IPs zugewiesen werden.
Danach lief alles reibungslos und funktionierte!
iproute2Beispiel :
auto eth0
allow-hotplug eth0
iface eth0 inet static
address 192.168.1.42
netmask 255.255.255.0
gateway 192.168.1.1
iface eth0 inet static
address 192.168.1.43
netmask 255.255.255.0
Weitere Infos iproute2hier: