Ein tom VPN-tabell blokkerer ikkje noko i seg sjølv

Ein politikkregel sender merkte pakkar til ein eigen tabell, og den vanlege forventninga er at tapet av VPN-ruta blokkerer dei. Mekanismen gjer noko anna. Når ein tabell ikkje inneheld noka samsvarande rute, held oppslaget fram til neste regel i staden for å stoppe, og tabellen main held framleis ei vanleg standardrute for uplink. Resultatet er ein konfigurasjon som ser fail-closed ut og oppfører seg fail-open.

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

Oppslaget held fram når ein tabell ikkje har noko

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

Ta det regelsettet: eit merkt oppslag går til tabell 42, og ein seinare regel sender same merket til ein tabell ved namn default. Så lenge tabell 42 held ei brukbar standardrute, leverer det første oppslaget vegen. Når den ruta forsvinn og ingenting anna i tabell 42 samsvarar, blir oppslaget ikkje eit dropp; handsaminga går vidare til neste regel, og når den heller ikkje finn noko, når den tabellen main. Ingenting i den sekvensen rapporterer kva regel som gav det endelege svaret, så ei fungerande tilknyting ser ut som ein fungerande politikk.

Tabell 253, som konvensjonelt blir kalla default, er ein vanleg rutetabell og er normalt tom. Namnet er ikkje ein instruks om å droppe pakkar, og det er ikkje det same som ei standard destinasjonsrute inne i ein tabell.

Terminale handlingar avsluttar søket

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

Ein terminal regel kan følgje VPN-oppslaget i staden for eit oppslag i ein tom tabell. Med same merke avsluttar ei prohibit-handling plassert etter tabell-42-regelen søket når den tabellen ikkje gir noko, og returnerer ei administrativ avvising i staden for å gi tabellen main ein ny sjanse. Unreachable og blackhole er også terminale, med annan feiloppførsel for avsendaren.

Ei rute av typen throw er annleis: innanfor den tabellen oppfører ho seg som om ingenting samsvara, så seinare reglar får likevel si tur. Det gjer throw nyttig for medvite tilbakefall og feil som ein endeleg blokkering.

Verifiser med det verkelege 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 dei verkelege reglane og tabellen i staden for eit diagram, og spør deretter flyten med den kjelda, merket og inngangskonteksten han faktisk har. Eit skriveverna oppslag retta mot ein destinasjon, som får oppgitt kjeldadresse, grensesnitt og merke, rapporterer ruta kjernen ville valt utan at ein pakke forlèt systemet. Å oppgi eit merke i spørjinga beviser ikkje at brannmuren merkar verkeleg trafikk; det er ein separat kontroll av merkereglane. Stadfest verdien med ein teljar eller ein logg før du dreg konklusjonar frå spørjinga.

Lokalt genererte førespurnader treng si eiga kontekst, fordi merkestien deira ofte er annleis enn vidareformidla trafikk. Kontroller dei med utgangsgrensesnittet programmet faktisk ville bruke.

To feiltilstandar, ikkje éin

Éin feiltilstand er at VPN-ruta forsvinn og trafikken fell gjennom til uplink. Ein død tunnel der ruta framleis er installert er ein annan: pakkane blir verande retta inn i ein ubrukeleg stig i staden for å falle gjennom, og symptomet er stille tap i staden for ei synleg direkte tilknyting. Test begge, og test også oppstart, gjenoppkopling og tenestestopp.

Ein slik regel hjelper berre medan han finst og medan pakkane framleis ber merket som vel han. Eit avskjeringsskript som slettar regelen, eller ein stig som fjernar merket, gjenopprettar den opne oppførselen. Dei overgangane er verdt å øve på.

Bruk politikken på IPv6 separat, og hald godkjende unntak for endepunkt eksplisitte i staden for underforståtte.