VPN-Adresse auf der Whitelist und trotzdem blockiert? Verfolgen Sie sie

Die Adresse, die eine VPN-App anzeigt, auf die Whitelist zu setzen, behebt selten einen blockierten Port, und das Paket erklärt, warum. Die Firewall ignoriert Ihre Regel nicht; sie bewertet eine Quelladresse, die nichts auf dem Client-Bildschirm zeigt. Bis das Ziel diesen Wert meldet, ist jede Regeländerung eine Vermutung.

Beginnen Sie bei der Anfrage, die den Dienst erreicht. Die Tunneladresse, die Ausgangsadresse und jede Übersetzung dazwischen bleiben Hypothesen, bis das Ziel eine davon bestätigt.

Die Adresse in der App ist nicht die ankommende

Eine VPN-Verbindung trägt mindestens vier Adressen, die es wert sind, einzeln benannt zu werden: den Server-Endpunkt, die Ihrem Client zugewiesene innere Tunneladresse, die lokale Wi-Fi- oder Ethernet-Adresse und die öffentliche Adresse, die eine Website sieht, nachdem der Verkehr den Anbieter verlassen hat. Ein Client-Fenster zeigt möglicherweise nur die zweite. Benennen Sie alle vier, bevor Sie eine Regel benennen. Beim Split-Tunneling können Anfragen an ein öffentliches Ziel den Tunnel vollständig umgehen, sodass die fehlschlagende Sitzung nicht die ist, von der der Benutzer glaubt, sie gestartet zu haben.

Entscheiden Sie, welche dieser vier die Regel zulassen soll, und prüfen Sie sie dann von der anderen Seite. Wenn die Anforderung wirklich eine Büroadresse ist, ist die Bedingung die Route plus die Ausgangsregelung dieses Standorts, und eine Verbindung mit der Bezeichnung Office VPN liefert keines von beidem für sich.

Verfolgen Sie eine Anfrage bis zu ihrer Filtergrenze

Bestätigen Sie die Zieladresse und den Port, die der Client verwendet, und prüfen Sie dann, ob dieses Ziel dem Pfad folgt, den Sie annehmen. Ein veröffentlichter Container-Port, ein Reverse-Proxy oder eine Portweiterleitung können die Entscheidung auf einen Host verschieben, den Sie nie bearbeitet haben. Jeder dieser Sprünge kann eine eigene Richtlinie tragen. Den Pfad zuerst festzustellen erspart Ihnen die Korrektur einer Regel, die kein Paket je erreicht.

Lesen Sie auf einem autorisierten Linux-Host die aktiven Regeln der Reihe nach, bevor Sie sie ändern. Weitergeleitete Dienste und Containerdienste springen oft in ihre eigene Kette, prüfen Sie daher auch das Sprungziel und nicht nur das endgültige Urteil.

iptables -vnL INPUT --line-numbers
iptables -S INPUT | head -n 40
ss -ltnp | grep -E ':(443|9443)\b'

Nennen Sie die passende Regelnummer im Ticket. Ohne sie kann der nächste Leser nicht erkennen, welche Änderung das Ergebnis verändert hat. Eine Regelnummer ohne Zeitstempel bleibt mehrdeutig.

Prüfen Sie den Pfad mit einer begrenzten Aufzeichnung

Eine harmlose Anfrage und eine schmale Aufzeichnung klären die Frage, die immer wieder aufkommt. Filtern Sie nach Zielport und dem untersuchten Host, begrenzen Sie die Paketanzahl und beenden Sie die Aufzeichnung, sobald die Anfrage abgeschlossen ist.

tcpdump -ni any 'tcp dst port 9443' -c 20

Vergleichen Sie drei Werte nebeneinander: die Quelle in der Aufzeichnung, die Quelle, die die passende Regel nennt, und die Ablehnung, die die Anwendung protokolliert hat. Sie können alle abweichen, und nur die erste erklärt einen von einer IP-Regel entschiedenen Drop. Ein weitergeleiteter HTTP-Header gehört zur Proxy-Schicht, daher beschreibt ein Protokoll, das diesen Header zitiert, nicht die Quelle, die die Firewall bewertet hat.

Lesen Sie die Kettenreihenfolge, nicht nur die Regel

Die iptables-Referenz dokumentiert den geordneten Durchlauf, weshalb ein Allow unterhalb einer passenden terminalen Ablehnung das Paket nie rettet. Eine früher akzeptierte Verbindung kann sich auch anders verhalten als eine neue, daher sagt ein alter Erfolg nichts über die neue Regel. Finden Sie die Ablehnung oder den Drop oberhalb Ihres Allows, bevor Sie annehmen, das Allow sei falsch. Zähler pro Regel zeigen Ihnen außerdem, welche Regel das Paket gesehen hat.

Eine Regel zu löschen, um zu sehen, was passiert, ist eine Änderung, keine Beobachtung. Lesen Sie die Zähler, notieren Sie die Regelnummer und bewahren Sie die ursprüngliche Richtlinie im Änderungsprotokoll auf. Wenn ein Test unvermeidlich ist, führen Sie ihn auf einer Kopie der Kette aus.

Ändern Sie die Regel, die ihr Eigentümer kontrolliert

Aktualisieren Sie nur die beabsichtigte Quell- und Dienstrichlinie, und zwar über denjenigen, dem sie gehört. Ein gemeinsam genutzter übersetzter Ausgang kann viele Benutzer gleichzeitig vertreten, daher authentifiziert das Zulassen dieser Adresse niemanden, und die Anwendungsberechtigungen dahinter bleiben, wo sie sind.

Wenn sich die Adresse weiter bewegt, ist die dauerhafte Antwort ein stabiler Ausgang oder ein authentifizierter Kanal, keine längere Ausnahmeliste. Halten Sie die beobachtete Quelle, den Zielport und die Regelnummer fest.