Hva policy routing endrer for VPN-trafikk, og hva det ikke endrer

Policy routing svarer på et annet spørsmål enn det de fleste feilsøkingsnotatene stiller. Hovedtabellen sier hvor en destinasjon går hen; policyregler sier hvilken tabell som i det hele tatt slås opp, og de kan avgjøre det ut fra kildeadressen, et pakkemerke, eller grensesnittet en pakke ankom på. Når en tunnel oppfører seg inkonsekvent, er regelsettet ofte årsaken og rutetabellen ofte ikke.

Regler velger tabellen, så velger tabellen ruten

Hver regel har en prioritet, en matchbetingelse og en måltabell. Kjernen går gjennom reglene i prioritetsrekkefølge og stopper ved første treff, og utfører deretter et vanlig oppslag etter lengste prefiks i den tabellen. En regel som peker på en tom tabell faller gjennom til det neste regel velger, og det er slik en nøye skrevet regel kan se ut som den ikke gjør noe.

Derfor forklarer en utskrift av hovedtabellen sjelden en fungerende VPN-klient. Klienter setter vanligvis inn regler på lave prioritetsnumre, lenge før hovedtabellens standardregel, slik at pakken aldri når ruten du stirret på. Å senke en metrikk i hovedtabellen endrer ingenting for trafikk som allerede er omdirigert.

En regel kan også med vilje gjøre et prefiks til et svart hull eller utilgjengelig. Noen klienter legger til en slik regel som en kill switch, og da ser droppet ut som en brukket tunnel snarere enn en konfigurert.

Les regelsettet som en sekvens, ikke som en liste

Skriv ut reglene med prioritetene deres og tabellene de viser til, og skriv deretter ut hver tabell som bærer en standardrute eller en tunnelrute. Rekkefølgen er den delen som betyr noe, og det er den delen et skjermbilde vanligvis utelater:

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

De to siste kommandoene er de som gjør en teori til en observasjon, fordi de spør hva kjernen ville gjort for den kilden og det merket. Hvis svaret endrer seg når merket endrer seg, er en merkebasert regel i spill, og enhver test som utelater merket, tester en annen pakke. Den ytre forbindelsen fortjener sin egen regel. En tunnel som ruter all trafikk gjennom seg selv, må utelukke endepunktsadressen den kobler til, ellers sendes de krypterte pakkene tilbake i tunnelen de nettopp forlot. De fleste klienter setter inn den utelatelsen automatisk, og et håndredigert regelsett er stedet der den mangler.

Merker og sockets: to måter klienter deler trafikk på

Noen klienter merker pakker i brannmuren og legger til en regel som samsvarer med merket. Andre bruker ruting på socketnivå og setter en rute på socketen før den kobler til. Det første er synlig i ip rule; det andre er ikke, og det vises ikke i et generisk oppslag.

Hvis et testprogram oppfører seg annerledes enn applikasjonen det skal representere, sjekk om applikasjonen setter et merke eller binder seg til en enhet. Den forskjellen er ikke en gåte når mekanismen er navngitt, og den forklarer hvorfor en curl fra en shell og en nettleserfane kan ta forskjellige veier på samme maskin. Begge teknikkene er policy routing i vid forstand: de velger en vei ved hjelp av noe annet enn destinasjonen. Ingen av dem autoriserer trafikken, og ingen av dem erstatter brannmurreglene eller legitimasjonen motparten forventer.

Spor eierskapet før du legger til enda en regel

Regler installeres av noe. En VPN-klient, en nettverksbehandler og et håndskrevet skript kan hver legge til regler ved oppstart, og gjentilkoblingslogikk kan etterlate det forrige settet. To utdaterte regler fra en tidligere profil vil fortsette å styre trafikk lenge etter at profilen er slettet.

Finn ut hvilken prosess som eier regelen ut fra prioriteten og formen, og sjekk om eieren skriver om settet ved hver tilkobling. Hvis den gjør det, forsvinner en manuell regel som ble lagt til i dag, i morgen, og rettelsen hører hjemme i klientens konfigurasjon snarere enn i en shell-historikkfil. Å rydde hele regelsettet for å teste er en fristende snarvei med en forutsigbar pris: det fjerner også reglene klienten trenger for å holde sin egen tunnel i gang. Slett én regel om gangen, eller test på en maskin du kan starte på nytt.

Bevis omfanget med to flyter, ikke én

En rettelse verifiseres bare av en flyt som skal påvirkes og en flyt som ikke skal det. Velg en destinasjon som policyen ruter inn i tunnelen, og en som må forbli utenfor, og sammenlign deretter oppslagene og opptakene 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 de to oppslagene returnerer forskjellige grensesnitt, gjør regelen noe. Når de returnerer samme grensesnitt, matcher regelen bredere enn tiltenkt, og det er feilen som stille sender et helt subnett gjennom en tunnel som var ment for én applikasjon.

Noter reglenes prioriteter og den eierende tjenesten i billetten, sammen med de to testadressene. Den neste personen har da et reproduserbart par i stedet for en beskrivelse av et symptom, og kan på et minutt si om policy routing fortsatt er i spill.