Rutingtabell mot faktisk oppslag: hvor VPN-trafikken går

En utskrift av rutingtabellen er den minst nyttige diagnosen i VPN-feilsøking og den som oftest limes inn. Førti linjer med prefikser forteller deg hva maskinen kunne gjøre, ikke hva den gjorde for forespørselen som feilet. Mekanismen du faktisk vil ha, er oppslaget: gitt denne kilden og denne destinasjonen, hvilken regel samsvarte, hvilken tabell ble konsultert, og hvilket grensesnitt og neste hopp kom ut. Start med én destinasjon og én kilde, les deretter tabellen med det spørsmålet i hånden, og samme utdata blir bevis i stedet for støy.

En tabell er et sett med kandidater, ikke en beslutning

Hver oppføring beskriver et prefiks og hva som skal gjøres med trafikk som samsvarer med det: send den til et grensesnitt, gi den til et neste hopp, eller forkast den. Ingenting i listen er ordnet etter hensikt, og oppføringen som ser mest spesifikk ut for et menneske, er ikke alltid den kjernen velger, fordi valget følger lengste prefikssamsvar og, blant like prefikser, metrikken.

Så det første trekket er å spørre kjernen i stedet for å lese listen. Oppslagskommandoen svarer for en destinasjon, og med et kilde-argument svarer den for det nøyaktige paret en videresendt eller bundet forbindelse ville brukt:

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

Hver adresse ovenfor er et dokumentasjonseksempel. Poenget er formen på svaret: grensesnitt, valgt kildeadresse, gateway og tabellen oppføringen kom fra. Hvis utdataene ikke samsvarer med grensesnittet du forventet, har du lokalisert problemet med én kommando, og ingen mengde lesing av hele tabellen ville fortalt deg hvilken kandidat som vant.

Oppslaget går gjennom regler, deretter tabeller

På Linux er beslutningen i to trinn. Policyregler evalueres i prioritetsrekkefølge, og den første regelen som samsvarer, navngir en tabell som skal konsulteres; den tabellen gjør deretter lengste-prefiks-samsvaret. En regel kan samsvare på kilde, destinasjon, brannmurmerke, grensesnitt eller en kombinasjon, og derfor kan en utskrift av hovedtabellen være helt nøyaktig og helt irrelevant for pakken du undersøker.

ip rule show
ip route show table all | head -40
ip route show table 100

Hvis en regel sender trafikk fra VPN-poolen din til tabell 100, er det tabell 100 som gjelder, og hovedtabellen er et lokkemiddel. Dette er også mekanismen bak kildebasert ruting på en ruter: samme destinasjon kan ha to forskjellige svar avhengig av hvor pakken kom fra, og bare oppslaget med et kilde-argument avslører hvilket som gjelder.

IPv6 har sine egne regler og tabeller. Et design som kjører begge familiene, trenger begge oppslagene, og et fungerende IPv4-svar sier ingenting om v6-veien en dual-stack-klient kan foretrekke.

Hva VPN-klienten installerer

Klienter erstatter vanligvis ikke standardruten, fordi det ville bryte tunnelens egen ytre vei. De installerer noe mer spesifikt som vinner på prefikslengde: et par halv-standardruter som dekker 0.0.0.0/1 og 128.0.0.0/1 er det klassiske trikset, siden begge er lengre prefikser enn 0.0.0.0/0 og sammen dekker hele rommet. Andre installerer bestemte private prefikser pluss en policyregel, og noen legger til et merke slik at bare utvalgt trafikk fanges.

Derfor er "VPN-en endret ikke standardruten min" ikke bevis på feil. Sjekk hva den faktisk la til, og om destinasjonen det gjelder faller innenfor disse prefiksene:

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

To halvruter er lette å overse i en utskrift fordi de ikke ser ut som en standardrute. En split-tunnel-konfigurasjon som glemte å inkludere et prefiks, produserer nøyaktig symptomet du jager: applikasjonen som skulle bruke tunnelen, løser og kobler til lokalt i stedet. Sammenlign de installerte prefiksene med destinasjonene brukeren faktisk trenger, ikke med adressene du tilfeldigvis testet. En split-tunnel-liste som dekker filserveren men ikke resolveren dens, produserer en forbindelse som løses til en offentlig adresse og deretter feiler autentisering, noe som ser ut som et passordproblem og er et ruteproblem.

Den ytre ruten må også overleve

Tunnelen er selv trafikk. Pakkene som bærer den innkapslede nyttelasten, går til peer-adressen over det fysiske grensesnittet, og den veien må ikke rutes tilbake i tunnelen. Når det skjer, får du den karakteristiske feilen der tunnelen etableres og deretter slutter å føre trafikk, fordi transporten for tunnelen nå er inne i tunnelen.

Sjekk peer-adressen slik du sjekket den indre destinasjonen, og bekreft at den løses til det fysiske grensesnittet og ikke til tunnelen:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

En rekursiv rute, en policyregel som fanger peeren, eller en standardrute som ble erstattet av en full-tunnel-klient, er de tre vanlige årsakene. Alle tre er synlige i det ytre oppslaget, og ingen av dem er synlige i en utskrift av hovedtabellen tatt etterpå.

Hva rutingutdata ikke kan fortelle deg

Et korrekt oppslag betyr at kjernen ville sendt pakken til et fornuftig sted. Det betyr ikke at brannmuren tillater den, at IPsec-policyen dekker den, at NAT-regelen oversetter den, eller at den fjerne siden har en returrute. Hver av disse er et senere trinn, og strongSwan-merknadene om videresending beskriver kjeden en pakke må passere i begge ender.

Det tar heller ikke høyde for binding på applikasjonsnivå. En prosess kan binde til et grensesnitt, sette et merke eller bruke sin egen resolver og koble til med et navn som løses annerledes enn det du testet. Når oppslaget er riktig og forbindelsen fortsatt feiler, er neste spørsmål hvilken prosess som lager den, og om den prosessen ser den samme tabellen som deg.

Hold derfor diagnosen i rekkefølge: navngi destinasjonen og kilden, kjør oppslaget, les bare tabellen og regelen oppslaget navnga, og test deretter neste trinn. Den sekvensen holder en rutingundersøkelse på minutter og etterlater en registrering andre kan følge, noe en innlimt tabell aldri gjør.