Der Tunnel steht, warum scheitert der private Name trotzdem?

Ein funktionierender Tunnel bedeutet nicht, dass der Client den richtigen Resolver gefragt hat. Prüfen Sie, wer geantwortet hat, und leiten Sie dann nur die Zone weiter, die es wirklich braucht.

An der Verbindung sieht alles richtig aus: Der Tunnel steht und die Konsole zeigt den privaten Endpunkt, doch jede Anfrage scheitert an der Namensauflösung. Der natürliche Schritt ist, den Tunnel zu beschuldigen, der sich meist als unschuldig erweist. Die Abfrage geht an einen Server, der nichts über die private Zone weiß. Keine Routing-Änderung wird diese Antwort ändern, denn das Problem ist, wer gefragt wurde.

Welcher Resolver hat die Abfrage erreicht?

Finden Sie den Resolver, der an jeder Verbindung hängt, bevor Sie überhaupt auf den Tunnel schauen. Linux zeigt Server pro Verbindung über den Resolver-Statusbefehl, und macOS zeigt bereichsgebundene Resolver im DNS-Konfigurationsdump. Kommt die Antwort noch vom Heimrouter, wurde die Tunnelverbindung nie befragt.

resolvectl status
scutil --dns | head -40
dig +short internal.example.com

Hier werden zwei Stufen vermischt: ein Server, der eine Resolver-Adresse pusht, und ein Client, der sie auf der aktiven Verbindung installiert. Ein Profil kann die Option enthalten, und ein Protokoll kann zeigen, dass sie ankommt, während das Betriebssystem weiter den alten Server verwendet. Vergleichen Sie das Protokoll mit dem, was die Verbindung meldet, und vertrauen Sie der Verbindung.

Verwenden Sie eine Adresse, auf die das Cloud-Netz wirklich antwortet

Cloud-Netze beantworten private Namen üblicherweise über eine reservierte Adresse, die zwei Stellen über der Basis des Bereichs liegt, sodass ein Netz ab 10.0.0.0 auf 10.0.0.2 antwortet. Manche Anbieter veröffentlichen außerdem einen link-lokalen Resolver, der ohne Kenntnis des Bereichs funktioniert, was hilft, wenn das Netz von jemand anderem gebaut wurde. Fragen Sie die Kandidatenadresse direkt ab, bevor Sie sie jemandem pushen. Eine Adresse, die kein Resolver ist, sieht genau wie ein Firewall-Drop aus, weil die Abfrage einfach nie eine Antwort bekommt.

Antwortet die direkte Abfrage aus dem Netz heraus, aber nicht über den Tunnel, ist der Resolver in Ordnung und der Weg zwischen den beiden Punkten nicht. Dieses Ergebnis verlagert die Untersuchung auf Routen, Weiterleitung und Zugriffsregeln statt auf das Client-Profil.

Ein Tunnel trägt den Namensraum nicht

Pakete kommen durch; Namen nicht. Jeder Seite muss gesagt werden, welcher Namensraum zur anderen gehört, und das ist ein separates Objekt, das dem gehört, der die Zone hält. Die übliche Form ist eine Weiterleitung für einen Namensraum, gerichtet auf einen über den Tunnel erreichbaren Resolver.

In der Praxis braucht jede Richtung ihre eigene Regel, denn die Seite, die die Zone besitzt, muss die Abfrage weitersenden. Beide Richtungen benötigen eine geroutete und erlaubte Abfragequelle, und die antwortende Seite muss Antworten durch den Tunnel zurückschicken statt ins Internet. Halten Sie die Weiterleitung eng, sodass nur der private Namensraum von der Verbindung abhängt. Jede Abfrage darüber zu schicken macht aus einer kleinen Abhängigkeit einen Totalausfall in dem Moment, in dem der Tunnel wegfällt.

Gehen Sie die Grenzen der Reihe nach durch

Testen Sie den auf der aktiven Verbindung installierten Resolver, dann eine direkte Abfrage an diesen Resolver, dann dieselbe Abfrage von der Gegenseite und schließlich die Anwendung, die denselben Namen verwendet. Jeder Schritt isoliert eine Grenze, sodass ein Fehler zeigt, wo Sie nachsehen müssen, statt die Untersuchung neu zu starten. Eine Antwort, die funktioniert, während die Anwendung scheitert, deutet auf Zertifikatsvertrauen oder eine API-Richtlinie statt auf DNS hin. Diese Fehler sind real, und keine Resolver-Änderung wird sie beheben.

Notieren Sie, welcher Schritt fehlgeschlagen ist. Diese eine Zeile ist es, was die nächste Person braucht, und das Aufschreiben dauert zehn Sekunden.

Halten Sie die Kette dort, wo die nächste Person sie findet

Halten Sie den gepushten Resolver, die Weiterleitungsregel, die erlaubte Abfragequelle und den antwortenden Endpunkt an einer Stelle fest. Wenn der private Name wieder scheitert, zeigt der Eintrag, ob der Tunnel sich verschoben hat, sich die Resolver-Adresse geändert hat oder eine Regel verengt wurde. Ohne ihn beginnt jeder Vorfall bei null und endet bei denselben drei Vermutungen.

Halten Sie den Eintrag kurz genug, um korrekt zu bleiben: vier Zeilen, ein Datum und der Name dessen, der jeden Teil besitzt. Ein veralteter Eintrag ist schlimmer als keiner, denn er wirkt maßgeblich, während er falsch ist.

Ähnliche Artikel