Warum kann mein OpenVPN-Client nicht auf Maschinen in demselben LAN wie der OpenVPN-Server zugreifen?

73791
Grezzo

Ich habe OpenVPN auf meinem Linux-Server und Windows-Client gemäß den Anweisungen hier konfiguriert . Mein Client kann auf den Server zugreifen, kommt jedoch nicht weiter ins LAN.

Mein Server ist 10.23.29.64/24, mein OpenVPN-Subnetz ist 10.23.30.0/24 und mein Client ist 10.0.0.71/24, daher gibt es keine Überschneidungen.

Meine Server-Konfigurationsdatei lautet:

port 53 proto udp dev tun ca ca.crt cert server.crt key server.key dh dh1024.pem server 10.23.30.0 255.255.255.0 ifconfig-pool-persist ipp.txt push "route 10.23.29.0 255.255.255.0" keepalive 10 120 comp-lzo user nobody group nobody persist-key persist-tun status openvpn-status.log verb 3 

Meine Client-Konfiguration ist

client dev tun proto udp remote HOSTNAME_REMOVED 53 resolv-retry infinite  nobind persist-key persist-tun ca ca.crt cert client.crt key client.key ns-cert-type server comp-lzo verb 3 

Wenn eine Verbindung besteht, erhält mein Client 10.23.30.6/30 und hat 4 Routen hinzugefügt:

 10.23.29.0 255.255.255.0 10.23.30.5 10.23.30.6 1 10.23.30.1 255.255.255.255 10.23.30.5 10.23.30.6 1 10.23.30.4 255.255.255.252 10.23.30.6 10.23.30.6 30 10.23.30.6 255.255.255.255 127.0.0.1 127.0.0.1 30 

Mein Server erhält 10.23.30.1/32 (PERHAPS DAS IST DAS PROBLEM?)

Mein Client kann den Server unter 10.23.30.1 und 10.23.29.64 pingen, er kann jedoch nicht weiter kommen. Was muss ich noch tun, damit dieser Client auf das restliche LAN zugreifen kann?

AKTUALISIEREN:

Ich habe meinem Router eine statische Route hinzugefügt, so dass die Routing-Tabelle so aussah

=>ip rtlist Label Destination Gateway Interface Mtc Admin Oper 10.0.0.138/32 127.0.0.1 loop 0 UP [UP] 10.0.0.255/32 127.0.0.1 loop 0 UP [UP] 10.23.29.254/32 127.0.0.1 loop 0 UP [UP] 10.23.29.255/32 127.0.0.1 loop 0 UP [UP] 87.115.131.206/32 127.0.0.1 loop 0 UP [UP] 127.0.0.1/32 127.0.0.1 loop 0 UP [UP] 255.255.255.255/32 127.0.0.1 loop 0 UP [UP] 195.166.128.189/32 87.115.131.206 Internet 0 UP UP 212.159.6.9/32 Internet 10 UP UP 212.159.6.10/32 Internet 10 UP UP 10.0.0.0/24 10.0.0.138 LocalNetwork 0 UP [UP] 10.23.29.0/24 10.23.29.254 LocalNetwork 0 UP [UP] 10.23.30.0/24 10.23.29.10 LocalNetwork 0 UP [UP] 0.0.0.0/0 Internet 10 UP UP 

aber als ich eine traceroute von 10.23.29.10 bis 10.23.30.1 gemacht habe, bekam ich:

traceroute to 10.23.30.1 (10.23.30.1), 30 hops max, 60 byte packets 1 dsldevice.lan (10.23.29.254) 2073.983 ms 2073.481 ms 74.545 ms 2 * * * 

und alle Sterne bis es aufgegeben hat. Dies lässt mich glauben, dass die Traceroute-Pakete nicht an 10.23.29.10 weitergeleitet werden, wie es in der Routing-Tabelle angegeben ist.

5
[Dies scheint eine Lösung zu sein.] (Https://community.openvpn.net/openvpn/wiki/NatHack) 0xcaff vor 8 Jahren 1
@caffinatedmonkey Dieser Link ist sehr hilfreich. Grezzo vor 8 Jahren 0

4 Antworten auf die Frage

6
Grezzo

Ich habe endlich herausgefunden, was das Problem war. Ich verwende die Routing-Option von OpenVPN, die ein neues Subnetz für alle OpenVPN-Verbindungen erstellt. Mein Client erhielt eine IP-Adresse aus diesem Subnetz und auch mein Server, sodass sie über dieses Netzwerk miteinander kommunizieren konnten. Mit aktivierter IPv4-Weiterleitung auf meinem Server konnte ich auch Pakete in mein LAN senden und es war offensichtlich möglich, über die IP-Adresse des LANs mit dem Server zu kommunizieren.

Als der Client versuchte, mit anderen Computern in meinem LAN zu kommunizieren, erreichten die Pakete von meinem Client meine LAN-Hosts (ich habe dies nicht bestätigt, aber ich bin mir ziemlich sicher, dass sie es waren), aber die Quelladresse dieser Pakete war die Adresse aus dem OpenVPN-Netzwerk. Die LAN-Hosts wussten, dass sich das nicht in ihrem LAN befand, und das einzige, was sie in diesem Fall wussten, war, sie an das Standard-Gateway zu schicken, das mein Router war. Ich bezweifle, dass es irgendetwas mit ihnen getan hat, da das Senden eines Pakets an einen privaten IP-Bereich ins Internet sinnlos ist.

Die Lösung besteht darin, allen LAN-Hosts eine statische Route hinzuzufügen oder die Option "Bridging" von OpenVPN anstelle von "Routing" zu verwenden. Ich habe das noch nicht getan, bin aber sicher, dass dies der Weg ist.

Ich schätze Steve Gibson nicht sehr hoch (siehe http://www.theregister.co.uk/2001/06/25/steve_gibson_really_is_off/), aber dieser Artikel erklärt es ziemlich gut: http://www.grc.com /vpn/routing.htm Grezzo vor 11 Jahren 2
... auch den Link, den @caffinatedmonkey in einem Kommentar zu meiner Frage gepostet hat Grezzo vor 8 Jahren 0
2
anony

I don't think you have to add a static route to all LAN hosts. You could just add a static route in your gateway on that LAN, pointing all openvpn-network addresses to the openvpn server "lan-ip address".

Ich hatte das gehört, aber ich habe es versucht und es hat nicht funktioniert. Vielleicht können Sie erklären, warum? Ich habe meine ursprüngliche Frage mit Details zu dem, was ich versucht habe, aktualisiert Grezzo vor 11 Jahren 0
1
AsynKc

Gleiches Problem mit meiner Konfiguration, aber jetzt behoben:

Da Sie die OpenVPN Road Warrior-Einstellungen verwenden, werden die Pakete zwar geroutet, aber NATed. Sie sollten Ihre ausgehenden NAT-Optionen konfigurieren, um alle Quellports von virtuellen OpenVPN-IP-Adressen auf der LAN-Schnittstelle in beliebige Zielports mit WAN-NAT-Adresse zu übersetzen.

In pfSense sollten Sie die Automatic Outbound NAT-Regel in der Manual Outbound NAT-Regel deaktivieren und einfach eine neue Regel für das interne OpenVPN-Netzwerk hinzufügen.

Können Sie erklären, wie Sie die manuelle Regel hinzufügen? Charlie vor 6 Jahren 0
0
Tom Ratcliff

Hatte das gleiche Problem hier (verwenden Sie dieses Handbuch zur Einrichtung: https://www.digitalocean.com/community/tutorials/how-to-set-up-an-openvpn-server-on-ubuntu-14-04 )

Die Antwort von Antonis über die statische Route war der Schlüssel. Bei dd-wrt unter setup -> advanced routing:

dd-wrt statische Routeneinrichtung

Woher

  • Ziel: Openvpn Tun0-Schnittstelle
  • Gateway: Server, auf dem Openvpn (LAN-IP) ausgeführt wird

Das hat mir geholfen!