Der OpenVPN-Server leitet den Ping-Verkehr für die restlichen Hosts im Subnetz nicht von tun0 an eth0 weiter

Derzeit habe ich ein OpenVPN-Server- und Client-Setup mit Rounting (kein Bridging).

Wenn ich versuche, von meinem Client zur Server-IP-Adresse zu pingen, funktioniert dies einwandfrei. Aber wenn ich versuche, den Rest der Subnetz-Hosts hinter dem openvpn-Server zu pingen, funktioniert das nicht. Kann jemand etwas erkennen, das offensichtlich in meinem Setup nicht stimmt? (Der OpenVPN-Server befindet sich unter 10.10.145.181 und der Host unter 10.10.146.8 IP-Adresse. Sie befinden sich in zwei separaten Subnetzen. Ich kann 10.10.146.8 von 10.10.145.181 direkt per Ping an diesen Host pingen. Nur wenn ich über VPN gehe, funktioniert dies nicht arbeiten.)

Soweit ich weiß, gelangt der Ping-Verkehr auf der tun0-Schnittstelle zum VPN-Server, aber dann leitet der VPN-Server ihn nicht über eth0 an den entsprechenden Host weiter. Daher sieht der Ping-Host keinen Datenverkehr und kein Paket wird verworfen. Aber was könnte das verursachen? Gibt es in openvpn eine Einstellung, um Datenverkehr von tun0 nach eth0 weiterzuleiten?

Folgendes beobachte ich ...

Auf dem OpenVPN-Client-Host:

> ping 10.10.146.8
PING 10.10.146.8 (10.10.146.8) 56(84) bytes of data.
<no further output>

Auf dem OpenVPN-Server-Host:

> sudo tcpdump -i tun0 'icmp[icmptype] = icmp-echo or icmp[icmptype] = icmp-echoreply'
00:34:32.624639 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1863, length 64
00:34:33.634564 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1864, length 64
00:34:34.640753 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1865, length 64
00:34:35.648922 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1866, length 64
00:34:36.659062 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1867, length 64
00:34:37.665402 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1868, length 64
00:34:38.673295 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1869, length 64
00:34:39.685336 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1870, length 64
00:34:40.687703 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1871, length 64
00:34:41.695766 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1872, length 64
> sudo tcpdump -i eth0 'icmp[icmptype] = icmp-echo or icmp[icmptype] = icmp-echoreply'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
04:14:48.583673 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 4807, seq 442, length 64
04:14:49.592908 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 4807, seq 443, length 64
04:14:50.600010 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 4807, seq 444, length 64
04:14:51.616401 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 4807, seq 445, length 64

Auf dem Host im Subnetz, den ich zu pingen versuche (10.10.146.8):

> sudo tcpdump -i eth0 'icmp[icmptype] = icmp-echo or icmp[icmptype] = icmp-echoreply'
sudo: unable to resolve host ip-10-10-146-8
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
<no further output>

Das Syslog (openvpn log) sagt:

Jul  8 00:36:25 ip-10-10-145-181 ovpn-server[1513]: xyz/<ip_address>:35315 UDPv4 READ [133] from [AF_INET]<ip_address>:35315: P_DATA_V1 kid=0 DATA len=132 
Jul  8 00:36:25 ip-10-10-145-181 ovpn-server[1513]: xyz/<ip_address>:35315 TUN WRITE [84]

netstat auf openvpn client:

10.10.0.1       10.10.0.5       255.255.255.255 UGH       0 0          0 tun0
10.10.0.5       0.0.0.0         255.255.255.255 UH        0 0          0 tun0
10.10.146.0     10.10.0.5       255.255.255.0   UG        0 0          0 tun0

netstat auf openvpn server:

10.10.0.0       10.10.0.2       255.255.255.0   UG        0 0          0 tun0
10.10.0.2       0.0.0.0         255.255.255.255 UH        0 0          0 tun0
10.10.145.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0

Ich habe eine Anweisung in der OpenVPN-Serverkonfiguration, um den Datenverkehr von der Clientseite weiterzuleiten, und ich sehe, dass dies geschieht.

push "route 10.10.146.0 255.255.255.0"

Zusätzliche Informationen zu Andrews Frage

> echo "sysctl -a | grep 'forwarding = 1'" | sudo -s
error: permission denied on key 'vm.compact_memory'
error: permission denied on key 'net.ipv4.route.flush'
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.lo.forwarding = 1
net.ipv4.conf.eth0.forwarding = 1
net.ipv4.conf.tun0.forwarding = 1
error: permission denied on key 'net.ipv6.route.flush'



> sudo iptables -L INPUT
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         


> sudo iptables -L FORWARD
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Update: Eigentlich sehe ich jetzt Datenverkehr auf eth0 auf dem Server, aber dieser Datenverkehr gelangt nicht ins Netzwerk und wird vom anderen Host empfangen. Ich denke, das ist ein Amazon VPC-Problem.

Ok, ich habe das nach ein paar Stunden Nachforschungen herausgefunden.

Das Problem liegt in der Weiterleitung. Die an den eth0-Port weitergeleiteten Pakete haben nicht die richtige Quell-IP-Adresse des Hosts im Netzwerk. Die IP-Adresse stammt von VPN.

05:07:43.991961 IP 10.8.0.6 > 10.10.146.8: ICMP echo request, id 3497, seq 499, length 64

Sie können dies ändern, indem Sie das Äquivalent von NAT (auf Routern) unter Linux aktivieren:

iptables -t nat -A POSTROUTING -o <eth0 or whatever else> -j MASQUERADE

Dies hat das Problem für mich behoben.

Dieses Problem kann auftreten, wenn das Standard-Gateway für die Hosts im LAN nicht der OpenVPN-Server ist. In einem solchen Fall benötigen die Hosts eine statische Route für die VPN-Adressen, damit die Antworten anstelle des Standard-Gateways an den VPN-Server gesendet werden.

Überprüfen Sie auf den LAN-Hosts die Routen ( route printfür Windows, route -nLinux, ǹetstat -rnMac).

Ich habe diesen Thread über Google gefunden und danke, dass diese Informationen nützlich waren. Ich habe genau das gleiche Problem, und diese Informationen haben es teilweise gelöst.

Maskiere es und es hat funktioniert. Aber für meinen Zweck ist dies nicht gut genug und weder die Lösung noch die endgültige Antwort für mich. Ich versuche immer noch, sie OHNE Maskierung weiterzuleiten. Für meinen Zweck ist es NICHT GENUG, die Verbindung alleine herzustellen. Weil ich die Quell-IP für die Protokollierung von Identifikations- und Zugriffssteuerungszwecken benötige. Durch das Maskieren wurde es verbunden, aber blind akzeptiert. Die Verbindung scheint immer von einer einzelnen FALSE-IP-Adresse zu stammen.

Ich habe einen SQL Server, der Verbindungen abhängig von der Quell-IP-Adresse akzeptieren / verweigern muss, nachdem er über das VPN gekommen ist. Es wird auch bevorzugt, die Zugriffs-IP weiterhin zu protokollieren, um Fehler oder die Sicherheit gegen Hacking zu verfolgen.

Ich frage mich immer noch, warum die Weiterleitung an diesem Endpunkt von VPN nur dann erfolgt, wenn Masqueraded. Der Verdacht, dass eine lokale Firewall oder ein Sicherheitsproblem vorliegt.

Bitte teilen Sie einige Erfahrungen oder Vorschläge mit, während Sie zu diesem Thread surfen. Vielen Dank.