☰

Keine Verbindung zu OpenVPN außerhalb des LAN möglich

tag-icon • tag-icon linux networking router openvpn gentoo
Keine Verbindung zu OpenVPN außerhalb des LAN möglich

Ich habe OpenVPN hinter einem Router eingerichtet und den Port weitergeleitet 1194. Das VPN verwendet das Subnetz 10.3.15.0/24und ist 192.168.1.14im LAN.

Es funktioniert, wenn ich eine lokale Verbindung herstelle oder mich von meinem Heimnetzwerk aus mit der öffentlichen IP verbinde. Aber nicht in anderen Netzwerken, die ich ausprobiert habe.

Ich kann keine Verbindung zum VPN herstellen und erhalte auf dem Client die Meldung:

Mon Apr 20 13:50:42 2015 UDPv4 link local: [undef]
Mon Apr 20 13:50:42 2015 UDPv4 link remote: [AF_INET]83.***.***.***:1194
Mon Apr 20 13:51:42 2015 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Apr 20 13:51:42 2015 TLS Error: TLS handshake failed
Mon Apr 20 13:51:42 2015 SIGUSR1[soft,tls-error] received, process restarting
Mon Apr 20 13:51:42 2015 Restart pause, 2 second(s)

Ich dachte, es könnte ein Firewall-Problem sein, das hier ist aus meinen Iptables:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  10.3.15.0/24         anywhere             ctstate NEW

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Aber ich habe versucht, die Tabelle zu leeren, was nicht funktioniert hat. Und beim Ausführen tcpdump -qni any port 1194gibt es eine Kommunikation (in beiden Fällen):

13:44:35.936684 IP 194.***.***.****.53929 > 192.168.1.14.1194: UDP, length 14
13:44:41.043704 IP 194.***.***.****.22955 > 192.168.1.14.1194: UDP, length 14
13:44:43.063426 IP 194.***.***.****.22955 > 192.168.1.14.1194: UDP, length 14
13:44:43.544690 IP 194.***.***.****.53929 > 192.168.1.14.1194: UDP, length 14

Mir ist auch etwas bei aufgefallen destination port unreachable, aber diese Fehler sind verschwunden.

Dies ist meine Serverkonfiguration:

port 1194
proto udp
dev tun

ca openvpn_certs/host-ca.pem
cert openvpn_certs/host-cert.pem
key openvpn_certs/host-key.pem
dh openvpn_certs/dh1024.pem

server 10.3.15.0 255.255.255.0
route 10.3.15.0 255.255.255.0
ifconfig-pool-persist ipp.txt

push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
push "redirect-gateway def1 bypass-dhcp"
push "remote-gateway 10.3.15.1"

client-to-client
max-clients 20

keepalive 10 120
comp-lzo

user nobody
group nobody

persist-key
persist-tun
status /var/log/openvpn-status.log
log-append /var/log/openvpn.log

verb 11

Hier ist meine Client-Konfiguration:

client
dev vpn
dev-type tun
proto udp
remote server.remote 1194
resolv-retry infinite
nobind
ns-cert-type server
persist-key
persist-tun
pull
ca certs/ca-host.pem
cert certs/cert-local.pem
key certs/key-local.pem
comp-lzo
verb 11

Auf dem Server läuft Alpine Linux, während auf dem Client Gentoo läuft.

Ich stecke fest und weiß nicht, wo ich suchen soll. Irgendwelche Ideen oder Anleitungen?

Danke!

Antwort1

Zunächst einmal bin ich mir nicht sicher, welche Version von OpenVPN Sie verwenden, aber „Remote-Gateway“ ist in v2.3.2 keine gültige Option. Wenn Sie eine ältere Version verwenden, überprüfen Sie Ihre lokale Manpage und entfernen Sie diese Anweisung gegebenenfalls.

Entsprechend derOpenVPN-Wikiist der Fehler „TLS-Schlüsselaushandlung fehlgeschlagen …“ fast immer eine Folge von:

  1. Eine Perimeter-Firewall im Netzwerk des Servers filtert eingehende OpenVPN-Pakete heraus (standardmäßig verwendet OpenVPN die UDP- oder TCP-Portnummer 1194).

    • Dies scheint in Ihrem Fall unwahrscheinlich, aber überprüfen Sie sicherheitshalber die Firewall Ihres Routers.

  2. Eine Software-Firewall, die auf dem OpenVPN-Server selbst läuft, filtert eingehende Verbindungen auf Port 1194.

    • Die von Ihnen bereitgestellte Filtertabelle sieht gut aus, vorausgesetzt, Sie haben die Standard-INPUT-Richtlinie normalerweise auf Akzeptieren eingestellt. Andernfalls müssen Sie UDP-Port 1194 zulassen:

      iptables -A INPUT -p udp -m udp --dport 1194 -j ACCEPT

  3. Ein NAT-Gateway im Netzwerk des Servers verfügt nicht über eine Portweiterleitungsregel für TCP/UDP 1194 an die interne Adresse des OpenVPN-Servercomputers.

  4. Die OpenVPN-Clientkonfiguration enthält in ihrer Konfigurationsdatei nicht die richtige Serveradresse. Die Remote-Direktive in der Clientkonfigurationsdatei muss entweder auf den Server selbst oder auf die öffentliche IP-Adresse des Gateways des Servernetzwerks verweisen.

  5. Die Windows-Firewall blockiert den Zugriff auf die Binärdatei openvpn.exe. Möglicherweise müssen Sie sie auf die Whitelist setzen (zur Liste „Ausnahmen“ hinzufügen), damit OpenVPN funktioniert.

Wenn Sie immer noch Probleme haben, liegt wahrscheinlich ein Problem mit Ihrer Public Key Infrastructure vor. Ich bin nicht vertraut mit Alpine Linux und weiß nicht, ob ihr OpenVPN-Paket mit Easy-RSA geliefert wird, also machen Sie weiter undLaden Sie die neueste Version herunterund extrahieren Sie es an einen geeigneten Ort sowohl auf Ihrem Server als auch auf einem (vorzugsweise) nicht mit dem Netzwerk verbundenen Computer (Ihrer Zertifizierungsstelle). Der Einfachheit halber gehe ich davon aus, dass Ihr Server Anfragen für Clients generiert. Wechseln Sie auf beiden Systemen in das Verzeichnis, in das Sie EasyRSA extrahiert haben, und...

cp vars.example vars
editor ./vars

Entfernen Sie auf dem CA-System die Kommentarzeichen und bearbeiten Sie die Organisationsfelder entsprechend (EASYRSA_REQ_COUNTRY usw.). Ändern Sie auf dem Server optional „set_var EASYRSA_PKI“, sodass es auf einen geeigneten Speicherort verweist (z. B. /etc/openvpn/pki).

Zertifikatsanforderungen auf dem Server generieren:

./easyrsa init-pki
./easyrsa gen-req <your_server_name> nopass
./easyrsa gen-req <some_client_name> nopass

Erstellen Sie auf dem Nicht-Server eine neue Zertifizierungsstelle:

./easyrsa init-pki
./easyrsa build-ca

Kopieren Sie die .req-Dateien in Ihr CA-System, importieren und signieren Sie sie:

./easyrsa import-req server /tmp/<your_server_name>.req
./easyrsa import-req client /tmp/<some_client_name>.req
./easyrsa sign-req server <your_server_name>
./easyrsa sign-req client <some_client_name>

Kopieren Sie die neu signierten Zertifikate sowie das CA-Zertifikat an einen geeigneten Speicherort auf dem Server und dem Client. Generieren Sie dann auf dem Server DH-Parameter:

 ./easyrsa gen-dh

Kopieren Sie abschließend den Client-Schlüssel auf den Client-Computer (sofern er dort noch nicht vorhanden ist) und aktualisieren Sie Ihre Konfigurationen mit den neuen Schlüssel- und Zertifikatsspeicherorten.

Antwort2

Stellen Sie sicher, dass das Zertifikat Ihres Servers mit der Bezeichnung nsCertType=server signiert wurde (dies ist veraltet und nicht die Standardeinstellung, wenn Sie easyrsa3 verwendet haben). Wenn nicht, würde die Anweisung „ns-cert-type server“ in Ihrer Clientkonfiguration dazu führen, dass der TLS-Handshake fehlschlägt. Verwenden Sie stattdessen „remote-cert-tls server“.

verwandte Informationen