☰

OpenVPN-Server kann keine Clients anpingen

tag-icon • tag-icon routing openvpn
OpenVPN-Server kann keine Clients anpingen

Ich habe OpenVPN auf einem Debian-Server eingerichtet. Clients können eine Verbindung herstellen und Clients können den Server anpingen und auf Ressourcen (Samba-Freigaben und Intranet) zugreifen.

Der Server kann den Client jedoch nicht anpingen, da es einfach zu einer Zeitüberschreitung kommt.

Diagramm

Client OpenVPN assigned IP: 10.67.15.26
   ↓ UDP on 1194
Internet
   ↓
Router port-forwards 1194 to server
   ↓ 
Server LAN IP: 10.67.5.1

Server-OpenVPN-Konfiguration (relevante Teile)

port 1194
proto udp
dev tun
server 10.67.15.0 255.255.255.0
push "route 10.67.5.0 255.255.255.0"

Server-Routingtabelle

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.67.15.2      0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.67.15.0      10.67.15.2      255.255.255.0   UG    0      0        0 tun0
10.67.5.0       0.0.0.0         255.255.255.0   U     0      0        0 eth1
0.0.0.0         10.67.5.254     0.0.0.0         UG    0      0        0 eth1

Server-Firewall

Ich habe die Firewall des Servers vorübergehend deaktiviert, die Richtlinien aller Ketten sind auf ACCEPT und alle Weiterleitungsflags sind gesetzt:

1 : /proc/sys/net/ipv4/conf/all/forwarding
1 : /proc/sys/net/ipv4/conf/default/forwarding
1 : /proc/sys/net/ipv4/conf/lo/forwarding
1 : /proc/sys/net/ipv4/conf/eth1/forwarding
1 : /proc/sys/net/ipv4/conf/tun0/forwarding
1 : /proc/sys/net/ipv4/ip_forward

Testfälle:

Client: ping 10.67.5.1funktioniert, ebenso wie andere Ressourcen.

Server: ping 10.67.15.26Zeitüberschreitung.

Antwort1

Durch den Vergleich zweier verschiedener Clients konnte ich zwei Probleme identifizieren und beheben.

Problem 1: Routing

Aus irgendeinem Grund (und ich bin nicht sicher, ob ich das gelöst habe) vergaß die Routing-Tabelle des Servers ständig die Route zu/von seinem LAN (10.67.5.0/24). Dies führte dazu, dass der gesamte ausgehende LAN-Verkehr über sein Haupt-Gateway lief und nicht zum OpenVPN-LAN (10.67.15.0/24) weitergeleitet wurde. Dies führte dazu, dass der für das LAN bestimmte Verkehr vom OpenVPN-Netzwerk am Haupt-Gateway fehlschlug; daher wurden zwar Pings gesendet, die Antwort wurde jedoch gelöscht.

Bearbeiten:Leider weiß ich nicht, was die Ursache für das Löschen dieser Route war. Wie Sie sehen, stand es in der Routing-Tabelle oben. Ich habe versucht, einen Routenbefehl in /etc/network/interfaces einzufügen, aber dann hatte ich zwei doppelte, identische Routen, also habe ich ihn wieder entfernt.Es war meinAbonnierenKonfiguration, die dazu führte, dass diese Route gelöscht wurde: Beim Einrichten des eth1-Adapters hatte ich eine /32-Netzmaske (also einen Host) anstelle von /24 (für das LAN) angegeben.

Durch Testen eines Debian-Clients konnte ich dies herausfinden; danach funktionierte es, beim Windows 7-Client jedoch nicht.

Problem 2: Windows 7 Firewall/Konfiguration

Es gab zwei Probleme mit der Windows-Einrichtung.

In Windows muss für den TAP-Adapter das private Profil „Arbeit“ eingestellt sein

Der Verdienst für diesen Abschnitt geht an kalwi

Update vom 11.06.2020

Sie können eine Schnittstelle mit den folgenden beiden Powershell-Befehlen auf privat setzen:

# this first one will let you see the available connections, 
# find the interface index of the one you would like to change
Get-NetConnectionProfile
Set-NetConnectionProfile -InterfaceIndex NN -NetworkCategory Private

Im „Netzwerk- und Freigabecenter“ sollten Sie (mindestens) 2 „aktive Netzwerke“ sehen. Ich hatte das drahtlose Netzwerk und dann ein „Nicht identifiziertes Netzwerk“. Letzteres ist das OpenVPN TAP-Gerät und es hatte ein Parkbank-Symbol, was bedeutet, dass es als öffentlich und nicht vertrauenswürdig behandelt wurde. Um dies ändern zu können, müssen Sie ein Standard-Gateway für den Adapter hinzufügen.

Starten Sie ein DOS/Cygwin-Terminalals Administrator. (Starten Sie Orb > suchen Sie nach CMD > klicken Sie mit der rechten Maustaste darauf > führen Sie es als Administrator aus).

Dann führen Sie dies aus route print -4. Sie sehen eine Schnittstellenliste. Jede Zeile beginnt mit einer Nummer und rechts sehen Sie den Namen. Identifizieren Sie die Schnittstellennummer für den TAP-Win32-Adapter. Meine war 17.

Fügen Sie nun die Route hinzu:

route -p add 0.0.0.0 mask 0.0.0.0 1.2.3.4 metric 500 if 17

Dabei muss 1.2.3.4 die IP Ihres OpenVPN-Gateways sein (angezeigt in der Spalte „Gateway“ in der Ausgabe des vorherigen Befehls) und 17 muss Ihre TAP-Schnittstellennummer sein. Die -pOption macht die Route permanent. Ich habe es zum Testen zunächst ohne diese Option gemacht.Dies setzt voraus, dass sich die OpenVPN-Gateway-IP des Clients zwischen den Verbindungen nicht ändert..

Sobald Sie dies getan haben, sollte ein Dialogfeld erscheinen, in dem Sie aufgefordert werden, das neue Netzwerk zu klassifizieren. Wählen SieArbeiten.

Zu diesem Zeitpunkt konnte ich Datenverkehr aus meinem Firmen-LAN an den Client senden (getestet mit Netcat), Pings blieben jedoch weiterhin unbeantwortet.

Weisen Sie Windows an, Pings (ICMPv4) zuzulassen.

Starten Sie Orb > Windows-Firewall mit erweiterter Sicherheit. Gehen Sie dann zu Eingehende Regeln und Neue Regel …

  • Benutzerdefinierte Regel
  • Alle Programme
  • Protokoll: ICMPv4
  • Erlauben Sie die Verbindung
  • Auf privates Profil bewerben
  • Nennen Sie es.

Schließlich wurden Pings zurückgegeben.

verwandte Informationen