Warum eine VPN-Ressource funktioniert und eine andere in eine Zeitüberschreitung läuft

Ein funktionierender privater Dienst ist eine Kontrolle, kein Versprechen. Vergleichen Sie Adressen, Ports, Antwortphasen und Identitäten, um zu finden, was dem fehlschlagenden fehlt.

Ein privater Dienst lädt durch den Tunnel, der nächste läuft in eine Zeitüberschreitung, und die Versuchung ist, das gesamte Clientprofil neu aufzubauen. Der funktionierende Dienst ist als Kontrolle nützlicher denn als Grund, von vorn zu beginnen. Er beweist, dass ein Ziel, ein Port und ein Autorisierungspfad erfüllt wurden, und nichts darüber hinaus.

Zwei Dienste am selben Gateway können über verschiedene Adressfamilien, verschiedene Subnetze und unterschiedliche Richtlinien erreicht werden.

Trennen Sie den funktionierenden vom fehlschlagenden Ablauf

Behandeln Sie jeden Dienst als eigenen Ablauf und nicht als Symptom des VPN. Ein beispielhafter Client kann portal.corp.example unter 172.20.4.15:443 öffnen und trotzdem eine Datenbank unter 172.20.9.40:5432 nicht erreichen, weil das zwei Ziele mit zwei Regelsätzen sind. Schreiben Sie beide Zeilen auf, bevor Sie etwas ändern, einschließlich Port und Protokoll, denn eine Regel, die TCP 443 auf einem Host erlaubt, sagt nichts über TCP 5432 auf demselben Host.

Die fehlschlagende Zeile ist die, die untersucht werden muss. Die funktionierende Zeile sagt nur, wo die Grundlinie liegt, und sie wird nach jeder Änderung der Vergleichspunkt sein.

Vergleichen Sie Adressen, bevor Sie Namen vergleichen

Lösen Sie jeden vollständigen Namen über die Richtlinie auf, die die Anwendung tatsächlich verwendet, und notieren Sie dann die gewählte Adressfamilie. Ein Name kann eine IPv6-Adresse zurückgeben, während ein anderer IPv4 zurückgibt, und eine alte zwischengespeicherte Antwort kann eine Anfrage an eine öffentliche Adresse schicken, die mit dem privaten Dienst nichts zu tun hat.

ip route get 172.20.4.15
ip route get 172.20.9.40
ip -6 route get 2001:db8:60::20

Die Abfrage beantwortet eine enge Frage: Welche Route würde dieser Host für dieses Ziel wählen, gegeben die aktuellen Tabellen und Richtlinienregeln. Eine Route für 172.20.4.0/24 deckt 172.20.9.0/24 nicht ab, und ein zweiter Netzwerkmanager oder eine lokale Route mit besserer Spezifität kann den Tunnel still überschreiben. Wiederholen Sie die Abfrage innerhalb des Namespace oder mit der Markierung, die die Anwendung verwendet, wenn diese sich von Ihrer Shell unterscheiden. Notieren Sie auch die Schnittstelle, über die das Paket das System verlässt, denn die Routentabelle kann eine Schnittstelle nennen, während Policy-Routing den Ablauf über eine andere schickt.

Eine passende Route ist eine notwendige Bedingung, keine Erlaubnis. Sie sagt, dass das Paket irgendwohin kann, und nichts darüber, ob eine Firewall, ein Autorisierungsdienst oder der Host selbst es annimmt.

Protokoll und Antwortphase zeigen, wo es stoppt

Eine Ping-Antwort beweist nicht, dass ein Datenbankport offen ist, und eine erfolgreiche HTTPS-Seite autorisiert keine Dateifreigabe auf derselben Maschine. Notieren Sie, was tatsächlich zurückkam, statt jeden Fehler in eine Kategorie zu ebnen. Eine Zeitüberschreitung, ein Reset, ein TLS-Identitätsfehler und eine Ablehnung auf Anwendungsebene deuten jeweils auf eine andere Schicht.

Der Unterschied ist wichtig, weil die Korrekturen auseinandergehen. Stille bedeutet meist ein Routen-, Firewall- oder Übersetzungsproblem auf dem Weg. Ein sofortiger Reset deutet darauf hin, dass etwas den Host erreicht und den Port abgelehnt hat. Ein Zertifikatsfehler bedeutet, dass die Verbindung ankam und der Name nicht passte, was ein Konfigurationsproblem und kein Erreichbarkeitsproblem ist. Eine Anwendungsablehnung bedeutet, dass das Netzwerk seine Arbeit getan hat und die Identität danach abgelehnt wurde.

Wenn eine Ressource über ein Gateway veröffentlicht wird, vergleichen Sie die Quelladresse, die das Ziel sieht, mit der Quelle, die Ihr Client zu verwenden glaubt. Eine Anfrage, die vom Gateway selbst ausgeht, kann erfolgreich sein, während dieselbe Anfrage von einem Client scheitert, weil die beiden von verschiedenen Adressen kommen und auf verschiedene Regeln treffen.

Ändern Sie eine Variable und führen Sie beide Anfragen erneut aus

Identität ist der letzte Ort, an den Menschen schauen, und der erste, an dem eine korrekte Ablehnung auftaucht. Die VPN-Anmeldung, die Verzeichnisgruppe und das Anwendungskonto sind drei getrennte Identitäten, die auseinanderlaufen können. Zugang zu einem Portal bedeutet nie Zugang zur dahinterliegenden Datenbank, und ein Name in einem Verzeichnis erzeugt keine Zeile in einem anderen. Wenn der Dienst außerhalb des vorgesehenen Bereichs des Benutzers liegt, ist die Ablehnung das System, das funktioniert.

Bitten Sie den Ressourceninhaber, die vorgesehene Berechtigung zu bestätigen, statt eine breite Route hinzuzufügen oder eine Gruppe testweise zu öffnen. Das Netzwerk zu erweitern, um einen Punkt zu beweisen, ist der Weg, auf dem eine vorübergehende Diagnose zu einer dauerhaften Exposition wird, und es zerstört die Kontrolle, mit der Sie begonnen haben. Eine nachgewiesene Abweichung pro Iteration genügt: eine fehlende Route, eine falsche Adressfamilie, ein blockierter Port oder eine fehlende Gruppenmitgliedschaft.

Wiederholen Sie nach jeder Änderung beide Anfragen und halten Sie die Ausgaben nebeneinander. Die Untersuchung endet, wenn der fehlschlagende Dienst unter seiner eigenen Richtlinie funktioniert, während der funktionierende Dienst und die Ablehnungen, die Sie weiterhin erwarten, sich genau wie zuvor verhalten.

Ähnliche Artikel