Een VPN-standaardroute in tabel 200 verbergt je LAN-route

Vier controles scheiden een fout in de beleidstabel van een routeringsfout: welke regel overeenkwam, welke tabel die regel noemde, wat die tabel bevat en welke route daarin won. De hoofdtabel wordt niet meer geraadpleegd zodra een eerdere tabel een route oplevert, dus een LAN-item dat daar zichtbaar is kan irrelevant zijn voor het pakket dat je test. Werk de controles op volgorde af, en de ontbrekende route komt bij de derde stap naar voren in plaats van de vierde.

Langste-prefix-overeenkomst gebeurt binnen één tabel; het vergelijkt niet de routes van alle tabellen als één lijst.

De opzoeking eindigt bij de eerste tabel die antwoordt

Neem een beleid waarin verkeer van een subnet eerst tabel 200 opzoekt, tabel 200 een standaardroute door de tunnel bevat en de hoofdtabel het LAN-prefix bevat. Een pakket voor een LAN-adres kan op die standaardroute in tabel 200 passen en daar stoppen. Omdat de opzoeking een route opleverde, krijgt de latere regel van de hoofdtabel nooit de kans om zijn specifiekere item aan te bieden. Het resultaat is een pakket dat de tunnel in gaat terwijl een volstrekt goede LAN-route ongebruikt blijft.

Eerdere regels en de eigen opzoeking van de machine naar lokale adressen gelden nog steeds, dus de test moet de bron, het merkteken en de interface gebruiken die de echte stroom draagt. Vraag met iets anders en het LAN wordt misschien correct gekozen, wat precies de fout verbergt die je zoekt.

Zet de LAN-uitzondering waar ze hoort

De gekozen tabel kan de LAN-, verbonden en endpoint-routes dragen die hij nodig heeft, wat het beleid zelfstandig houdt. Een ander ontwerp gebruikt een expliciete eerdere regel voor het LAN-prefix, of een bewuste throw-route die een prefix aan een latere opzoeking overhandigt. Elk is een legitiem patroon met een andere eigenaar. Kies op basis van het bedoelde beleid en van wie de routes onderhoudt, niet op basis van welke korter te typen is.

Wat het patroon ook is, de uitzondering moet zichtbaar zijn waar het beleid is gedefinieerd. Een route die met de hand is toegevoegd en niet is vastgelegd, verdwijnt bij de volgende herstart en neemt de diagnose mee.

Kopieer de hoofdtabel niet in zijn geheel

Elke route uit de hoofdtabel naar de beleidstabel kopiëren lijkt een oplossing en maakt een momentopname. Een beheerder kan adressen en interfaces dynamisch toevoegen of verwijderen, en de kopie veroudert zonder dat iemand het merkt. Houd de levenscyclus van routes bij de eigenaar van de configuratie en genereer de tabel opnieuw uit de configuratie in plaats van uit een moment in de tijd.

Een gekopieerde tabel ondermijnt ook het doel, omdat hij het terugvalgedrag reproduceert dat het beleid juist moest beperken.

Controleer antwoorden apart van routes

Zodra de opzoeking het bedoelde pad kiest, kunnen antwoorden nog steeds mislukken om redenen die niets met de tabel te maken hebben. Vertaling kan op de verkeerde interface worden toegepast, validatie van de omgekeerde weg kan een pakket weigeren dat via een onverwacht pad aankwam, of het endpoint antwoordt misschien gewoon niet. Dat zijn verschillende fouten met verschillend bewijs, en geen ervan wordt gerepareerd door route-items te bewerken.

Bewaar de opzoeking voor precies die stroom aan beide zijden van de wijziging, zodat de correctie zichtbaar blijft. Validatie van de omgekeerde weg globaal uitschakelen of regels leegmaken levert geen ontbrekende route op en verzwakt ongerelateerde controles.

Noteer de regel, de tabel, de winnende route en het antwoordpad. Die registratie scheidt een beleidsfout van een kapotte dienst.