En tom VPN-tabell blokkerer ikke noe i seg selv

En politikkregel sender merkede pakker til en dedikert tabell, og den vanlige forventningen er at tapet av VPN-ruten blokkerer dem. Mekanismen gjør noe annet. Når en tabell ikke inneholder noen samsvarende rute, fortsetter oppslaget til neste regel i stedet for å stoppe, og tabellen main holder fortsatt en vanlig standardrute for uplink. Resultatet er en konfigurasjon som ser fail-closed ut og oppfører seg fail-open.

Ingenting er ødelagt; slik er policy-ruting spesifisert.

Oppslaget fortsetter når en tabell ikke har noe

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 lookup default
32766: from all lookup main

Ta det regelsettet: et merket oppslag går til tabell 42, og en senere regel sender samme merke til en tabell ved navn default. Så lenge tabell 42 holder en brukbar standardrute, leverer det første oppslaget veien. Når den ruten forsvinner og ingenting annet i tabell 42 samsvarer, blir oppslaget ikke et dropp; behandlingen går videre til neste regel, og når den heller ikke finner noe, når den tabellen main. Ingenting i den sekvensen rapporterer hvilken regel som ga det endelige svaret, så en fungerende forbindelse ser ut som en fungerende politikk.

Tabell 253, som konvensjonelt kalles default, er en vanlig rutingtabell og er normalt tom. Navnet er ikke en instruks om å droppe pakker, og det er ikke det samme som en standard destinasjonsrute inne i en tabell.

Terminale handlinger avslutter søket

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 prohibit
32766: from all lookup main

En terminal regel kan følge VPN-oppslaget i stedet for et oppslag i en tom tabell. Med samme merke avslutter en prohibit-handling plassert etter tabell-42-regelen søket når den tabellen ikke gir noe, og returnerer en administrativ avvisning i stedet for å gi tabellen main en ny sjanse. Unreachable og blackhole er også terminale, med annen feiloppførsel for avsenderen.

En rute av typen throw er annerledes: innenfor den tabellen oppfører den seg som om ingenting samsvarte, så senere regler får likevel sin tur. Det gjør throw nyttig for bevisst tilbakefall og feil som en endelig blokkering.

Verifiser med det virkelige merket og grensesnittet

ip -4 rule show
ip -4 route show table 42
ip -4 route get 198.51.100.20 from 10.44.0.2 iif lan0 mark 0x36

Undersøk de virkelige reglene og tabellen i stedet for et diagram, og spør deretter flyten med den kilden, merket og inngangskonteksten den faktisk har. Et skrivebeskyttet oppslag rettet mot en destinasjon, som får oppgitt kildeadresse, grensesnitt og merke, rapporterer ruten kjernen ville valgt uten at en pakke forlater systemet. Å oppgi et merke i spørringen beviser ikke at brannmuren merker virkelig trafikk; det er en separat kontroll av merkereglene. Bekreft verdien med en teller eller en logg før du trekker konklusjoner fra spørringen.

Lokalt genererte forespørsler trenger sin egen kontekst, fordi merkestien deres ofte er forskjellig fra videresendt trafikk. Kontroller dem med utgangsgrensesnittet programmet faktisk ville brukt.

To feiltilstander, ikke én

Én feiltilstand er at VPN-ruten forsvinner og trafikken faller gjennom til uplink. En død tunnel der ruten fortsatt er installert er en annen: pakkene forblir rettet inn i en ubrukelig sti i stedet for å falle gjennom, og symptomet er stille tap i stedet for en synlig direkte forbindelse. Test begge, og test også oppstart, gjenoppkobling og tjenestestopp.

En slik regel hjelper bare mens den finnes og mens pakkene fortsatt bærer merket som velger den. Et avskjæringsskript som sletter regelen, eller en sti som fjerner merket, gjenoppretter den åpne oppførselen. De overgangene er verdt å øve på.

Bruk politikken på IPv6 separat, og hold godkjente unntak for endepunkter eksplisitte i stedet for underforståtte.