Blockiert die Firewall das VPN? Eine Prüfung Schritt für Schritt

Ein einziger VPN-Timeout beweist, dass keine brauchbare Antwort ankam, und nichts darüber, warum. Das Profil kann den falschen Port nennen, der Server kann ausgefallen sein, oder die Anfrage kann ohne funktionierenden Rückweg ankommen. Jeder dieser Fälle hinterlässt eine andere Spur, und die Spur sagt Ihnen, welche Regel Sie anfassen müssen. Arbeiten Sie die vier Stufen unten der Reihe nach ab. Hören Sie auf, sobald eine davon das Symptom erklärt.

Schritt 1: Server und Transport bestätigen

Lesen Sie Servername, Transport und Port aus dem aktuellen Profil des Betreibers und nicht aus einer lokalen Änderung. Ein auf Ihrem Laptop geänderter Port kann keinen Listener auf einem öffentlichen Server erzeugen, und diese Abweichung erzeugt einen Timeout, der mit einer Blockade identisch ist. Bietet das Profil einen unterstützten alternativen Transport, notieren Sie ihn als Rückfalloption und nicht als Lösung. Lösen Sie den Namen auf und vergleichen Sie die Antwort mit der Adresse, die der Betreiber veröffentlicht hat.

Ein veralteter DNS-Eintrag schickt den Client zu einem Host, der nie geantwortet hat. Das ist ein weiterer Fehler, der einen Filter nachahmt, und er kostet eine Abfrage, um ihn auszuschließen.

Schreiben Sie beide Werte ins Ticket. Jeder spätere Vergleich nutzt sie, und ein Ticket ohne sie beginnt die Untersuchung von vorn.

Schritt 2: den Pfad mit einem kontrollierten Vergleich beweisen

Halten Sie Gerät und Profil unverändert und versuchen Sie ein anderes vertrauenswürdiges Zugangsnetz. Kommt der Tunnel dort hoch, ist der ursprüngliche Pfad oder seine Richtlinie der Unterschied. Arbeitet ein zweites freigegebenes Gerät im ursprünglichen Netz, ist das erste Gerät der Unterschied. Einer dieser beiden Vergleiche ist fast immer entscheidend.

Schließen Sie zuerst jede legitime Netzanmeldung ab, denn ein Captive Portal sieht wie eine Blockade aus, bis es abgeschlossen ist.

Testen Sie den Port, den Sie tatsächlich nutzen, und behandeln Sie ein TCP-Ergebnis als Information nur über TCP.

Resolve-DnsName vpn.corp.example
tracert -h 8 -w 500 vpn.corp.example
Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed

Ein erfolgreicher TCP-Handshake auf 443 sagt, dass dort ein Listener geantwortet hat. Er sagt nichts über einen UDP-Listener auf 51820 und nichts darüber, ob die Aushandlung abgeschlossen wurde.

Schritt 3: die Sicherheitsereignisse für den Moment des Fehlers lesen

Firewall-Ereignisse sind der stärkste verfügbare Beweis, und sie tragen einen Vorbehalt, den man zuerst nennen sollte. In vielen Standardprofilen ist die Protokollierung abgeschaltet, prüfen Sie also, ob das betreffende Profil Drops protokolliert, bevor Sie ein leeres Protokoll als Beweis der Unschuld lesen. Ist die Protokollierung an, nennt das Ereignis die Regel, die Richtung und die Adressen, also genau das, was eine Regeländerung braucht. Anwendungsregeln und Portregeln sind getrennte Objekte, und verwaltete Richtlinien können eine lokale Einstellung überstimmen. Bestätigen Sie, welchen Client und welchen Dienst eine Regel tatsächlich abdeckt.

Sammeln Sie den Profilzustand und die letzten Ereignisse von der Maschine, die ausgefallen ist, nicht von einem benachbarten Host.

Vergleichen Sie die Ereigniszeit mit der Zeit Ihres Testversuchs, denn ein passender Regelname mit anderem Zeitstempel ist ein Zufall.

Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, LogBlocked
Get-NetFirewallRule -Enabled True -Direction Outbound | Where-Object DisplayName -match 'VPN'
Get-WinEvent -LogName 'Microsoft-Windows-Windows Firewall With Advanced Security/Firewall' -MaxEvents 20

Fragen Sie auf einem Server, den Sie administrieren, ob die Anfrage überhaupt beim Listener ankam. Ein ankommendes Paket ohne Antwort ist ein Weiterleitungs- oder Rückrouteproblem. Eine Anfrage, die nie auftaucht, ist ein Filter- oder Adressierungsproblem.

Schritt 4: Weiterleitung testen, nachdem der Tunnel steht

Eine Firewall kann die Sitzung erlauben und trotzdem alles verweigern, was die Sitzung erreichen will. Weiterleitungs-Sysctls, NAT-Regeln und Rückrouten liegen alle nach der Authentifizierung, und eine pauschale Ausnahme für den VPN-Port repariert keine davon. Testen Sie ein internes Ziel und ein Internetziel getrennt, weil sie meist aus verschiedenen Gründen scheitern. Scheitern interne Namen, während Adressen funktionieren, schauen Sie vor jeder Regel auf das geschobene DNS.

Führen Sie die drei Prüfungen unten auf dem Server aus, während ein Client verbunden ist und die fehlschlagende Anfrage versucht.

Die Zähler auf dem Tunnel-Interface sind der Punkt, denn sie zeigen, ob Pakete hereinkamen und ob etwas hinausging.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -n -E 'forward|masquerade'
tcpdump -ni tun0 -c 10

Wenn Pakete am Tunnel ankommen und nichts in Richtung Ziel hinausgeht, ist Weiterleitung oder NAT der Verdächtige. Wenn gar nichts ankommt, steht die Sitzung, aber der Client sendet nicht, und die Routentabelle des Clients ist der Ort zum Nachsehen.

Die Korrektur prüfen und entfernen, was nicht geholfen hat

Wiederholen Sie nach einer genehmigten Korrektur genau den Test, der fehlgeschlagen ist, und halten Sie das Ergebnis gegen dasselbe Profil und Gerät fest. Entfernen Sie dann jede vorübergehende Ausnahme, die das Ergebnis nicht verändert hat, denn ungenutzte Ausnahmen sammeln sich an, und jede ist eine Entscheidung, an die sich niemand erinnert. Halten Sie den Rest eng: ein Ziel, ein Port, eine Richtung, ein Verantwortlicher.

Führen Sie dieselben drei Befehle erneut aus und vergleichen Sie sie mit den Ausgaben, die Sie vor der Änderung gespeichert haben.

Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed
tracert -h 8 -w 500 vpn.corp.example
Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match 'VPN' | Select-Object DisplayName, Action

Wenn das Vergleichsnetz funktioniert, das ursprüngliche Netz weiterhin scheitert und die Ereignisse leer bleiben, ist der Pfad und nicht der Host der verbleibende Verdächtige. Geben Sie das als konkrete Aussage an den Netzverantwortlichen weiter, mit beiden Vergleichsergebnissen im Anhang. Das ist ein besserer Ort zum Aufhören als ein deaktiviertes Firewall-Profil.