Eine VPN-Standardroute in Tabelle 200 verdeckt Ihre LAN-Route

Vier Prüfungen trennen einen Fehler in der Policy-Tabelle von einem Routingfehler: welche Regel gepasst hat, welche Tabelle diese Regel genannt hat, was diese Tabelle enthält und welche Route darin gewonnen hat. Die Haupttabelle wird nicht mehr konsultiert, sobald eine frühere Tabelle eine Route liefert, daher kann ein dort sichtbarer LAN-Eintrag für das Paket, das Sie testen, irrelevant sein. Arbeiten Sie die Prüfungen der Reihe nach ab, und die fehlende Route zeigt sich beim dritten Schritt statt beim vierten.

Die Suche nach dem längsten Präfix findet innerhalb einer Tabelle statt; sie vergleicht nicht die Routen aller Tabellen als eine einzige Liste.

Die Suche endet bei der ersten Tabelle, die antwortet

Nehmen Sie eine Policy, bei der Datenverkehr aus einem Subnetz zuerst Tabelle 200 nachschlägt, Tabelle 200 eine Standardroute durch den Tunnel enthält und die Haupttabelle das LAN-Präfix enthält. Ein Paket an eine LAN-Adresse kann auf diese Standardroute in Tabelle 200 passen und dort anhalten. Weil die Suche eine Route ergeben hat, kommt die spätere Regel der Haupttabelle nie dazu, ihren spezifischeren Eintrag anzubieten. Das Ergebnis ist ein Paket, das in den Tunnel geht, während eine völlig brauchbare LAN-Route ungenutzt bleibt.

Frühere Regeln und die eigene Suche der Maschine nach lokalen Adressen gelten weiterhin, daher muss der Test die Quelle, die Markierung und die Schnittstelle verwenden, die der reale Fluss trägt. Fragen Sie mit etwas anderem ab, und das LAN wird vielleicht korrekt gewählt, was genau den Fehler verdeckt, den Sie suchen.

Setzen Sie die LAN-Ausnahme dorthin, wo sie hingehört

Die gewählte Tabelle kann die benötigten LAN-, verbundenen und Endpunkt-Routen tragen, was die Policy in sich geschlossen hält. Ein anderes Design nutzt eine ausdrückliche frühere Regel für das LAN-Präfix oder eine bewusste Throw-Route, die ein Präfix an eine spätere Suche übergibt. Jedes ist ein legitimes Muster mit einem anderen Eigentümer. Entscheiden Sie nach der beabsichtigten Policy und danach, wer die Routen pflegt, nicht danach, welches kürzer zu tippen ist.

Wie das Muster auch aussieht, die Ausnahme muss dort sichtbar sein, wo die Policy definiert ist. Eine von Hand hinzugefügte und nicht festgehaltene Route verschwindet beim nächsten Neustart und nimmt die Diagnose mit.

Kopieren Sie die Haupttabelle nicht pauschal

Jede Route aus der Haupttabelle in die Policy-Tabelle zu kopieren sieht wie eine Reparatur aus und erzeugt eine Momentaufnahme. Ein Verwalter kann Adressen und Schnittstellen dynamisch hinzufügen oder entfernen, und die Kopie veraltet, ohne dass es jemand bemerkt. Behalten Sie den Lebenszyklus der Routen bei ihrem Konfigurationseigentümer und erzeugen Sie die Tabelle aus der Konfiguration neu statt aus einem Zeitpunkt.

Eine kopierte Tabelle verfehlt auch den Zweck, weil sie das Ausweichverhalten reproduziert, das die Policy einschränken sollte.

Prüfen Sie Antworten getrennt von Routen

Wenn die Suche den beabsichtigten Pfad wählt, können Antworten aus Gründen scheitern, die nichts mit der Tabelle zu tun haben. Die Übersetzung kann auf der falschen Schnittstelle angewendet werden, die Prüfung des Rückwegs kann ein Paket ablehnen, das über einen unerwarteten Pfad ankam, oder der Endpunkt antwortet einfach nicht. Das sind verschiedene Fehler mit verschiedenen Belegen, und keiner davon wird durch Bearbeiten von Routeneinträgen behoben.

Halten Sie die Suche für genau diesen Fluss beiderseits der Änderung fest, damit die Korrektur sichtbar bleibt. Rückwegprüfungen global abzuschalten oder Regeln zu leeren liefert keine fehlende Route und schwächt unabhängige Kontrollen.

Notieren Sie die Regel, die Tabelle, die gewinnende Route und den Antwortpfad. Diese Aufzeichnung trennt einen Policy-Fehler von einem defekten Dienst.