Kva policy routing endrar for VPN-trafikk, og kva det ikkje endrar

Policy routing svarar på eit anna spørsmål enn det dei fleste feilsøkingsnotata stiller. Hovudtabellen seier kvar ein destinasjon går; policyreglar seier kva tabell som i det heile blir slått opp, og dei kan avgjere det ut frå kjeldeadressa, eit pakkemerke, eller grensesnittet ein pakke kom inn på. Når ein tunnel oppfører seg inkonsekvent, er regelsettet ofte årsaka og rutetabellen ofte ikkje.

Reglar vel tabellen, så vel tabellen ruta

Kvar regel har ein prioritet, eit matchvilkår og ein måltabell. Kjernen går gjennom reglane i prioritetsrekkjefølgje og stoppar ved fyrste treff, og utfører deretter eit vanleg oppslag etter lengste prefiks i den tabellen. Ein regel som peikar på ein tom tabell fell gjennom til det neste regel vel, og slik kan ein nøye skriven regel sjå ut som han ikkje gjer noko.

Difor forklarer eit utskrift av hovudtabellen sjeldan ein fungerande VPN-klient. Klientar set vanlegvis inn reglar på låge prioritetsnummer, lenge før standardregelen i hovudtabellen, slik at pakken aldri når ruta du stira på. Å senke ein metrikk i hovudtabellen endrar ingenting for trafikk som alt er omdirigert.

Ein regel kan òg med vilje gjere eit prefiks til eit svart hól eller utilgjengeleg. Nokre klientar legg til ein slik regel som ein kill switch, og då ser droppet ut som ein broten tunnel snarare enn ein konfigurert.

Les regelsettet som ein sekvens, ikkje som ei liste

Skriv ut reglane med prioritetane sine og tabellane dei viser til, og skriv deretter ut kvar tabell som ber ei standardrute eller ei tunnelrute. Rekkjefølgja er den delen som betyr noko, og det er den delen eit skjermbilete vanlegvis utelèt:

ip rule show
ip route show table all | sed -n '1,60p'
ip route get 198.51.100.20 from 10.8.0.2
ip route get 198.51.100.20 from 10.8.0.2 mark 0x1

Dei to siste kommandoane er dei som gjer ein teori til ein observasjon, fordi dei spør kva kjernen ville gjort for den kjelda og det merket. Viss svaret endrar seg når merket endrar seg, er ein merkebasert regel i spel, og kvar test som utelèt merket, testar ein annan pakke. Den ytre sambindinga fortener sin eigen regel. Ein tunnel som rutar all trafikk gjennom seg sjølv, må utelukke endepunktsadressa han koplar til, elles blir dei krypterte pakkane sende tilbake i tunnelen dei nettopp forlét. Dei fleste klientar set inn den utelatinga automatisk, og eit handredigert regelsett er staden der ho manglar.

Merke og sockets: to måtar klientar deler trafikk på

Nokre klientar merkar pakkar i brannmuren og legg til ein regel som samsvarer med merket. Andre brukar ruting på socketnivå og set ei rute på socketen før han koplar til. Det fyrste er synleg i ip rule; det andre er ikkje, og det vil ikkje visast i eit generisk oppslag.

Viss eit testprogram oppfører seg annleis enn applikasjonen det skal representere, sjekk om applikasjonen set eit merke eller bind seg til ei eining. Den skilnaden er ikkje ei gåte når mekanismen er namngjeven, og han forklarer kvifor ein curl frå ein shell og ein nettlesarfane kan ta ulike vegar på same maskin. Begge teknikkane er policy routing i vid forstand: dei vel ein veg ved hjelp av noko anna enn destinasjonen. Ingen av dei autoriserer trafikken, og ingen av dei erstattar brannmurreglane eller legitimasjonen motparten ventar.

Spor eigarskapet før du legg til endå ein regel

Reglar blir installerte av noko. Ein VPN-klient, ein nettverkshandsamar og eit handskrive skript kan kvar leggje til reglar ved oppstart, og gjentilkoplingslogikk kan etterlate det førre settet. To utdaterte reglar frå ein tidlegare profil vil halde fram med å styre trafikk lenge etter at profilen er sletta.

Finn ut kva prosess som eig regelen ut frå prioriteten og forma, og sjekk om eigaren skriv om settet ved kvar tilkopling. Viss han gjer det, forsvinn ein manuell regel som vart lagt til i dag, i morgon, og rettinga høyrer heime i konfigurasjonen til klienten snarare enn i ei shell-historie fil. Å rydde heile regelsettet for å teste er ein freistande snøggveg med ein føreseieleg pris: det fjernar òg reglane klienten treng for å halde sin eigen tunnel i gang. Slett ein regel om gongen, eller test på ein maskin du kan starte på nytt.

Prov omfanget med to flytar, ikkje éin

Ei retting blir berre verifisert av ein flyt som skal påverkast og ein flyt som ikkje skal det. Vel ein destinasjon som policyen rutar inn i tunnelen, og ein som må halde seg utanfor, og samanlikn deretter oppslaga og opptaka for begge:

ip route get 198.51.100.20 from 192.0.2.44
ip route get 198.51.100.21 from 192.0.2.44
tcpdump -ni any host 198.51.100.21 and port 443

Når dei to oppslaga returnerer ulike grensesnitt, gjer regelen noko. Når dei returnerer same grensesnitt, matchar regelen breiare enn tiltenkt, og det er feilen som stille sender eit heilt subnett gjennom ein tunnel som var meint for éin applikasjon.

Noter prioritetane til reglane og den eigande tenesta i billetten, saman med dei to testadressene. Den neste personen har då eit reproduserbart par i staden for ei skildring av eit symptom, og kan på eit minutt seie om policy routing framleis er i spel.