En VPN-standardrute i tabell 200 skjuler LAN-ruten din

Fire kontroller skiller en feil i policytabellen fra en rutingfeil: hvilken regel som matchet, hvilken tabell den regelen pekte på, hva den tabellen inneholder, og hvilken rute i den som vant. Hovedtabellen blir ikke slått opp når en tidligere tabell gir en rute, så en LAN-oppføring som er synlig der kan være irrelevant for pakken du tester. Kjør kontrollene i rekkefølge, og den manglende ruten dukker opp på tredje trinn i stedet for det fjerde.

Samtidig av lengst prefiks skjer inne i én tabell; den sammenligner ikke alle tabellers ruter som én liste.

Oppslaget slutter ved den første tabellen som svarer

Ta en policy der trafikk fra et subnett først slår opp tabell 200, tabell 200 inneholder en standardrute gjennom tunnelen, og hovedtabellen inneholder LAN-prefikset. En pakke til en LAN-adresse kan matche den standardruten i tabell 200 og stoppe der. Fordi oppslaget ga en rute, får den senere hovedtabellregelen aldri sjansen til å tilby den mer spesifikke oppføringen sin. Resultatet er en pakke som går inn i tunnelen mens en helt grei LAN-rute står ubrukt.

Tidligere regler og maskinens eget oppslag på lokale adresser gjelder fortsatt, så testen må bruke kilden, merket og grensesnittet som den virkelige flyten bærer. Spør med noe annet, og LAN-et kan bli valgt riktig, noe som skjuler nettopp feilen du jager.

Sett LAN-unntaket der det hører hjemme

Den valgte tabellen kan bære LAN-, tilkoblede og endepunktsruter som den trenger, noe som holder policyen selvbærende. Et annet design bruker en eksplisitt tidligere regel for LAN-prefikset, eller en bevisst kastrute som overleverer et prefiks til et senere oppslag. Hver er et legitimt mønster med en annen eier. Velg ut fra den tiltenkte policyen og ut fra hvem som vedlikeholder rutene, ikke ut fra hvilken som er raskest å skrive.

Uansett mønster må unntaket være synlig der policyen er definert. En rute som legges til manuelt og ikke registreres, forsvinner ved neste omstart og tar diagnosen med seg.

Ikke kopier hovedtabellen i sin helhet

Å kopiere hver rute fra hovedtabellen til policytabellen ser ut som en reparasjon, men lager et øyeblikksbilde. En administrator kan legge til eller fjerne adresser og grensesnitt dynamisk, og kopien blir utdatert uten at noen merker det. Hold livssyklusen til rutene hos konfigurasjonseieren, og generer tabellen på nytt fra konfigurasjonen i stedet for fra et øyeblikk i tiden.

En kopiert tabell undergraver også formålet, fordi den gjengir reserveatferden som policyen skulle begrense.

Kontroller svar separat fra ruter

Når oppslaget har valgt den tiltenkte veien, kan svar fortsatt feile av grunner som ikke har noe med tabellen å gjøre. Oversettelse kan bli brukt på feil grensesnitt, validering av omvendt vei kan avvise en pakke som kom via en uventet vei, eller endepunktet svarer kanskje rett og slett ikke. Dette er ulike feil med ulike bevis, og ingen av dem repareres ved å redigere ruteoppføringer.

Lagre oppslaget for nøyaktig den flyten på begge sider av endringen, slik at rettelsen forblir synlig. Å slå av validering av omvendt vei globalt eller tømme regler gir ingen manglende rute og svekker urelaterte kontroller.

Noter regelen, tabellen, den vinnende ruten og svarveien. Den registreringen skiller en policyfeil fra en ødelagt tjeneste.