Fallback-Lease nach der Rückkehr des Site-Tunnels: erneuern oder warten?

Site-Strecke steht, Tunnel aufgebaut, und die Rechner der Filiale erreichen den Dateiserver weiterhin nicht. Während der Störung liefen zwei Uhren, und nur eine davon ist abgelaufen. Der Tunnel erholte sich, als der verschlüsselte Pfad zurückkam; die Adresse jedes Clients erholt sich, wenn sein aktueller Lease endet oder ersetzt wird. Der Vergleich dieser beiden Zeitlinien erklärt die Lücke schneller als das Lesen von Firewall-Protokollen.

Zwei Uhren, und eine davon ist nicht der Tunnel

Mit DHCP über VPN plus lokalem Fallback kann das Gerät temporäre lokale Leases ausgeben, solange der entfernte DHCP-Pfad nicht verfügbar ist. Die temporäre Dauer wird meist in Minuten gezählt, was kurz genug ist, um das Problem zu verbergen, und lang genug, um eine kurze Störung zu überleben. Wenn der Tunnel zurückkommt, stellt der Fallback das Angebot dieser Leases ein. Er greift nicht in einen Client hinein und kündigt den Lease, den dieser bereits hält. Dieser Client behält Adresse, Maske, Gateway und Resolver bis zur Erneuerung oder zum Ablauf, weshalb ein gesunder Tunnel und ein defekter Rechner für den Rest des Leases koexistieren können.

Halten Sie die Implementierung und die Softwareversion an dieser Aussage fest. Timernamen und Standardwerte unterscheiden sich zwischen SonicOS-Versionen, und eine ältere Oberfläche beweist nicht, was eine neuere tut.

Vergleichen Sie die beiden Wiederherstellungswege

Weg A ist das Warten. Er kostet nichts, riskiert nichts und überlässt jedem Client die Erneuerung nach seinem eigenen Zeitplan. Weg B ist das erzwungene Freigeben und Erneuern auf dem betroffenen Client, was die vorgesehene Adresse sofort liefert, aber alles unterbricht, was der Client gerade tut. Auf einem einzelnen Rechner ist die erzwungene Erneuerung meist der schnellere Weg und leicht zu begründen. In einem Labor oder an einer Kassenstation mitten in einer Transaktion ist das Warten die sicherere Wahl, und eine geplante Erneuerung außerhalb der Geschäftszeiten schlägt beides.

ipconfig /all
ipconfig /release
ipconfig /renew

Lesen Sie die Ausgabe, bevor Sie etwas freigeben. Wenn Adresse, Gateway und DNS bereits zum normalen Bereich passen, hat sich der Client selbst erholt und das verbleibende Problem liegt woanders. Auf einem Linux-Client ist das Äquivalent eine Lease-Freigabe und -Erneuerung über den Netzwerkmanager statt einer von Hand bearbeiteten Adresse, weil der Manager Ihre Änderung sonst beim nächsten Ereignis überschreibt.

Lesen Sie das Angebot, nicht nur die Adresse

Die Adresse allein sagt nicht, wer sie geliefert hat. Entscheidend sind die Serverkennung im Angebot, die Lease-Zeit und ob Gateway und Resolver zum Fallback-Bereich oder zum normalen passen.

tcpdump -ni any 'port 67 or port 68'

Zeichnen Sie während der Erneuerung auf, denn eine stille Schnittstelle sagt Ihnen, dass der Client nie gefragt hat. Kommt das Angebot vom lokalen Fallback, während der Tunnel steht, behandelt die Auswahllogik den entfernten Pfad weiterhin als nicht verfügbar, und erzwungene Erneuerungen auf den Clients wiederholen nur dasselbe Ergebnis. Korrelieren Sie die Aufzeichnung mit den Tunnelereignissen auf derselben Uhr. Eine Schlüsselerneuerung oder ein kurzer Ausfall, der Sekunden vor der Anfrage des Clients endet, ist eine plausible Ursache; ein sauberer Tunnel mit einer Fallback-Antwort ist ein Konfigurationsproblem im Auswahlpfad.

Wo sich der Vergleich umkehrt

Sind viele Clients gleichzeitig betroffen, werden Erneuerungen pro Client zu einer Warteschlange von Unterbrechungen und zu einem Anruf beim Support. Schauen Sie in diesem Fall auf den Fallback-Bereich und das Wiederherstellungsverfahren statt auf die Clients, weil die Gruppe gemeinsam zurückkam und gemeinsam wieder zurückkommen wird.

Ist nur ein Client betroffen, während seine Nachbarn in Ordnung sind, gilt das Gegenteil: der Lease dieses Clients, seine Reservierung oder das Verhalten seines eigenen DHCP-Clients ist die Variable, und eine standortweite Änderung ist das falsche Werkzeug.

Statische Adressen und Reservierungen brauchen eine dritte Antwort. Ein an eine Adresse gebundener Client lässt sich durch Erneuerung nicht retten, und eine Reservierung, die mit dem Fallback-Bereich kollidiert, erzeugt ein Duplikat, das wie ein Routingfehler aussieht, bis Sie die beiden Adresspläne vergleichen.

Schreiben Sie das Exit-Verfahren auf

Entscheiden Sie vorab, wofür der Fallback da ist, wie lange ein Client seine temporäre Adresse behalten darf und wer während der Geschäftszeiten eine Erneuerung erzwingen darf. Schreiben Sie die Antwort dorthin, wo der Bereitschaftstechniker sie findet, neben die Bereichsdefinition. Testen Sie es dann einmal bewusst: Trennen Sie den Tunnel, beobachten Sie, was der Client erhält, stellen Sie den Tunnel wieder her und notieren Sie, wie lange der Client braucht, um seine normalen Einstellungen zurückzubekommen. Diese eine Übung ersetzt den größten Teil des Rätselratens, wenn die Site-Strecke das nächste Mal flattert.

Schließen Sie ab, indem Sie die Ressource bestätigen, nicht die Adresse. Den Dateiserver erreichen, seinen Namen auflösen und das Internet erreichen sind drei getrennte Prüfungen, und nur die letzte war nie zweifelhaft.