☰

OpenVPN-Verbindung wird alle 2 Minuten zurückgesetzt

tag-icon • tag-icon openvpn tunnelblick
OpenVPN-Verbindung wird alle 2 Minuten zurückgesetzt

Ich habe einen OpenVPN-Server, der unter Ubuntu in AWS läuft, und verwende Tunnelblick unter macOS, um mich damit zu verbinden. Ich habe keine Probleme, mich mit anderen VPN-Servern zu verbinden, aber bei diesem scheint es alle 2 Minuten zu einem Timeout/Reset zu kommen.

Mein OVPN-Profil:

client
dev tun
proto udp
remote ............... 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
remote-cert-tls server
cipher AES-256-CBC
verb 3
cipher AES-128-CBC
auth SHA256
key-direction 1
<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>
<cert>
Certificate:
    Data:
        Version: 3 (0x2)
...
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
</key>
<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
...
-----END OpenVPN Static key V1-----
</tls-auth>

Beim Herstellen einer Verbindung überträgt der Server die folgenden Einstellungen:

PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 8.8.8.8,route 172.16.0.0 255.255.240.0,route 172.16.16.0 255.255.240.0,route 172.16.128.0 255.255.240.0,route 172.16.144.0 255.255.240.0,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5,peer-id 1,cipher AES-256-GCM'

(besonders beachten ping 10,ping-restart 120)

Wenn man die Protokollebene auf dem Client erhöht, sieht es so aus, als ob die Verbindung Datenpakete sendet:

2021-09-03 11:31:21.848620 UDP WRITE [62] to [AF_INET]...:1194: P_ACK_V1 kid=0 pid=[ #13 ] [ 6 ]
2021-09-03 11:31:21.848768 UDP WRITE [130] to [AF_INET]...:1194: P_DATA_V2 kid=0 DATA len=129
2021-09-03 11:31:21.848856 UDP WRITE [226] to [AF_INET]...:1194: P_DATA_V2 kid=0 DATA len=225

Allerdings bricht die Verbindung immer nach etwa 2 Minuten ab. Im Client-Protokoll heißt es:

2021-09-03 11:40:26.121900 [cc-vpn] Inactivity timeout (--ping-restart), restarting
2021-09-03 11:40:26.122379 SIGUSR1[soft,ping-restart] received, process restarting
2021-09-03 11:40:26.122504 MANAGEMENT: >STATE:1630683626,RECONNECTING,ping-restart,,,,,
2021-09-03 11:40:26.448969 MANAGEMENT: CMD 'hold release'

Außer einem Neustart der Verbindung steht im Serverprotokoll nichts.

Das 2-Minuten-Timeout ist angesichts der an den Client gesendeten Einstellung sinnvoll ping-restart 120, aber mir ist nicht klar, warum er denkt, er sei inaktiv gewesen. Was übersehe ich? Gibt es eine Einstellung auf dem Client, die verhindert, dass der Ping ordnungsgemäß an den Server gesendet wird?

Insbesondere das Hinzufügen von Ping/Ping-Restart zur Client-Konfiguration scheint nicht zu helfen (ich gehe davon aus, dass es ohnehin durch den Server-PUSH überschrieben würde).

Wie kann ich das debuggen und herausfinden, warum die Verbindung nicht aufrechterhalten wird?

Antwort1

Dies ist oft ein Zeichen dafür, dass mehrere Clients dieses Schlüssel-/Zertifikatpaar verwenden:

  • (1) authentifiziert
  • (2) authentifiziert sich; der Server sieht das gleiche Zertifikat und denkt daher, dass es sich nur um eine ersetzte Verbindung handelt, und (1) empfängt keine Keepalive-Pings mehr
  • (1) verpasst einige Pings, entscheidet, dass die Verbindung unterbrochen ist und stellt die Verbindung erneut her. Jetzt (2) empfängt keine Pings mehr
  • (2) verpasst einige Pings, entscheidet, dass die Verbindung unterbrochen ist und stellt die Verbindung erneut her. Jetzt empfängt (1) keine Pings mehr

Sie sehen, was vor sich geht, und es ist auch klar, welche Rolle das festgelegte Inaktivitäts-Timeout ping-restarthier spielt.

Damit dies nicht passiert, müssen Sie Ihre VPN-CA sorgfältig verwalten. Insbesondere:

  • Behalten Sie den Überblick, wo Ihre Schlüssel installiert sind und wer für das Gerät verantwortlich ist, auf dem jeder Schlüssel installiert ist. Sorgen Sie dafür, dass Sie jeden kontaktieren können, der über aktive VPN-Schlüssel verfügt (z. B. indem Sie deren Telefonnummer, E-Mail-Adresse usw. aufzeichnen. Sie können OpenSSL so einrichten, dass es bei der Zertifikatsausstellung nach diesen Daten fragt und diese Daten direkt in Zertifikaten und im CA-Index aufzeichnet).
  • Benutzen Sie niemals den gleichen Schlüssel/das gleiche Zertifikat mehr als einmal. Geben Sie den Schlüssel/das Zertifikat niemals inVorlagen; wenn Sie ein System klonen, löschen Sie dort die Schlüssel. Schlüssel müssen immer neu generiert und zertifiziert werden, wenn das Systembereitgestellt.
  • Wenn ein Benutzer nach einem (weiteren) Schlüssel/Zertifikat fragt, obwohl er bereits ein aktives hat, muss er erklären, warum. Er hat möglicherweise alte Daten verloren, weil das Betriebssystem neu installiert wurde und er vergessen hat, die VPN-Konfiguration zu speichern; oder er braucht einfach ein VPN auf einem zusätzlichen Computer. Oder was auch immer. Wenn Sie ihre Erklärung bewerten, müssen Sie entweder zuerstwiderrufenalten Schlüssel, bevor Sie einen neuen ausstellen, oder geben Sie einen Schlüssel mit einer anderen CN aus, um einen Konflikt zu vermeiden.
  • Weisen Sie Ihre Benutzer an, Ihnen immer mitzuteilen, dass ihr Schlüssel/Zertifikat nicht mehr verwendet wird (es ist verloren gegangen oder der Grund für seine Ausstellung ist nicht mehr bekannt), damit Sie es widerrufen können. Und dann müssen Sie es widerrufen.
  • Sehr wichtig, schulen Sie die BenutzerdringendSie werden benachrichtigt, wenn der Verdacht besteht, dass der Schlüssel/das Zertifikat gestohlen wurde. In diesem Fall müssen Sie es sofort widerrufen.

Dies sind Teile eines Prozesses namens „Netzwerksicherheit“. Ein VPN wäre ohne eine gewisse Disziplin nicht sicher, egal wie perfekt die Software und die hochmoderne Verschlüsselung ist, die es verwendet.

Falls sich jemand fragt, warum OpenVPN diesen Zustand nicht erkennt und ihn nicht in Protokolldateien meldet, wie unten kommentiert: Es wäre zu unzuverlässig und irreführend. Protokolle sollten nur Rohdaten enthalten, und die einzige gut belegte Tatsache ist, dass derselbe CN wiederholt von verschiedenen Standorten aus eine Verbindung herstellt; sie sollten keine Annahmen darüber enthalten, warum dies passiert ist.

Wenn Sie die Sicherheitsprozeduren wie oben beschrieben befolgen, tritt das Problem einfach nicht auf. Wenn es passiert, kann es nur bedeuten, dass die Prozedur verletzt wurde. In diesem Fall ist es am sichersten, um die Sicherheit des VPN zu gewährleisten, davon auszugehen, dass der Schlüssel kompromittiert wurde, und das Zertifikat sofort zu widerrufen. Wahrscheinlich wird das VPN für eine Person (deren Schlüssel es war) zusammenbrechen, aber das ist die natürliche Konsequenz vonihreUnfähigkeit, das festgelegte Verfahren einzuhalten: Sie haben Sie nicht darüber informiert, dass sie VPN auf einem Computer nicht verwenden und es auf einen anderen kopiert haben, oder das Zertifikat wurde gestohlen, was auch immer. Nach einer erneuten Schulung zum Thema können Sie ihnen das neue Zertifikat ausstellen.

verwandte Informationen