En VPN-standardrutt i tabell 200 döljer din LAN-rutt

Fyra kontroller skiljer ett fel i policytabellen från ett routingfel: vilken regel som matchade, vilken tabell den regeln pekade på, vad den tabellen innehåller och vilken rutt i den som vann. Huvudtabellen slås inte upp när en tidigare tabell ger en rutt, så en LAN-post som syns där kan vara irrelevant för paketet du testar. Kör kontrollerna i ordning, och den saknade rutten dyker upp i tredje steget i stället för det fjärde.

Matchning av längsta prefix sker inuti en tabell; den jämför inte alla tabellers rutter som en enda lista.

Uppslaget slutar vid den första tabellen som svarar

Ta en policy där trafik från ett subnät först slår upp tabell 200, tabell 200 innehåller en standardrutt genom tunneln och huvudtabellen innehåller LAN-prefixet. Ett paket till en LAN-adress kan matcha den standardrutten i tabell 200 och stanna där. Eftersom uppslaget gav en rutt får den senare huvudtabellsregeln aldrig chansen att erbjuda sin mer specifika post. Resultatet är ett paket som går in i tunneln medan en alldeles utmärkt LAN-rutt står oanvänd.

Tidigare regler och maskinens eget uppslag på lokala adresser gäller fortfarande, så testet måste använda den källa, den markering och det gränssnitt som det verkliga flödet bär. Fråga med något annat och LAN:et kan väljas korrekt, vilket döljer precis det fel du jagar.

Sätt LAN-undantaget där det hör hemma

Den valda tabellen kan bära de LAN-, anslutna och ändpunktsrutter som den behöver, vilket håller policyn självständig. En annan design använder en uttrycklig tidigare regel för LAN-prefixet, eller en avsiktlig kastrutt som lämnar ett prefix till ett senare uppslag. Var och en är ett legitimt mönster med en annan ägare. Välj utifrån den avsedda policyn och utifrån vem som underhåller rutterna, inte utifrån vilken som är snabbast att skriva.

Oavsett mönster måste undantaget vara synligt där policyn definieras. En rutt som läggs till manuellt och inte registreras försvinner vid nästa omstart och tar diagnosen med sig.

Kopiera inte huvudtabellen i sin helhet

Att kopiera varje rutt från huvudtabellen till policytabellen ser ut som en reparation men skapar en ögonblicksbild. En administratör kan lägga till eller ta bort adresser och gränssnitt dynamiskt, och kopian blir inaktuell utan att någon märker det. Håll rutternas livscykel hos sin konfigurationsägare och generera om tabellen från konfigurationen i stället för från en tidpunkt.

En kopierad tabell motverkar också syftet, eftersom den återskapar det reservbeteende som policyn skulle begränsa.

Kontrollera svar separat från rutter

När uppslaget har valt den avsedda vägen kan svar fortfarande misslyckas av skäl som inte har något med tabellen att göra. Översättning kan tillämpas på fel gränssnitt, validering av omvänd väg kan avvisa ett paket som kom via en oväntad väg, eller så svarar ändpunkten helt enkelt inte. Det är olika fel med olika bevis, och inget av dem repareras genom att redigera ruttposter.

Spara uppslaget för exakt det flödet på båda sidor av ändringen, så att rättelsen förblir synlig. Att stänga av validering av omvänd väg globalt eller tömma regler ger ingen saknad rutt och försvagar orelaterade kontroller.

Notera regeln, tabellen, den vinnande rutten och svarsvägen. Den anteckningen skiljer ett policyfel från en trasig tjänst.