Rutetabell mot faktisk oppslag: kvar VPN-trafikken går

Eit utskrift av rutetabellen er den minst nyttige diagnosen i VPN-feilsøking og den som oftast blir limt inn. Førti linjer med prefiks fortel deg kva maskina kunne gjere, ikkje kva ho gjorde for førespurnaden som feila. Mekanismen du faktisk vil ha, er oppslaget: gitt denne kjelda og denne destinasjonen, kva regel samsvara, kva tabell vart konsultert, og kva grensesnitt og neste hopp kom ut. Start med éin destinasjon og éi kjelde, les deretter tabellen med det spørsmålet i handa, og same utdata blir prov i staden for støy.

Ein tabell er eit sett med kandidatar, ikkje ei avgjerd

Kvar oppføring skildrar eit prefiks og kva som skal gjerast med trafikk som samsvarar med det: send han til eit grensesnitt, gje han til eit neste hopp, eller forkast han. Ingenting i lista er ordna etter hensikt, og oppføringa som ser mest spesifikk ut for eit menneske, er ikkje alltid den kjernen vel, fordi valet følgjer lengste prefikssamsvar og, blant like prefiks, metrikken.

Så det første trekket er å spørje kjernen i staden for å lese lista. Oppslagskommandoen svarar for ein destinasjon, og med eit kjelde-argument svarar han for det nøyaktige paret ei vidaresend eller bunden tilknyting ville bruke:

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

Kvar adresse over er eit dokumentasjonseksempel. Poenget er forma på svaret: grensesnitt, vald kjeldeadresse, gateway og tabellen oppføringa kom frå. Viss utdataene ikkje samsvarar med grensesnittet du venta, har du lokalisert problemet med éin kommando, og inga mengd lesing av heile tabellen ville fortalt deg kva kandidat som vann.

Oppslaget går gjennom reglar, deretter tabellar

På Linux er avgjerda i to trinn. Policyreglar blir evaluerte i prioritetsrekkjefølgje, og den første regelen som samsvarar, namngjev ein tabell som skal konsulterast; den tabellen gjer deretter lengste-prefiks-samsvaret. Ein regel kan samsvare på kjelde, destinasjon, brannmurmerke, grensesnitt eller ein kombinasjon, og difor kan eit utskrift av hovudtabellen vere heilt nøyaktig og heilt irrelevant for pakken du undersøkjer.

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

Viss ein regel sender trafikk frå VPN-poolen din til tabell 100, er det tabell 100 som gjeld, og hovudtabellen er eit lokkemiddel. Dette er også mekanismen bak kjeldebasert ruting på ein ruter: same destinasjon kan ha to ulike svar avhengig av kvar pakken kom frå, og berre oppslaget med eit kjelde-argument avslører kva som gjeld.

IPv6 har sine eigne reglar og tabellar. Eit design som køyrer begge familiane, treng begge oppslaga, og eit fungerande IPv4-svar seier ingenting om v6-vegen ein dual-stack-klient kan føretrekkje.

Kva VPN-klienten installerer

Klientar erstattar vanlegvis ikkje standardruta, fordi det ville bryte den eigne ytre vegen til tunnelen. Dei installerer noko meir spesifikt som vinn på prefikslengd: eit par halv-standardruter som dekkjer 0.0.0.0/1 og 128.0.0.0/1 er det klassiske trikset, sidan begge er lengre prefiks enn 0.0.0.0/0 og saman dekkjer heile rommet. Andre installerer bestemte private prefiks pluss ein policyregel, og nokre legg til eit merke slik at berre utvald trafikk blir fanga.

Difor er "VPN-en endra ikkje standardruta mi" ikkje prov på feil. Sjekk kva han faktisk la til, og om destinasjonen det gjeld fell innanfor desse prefiksa:

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 å oversjå i eit utskrift fordi dei ikkje ser ut som ei standardrute. Ein split-tunnel-konfigurasjon som gløymde å ta med eit prefiks, produserer nøyaktig symptomet du jagar: applikasjonen som skulle bruke tunnelen, løyser og koplar til lokalt i staden. Samanlikn dei installerte prefiksa med destinasjonane brukaren faktisk treng, ikkje med adressene du tilfeldigvis testa. Ei split-tunnel-liste som dekkjer filserveren men ikkje resolveren hans, produserer ei tilknyting som blir løyst til ei offentleg adresse og deretter feilar autentisering, noko som ser ut som eit passordproblem og er eit ruteproblem.

Den ytre ruta må også overleve

Tunnelen er sjølv trafikk. Pakkane som ber den innkapsla nyttelasta, går til peer-adressa over det fysiske grensesnittet, og den vegen må ikkje rutast tilbake i tunnelen. Når det skjer, får du den karakteristiske feilen der tunnelen blir oppretta og deretter sluttar å føre trafikk, fordi transporten for tunnelen no er inne i tunnelen.

Sjekk peer-adressa slik du sjekka den indre destinasjonen, og stadfest at ho blir løyst til det fysiske grensesnittet og ikkje til tunnelen:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

Ei rekursiv rute, ein policyregel som fangar peeren, eller ei standardrute som vart erstatta av ein full-tunnel-klient, er dei tre vanlege årsakene. Alle tre er synlege i det ytre oppslaget, og ingen av dei er synlege i eit utskrift av hovudtabellen teke etterpå.

Kva rutingutdata ikkje kan fortelje deg

Eit korrekt oppslag betyr at kjernen ville sendt pakken til ein fornuftig stad. Det betyr ikkje at brannmuren tillèt han, at IPsec-policyen dekkjer han, at NAT-regelen omset han, eller at den fjerne sida har ei returrute. Kvar av desse er eit seinare trinn, og strongSwan-merknadene om vidaresending skildrar kjeda ein pakke må passere i begge endar.

Det tek heller ikkje omsyn til binding på applikasjonsnivå. Ein prosess kan binde til eit grensesnitt, setje eit merke eller bruke sin eigen resolver og kople til med eit namn som blir løyst annleis enn det du testa. Når oppslaget er riktig og tilknytinga framleis feilar, er neste spørsmål kva prosess som lagar ho, og om den prosessen ser den same tabellen som deg.

Hald difor diagnosen i rekkjefølgje: nemn destinasjonen og kjelda, køyr oppslaget, les berre tabellen og regelen oppslaget nemnde, og test deretter neste trinn. Den sekvensen held ei rutingundersøking på minutt og etterlèt ein registrering andre kan følgje, noko ein innlimt tabell aldri gjer.