.png)
Ich habe eine einzelne Windows 10-Box, die keine Verbindung zu meinem Linux OpenVPN-Server herstellt. Ich habe überprüft, ob das Zertifikat gültig ist (und es neu ausgestellt). Das Protokoll (auf dem Client) enthält immer wieder Folgendes:
Di 30. Jan 10:01:40 2018 TCP/UDP: Zuletzt verwendete Remote-Adresse beibehalten: [AF_INET]:443
Di., 30. Januar 2018, 10:01:40 Uhr Socket-Puffer: R=[65536->65536] S=[65536->65536]
Di., 30. Jan. 2018, 10:01:40 Uhr Versuch, eine TCP-Verbindung mit [AF_INET]:443 [nonblock] herzustellen
Di 30. Jan 10:01:41 2018 TCP-Verbindung hergestellt mit [AF_INET]:443
Di 30. Jan 10:01:41 2018 TCP_CLIENT Link lokal: (nicht gebunden)
Di 30. Jan 10:01:41 2018 TCP_CLIENT-Link Remote: [AF_INET]:443
Di., 30. Jan. 2018, 10:01:59 Uhr, TCP_CLIENT lesen: Verbindungs-Timeout (WSAETIMEDOUT) (Code=10060)
Di 30. Jan 10:01:59 2018 Verbindung zurückgesetzt, Neustart [-1]
Di 30. Jan 10:01:59 2018 SIGUSR1[soft,connection-reset] empfangen, Prozess wird neu gestartet
Di., 30. Jan. 2018, 10:01:59 Neustartpause, 300 Sekunden
Während das Zertifikat widerrufen wurde, sah ich den gleichen Protokollinhalt, keine neuen Fehler.
Ich habe überprüft, dass ich von Windows aus über Port 443 per Telnet auf den Server zugreifen kann. Außerdem habe ich überprüft, dass Tracert von der Windows-Box aus keine unerwarteten Ausfälle anzeigt.
Wenn ich mit „grep“ nach dem Server suche, sind in openvpn-status.log (auf dem Server) keine Einträge vorhanden (aber ich kann andere Verbindungen sehen, wenn ich die Datei durchsuche).
Schließlich wird mir mitgeteilt, dass im Netzwerk des Windows-Clients kein Webfiltergerät vorhanden ist.
Was kann ich sonst noch überprüfen? Danke.
Antwort1
Es stellte sich heraus, dass der Kunde über einen Inhaltsfilter verfügte, von dem wir nichts wussten.