VPN-Endpunkt-Zulassungsliste: Die DNS-Aktualisierung, die du vergessen hast

vpn.example.com in eine Firewall-Ausnahme einzutragen fühlt sich an wie ein DNS-Abo. Meist geschieht eine Übersetzung beim Laden, danach hält die Regel Adressen und nichts aktualisiert sie. Zwei Komponenten teilen sich nun die Aufgabe: der Resolver, der antwortet, und die Firewall, die speichert. Die meisten Endpunkt-Ausfälle beginnen dort, wo diese Übergabe nie entworfen wurde.

Ein Hostname in einer Regel ist kein lebendiges Abo

Manche Werkzeuge lösen einen Namen beim Laden der Konfiguration auf; andere behalten einen Hostnamen und lösen ihn nach eigenem Zeitplan neu auf; wieder andere akzeptieren nur Adressen. Die sichtbare Konfiguration sagt selten, welcher Fall gilt. Dokumentationsbeispiele nehmen meist den Ladezeit-Fall an, weshalb der Unterschied Menschen bei einer Migration überrascht. Lies das Verhalten der Implementierung, bevor du annimmst, dass eine Adressänderung bemerkt wird, denn eine veraltete Zulassungsliste sieht genauso aus wie eine funktionierende, bis der Endpunkt umzieht.

Eine Regel, die den richtigen Host nennt, kann trotzdem die falsche Adresse zulassen. Diese Lücke ist der Mythos, kein Tippfehler.

Cache-TTL ist nicht der Timer deiner Firewall

DNS-Einträge haben eine Gültigkeitsdauer, und Resolver cachen Antworten für diesen Zeitraum. Die DNS-Spezifikation definiert dieses Cache-Verhalten, regelt aber DNS-Daten, nicht den separaten Adressspeicher einer Firewall. Eine kurze TTL erzeugt keinen Aktualisierungsjob, wo keiner existiert. Caching findet zudem auf mehr als einer Ebene statt, sodass die Antwort, die ein Terminal sieht, nicht die sein muss, die die Firewall gesehen hat.

Stelle dem tatsächlichen Produkt drei Fragen: wann es auflöst, wo es das Ergebnis speichert und was eine Aktualisierung auslöst. Wenn die Antwort nur beim Start gilt, kann eine langlebige Sitzung die Adresse überleben, zu der sie zugelassen wurde.

dig +short vpn.example.com
resolvectl query vpn.example.com

Entwirf Aktualisierung und Fehler als eine Richtlinie

Eine gepflegte Ausnahme braucht ausdrückliche Antworten: was eine Aktualisierung auslöst, bevor der Client eine neue Adresse wählt, wie sich die erlaubte Menge ändert, ohne ein breites temporäres Fenster zu öffnen, und wann veraltete Einträge entfernt werden. Schreibe diese Antworten neben die Regel.

Wähle das Fehlerverhalten bewusst. Die alte Adresse zu behalten kann eine Sitzung retten und eine veraltete Erlaubnis hinterlassen; die Menge zu leeren kann die Wiederherstellung blockieren. Keines sollte ein zufälliges Ergebnis eines fehlgeschlagenen Lookups sein. Schreibe das gewählte Verhalten ins Runbook, damit der nächste Betreiber unter Druck nicht improvisiert.

Halte auch Bootstrap-DNS eng. Eine bedingungslose Ausnahme für einen öffentlichen Resolver ist ein direkter DNS-Pfad für alles, was sie trifft, nicht nur für den Namen des Endpunkts.

Beweise die Endpunktänderung, nicht die erste Verbindung

Nutze den unterstützten Manager des Clients, wenn er Auflösung und Blockierung bereits koordiniert. Behalte auf einem standortverwalteten PF-Host den Besitz und den Wiederherstellungsplan des Standorts, statt die Hostnamen-Tabellensyntax einer anderen Plattform mit anderem Lebenszyklusverhalten zu kopieren.

Vergleiche mit einem genehmigten, harmlosen Test die vom Client gewählte Adresse mit der aktiven erlaubten Menge vor und nach einer kontrollierten Änderung. Decke einen fehlgeschlagenen Lookup ab, das Löschen eines nicht mehr gültigen Eintrags und, wo unterstützt, eine andere Adressfamilie. Der beabsichtigte Tunnel sollte sich erholen, während unabhängiger direkter Verkehr unter der Richtlinie bleibt. Eine erfolgreiche erste Verbindung beweist nur, dass die anfängliche Übersetzung zufällig korrekt war.