Ei VPN-standardrute i tabell 200 gøymer LAN-ruta di

Fire kontrollar skil ein feil i policytabellen frå ein rutingsfeil: kva regel som passa, kva tabell den regelen peika på, kva den tabellen inneheld, og kva rute i han som vann. Hovudtabellen blir ikkje slått opp når ein tidlegare tabell gir ei rute, så ein LAN-oppføring som er synleg der kan vera irrelevant for pakka du testar. Køyr kontrollane i rekkjefølgje, og den manglande ruta dukkar opp på tredje trinn i staden for det fjerde.

Samtidig av lengst prefiks skjer inne i éin tabell; han samanliknar ikkje rutene til alle tabellane som éi liste.

Oppslaget sluttar ved den første tabellen som svarar

Ta ein policy der trafikk frå eit subnett først slår opp tabell 200, tabell 200 inneheld ei standardrute gjennom tunnelen, og hovudtabellen inneheld LAN-prefikset. Ei pakke til ei LAN-adresse kan passa den standardruta i tabell 200 og stoppa der. Fordi oppslaget gav ei rute, får den seinare hovudtabellregelen aldri sjansen til å tilby den meir spesifikke oppføringa si. Resultatet er ei pakke som går inn i tunnelen medan ei heilt grei LAN-rute står ubrukt.

Tidlegare reglar og maskina sitt eige oppslag på lokale adresser gjeld framleis, så testen må bruka kjelda, merket og grensesnittet som den verkelege flyten ber. Spør med noko anna, og LAN-et kan bli valt rett, noko som skjuler nettopp feilen du jagar.

Set LAN-unntaket der det høyrer heime

Den valde tabellen kan bera LAN-, tilkopla og endepunktsruter som han treng, noko som held policyen sjølvberande. Eit anna design brukar ein eksplisitt tidlegare regel for LAN-prefikset, eller ei medviten kastrute som overleverer eit prefiks til eit seinare oppslag. Kvar er eit legitimt mønster med ein annan eigar. Vel ut frå den tiltenkte policyen og ut frå kven som vedlikeheld rutene, ikkje ut frå kva som er raskast å skriva.

Uansett mønster må unntaket vera synleg der policyen er definert. Ei rute som blir lagd til manuelt og ikkje registrert, forsvinn ved neste omstart og tek diagnosen med seg.

Ikkje kopier hovudtabellen i sin heilskap

Å kopiera kvar rute frå hovudtabellen til policytabellen ser ut som ein reparasjon, men lagar eit augeblinksbilete. Ein administrator kan leggja til eller fjerna adresser og grensesnitt dynamisk, og kopien blir utdatert utan at nokon merkar det. Hald livssyklusen til rutene hjå konfigurasjonseigaren, og generer tabellen på nytt frå konfigurasjonen i staden for frå eit augeblink i tida.

Ein kopiert tabell underminerer også føremålet, fordi han gjev att reserveåtferda som policyen skulle avgrense.

Kontroller svar separat frå ruter

Når oppslaget har valt den tiltenkte vegen, kan svar framleis feila av grunnar som ikkje har noko med tabellen å gjera. Omsetjing kan bli brukt på feil grensesnitt, validering av omvend veg kan avvise ei pakke som kom via ein uventa veg, eller endepunktet svarar kanskje rett og slett ikkje. Dette er ulike feil med ulike bevis, og ingen av dei blir reparert ved å endra ruteoppføringar.

Lagre oppslaget for nøyaktig den flyten på begge sider av endringa, slik at rettinga blir verande synleg. Å slå av validering av omvend veg globalt eller tømma reglar gir inga manglande rute og svekkjer urelaterte kontrollar.

Noter regelen, tabellen, den vinnande ruta og svarvegen. Den registreringa skil ein policyfeil frå ein øydelagd teneste.