Routingtabel kontra det faktiske opslag: hvor VPN-trafikken ender

Et routingtabeldump er den mindst nyttige diagnostik ved fejlfinding af VPN og den, der oftest indsættes. Fyrre linjer med præfikser fortæller dig, hvad maskinen kunne gøre, ikke hvad den gjorde for den forespørgsel, der fejlede. Den mekanisme, du faktisk vil have, er opslaget: givet denne kilde og denne destination, hvilken regel matchede, hvilken tabel blev konsulteret, og hvilket interface og næste hop kom ud. Start ved én destination og én kilde, læs derefter tabellen med det spørgsmål i hånden, og samme output bliver bevis i stedet for støj.

En tabel er et sæt kandidater, ikke en beslutning

Hver post beskriver et præfiks og hvad man skal gøre med trafik, der matcher det: send den til et interface, giv den videre til et næste hop, eller drop den. Intet på den liste er ordnet efter hensigt, og den post, der ser mest specifik ud for et menneske, er ikke altid den, kernen vælger, fordi valget følger længste præfiksmatch og, blandt lige præfikser, metrikken.

Så det første skridt er at spørge kernen i stedet for at læse listen. Opslagskommandoen svarer for en destination, og med et kilde-argument svarer den for det præcise par, som en videresendt eller bundet forbindelse ville bruge:

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 dokumentationseksempel. Pointen er svarets form: interface, valgt kildeadresse, gateway og den tabel, posten kom fra. Hvis det output ikke matcher det interface, du forventede, har du lokaliseret problemet med én kommando, og ingen mængde læsning af den fulde tabel ville have fortalt dig, hvilken kandidat der vandt.

Opslaget går gennem regler og derefter tabeller

På Linux er beslutningen i to trin. Politikregler evalueres i prioritetsrækkefølge, og den første regel, der matcher, navngiver en tabel, der skal konsulteres; den tabel udfører derefter længste-præfiks-match. En regel kan matche på kilde, destination, firewall-mark, interface eller en kombination, og derfor kan et dump af hovedtabellen være helt præcist og helt irrelevant for den pakke, du undersøger.

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

Hvis en regel sender trafik fra din VPN-pulje til tabel 100, så er tabel 100 den, der betyder noget, og hovedtabellen er en lokkemad. Det er også mekanismen bag kildebaseret routing på en router: den samme destination kan have to forskellige svar afhængigt af, hvor pakken kom fra, og kun opslaget med et kilde-argument afslører, hvilket der gælder.

IPv6 har sine egne regler og tabeller. Et design, der kører begge familier, har brug for begge opslag, og et fungerende IPv4-svar siger intet om den v6-rute, en dual-stack-klient kan foretrække.

Hvad VPN-klienten installerer

Klienter erstatter normalt ikke standardruten, fordi det ville bryde tunnelens egen ydre rute. De installerer noget mere specifikt, der vinder på præfikslængde: et par halv-standardruter, der dækker 0.0.0.0/1 og 128.0.0.0/1, er det klassiske trick, da begge er længere præfikser end 0.0.0.0/0 og tilsammen dækker hele rummet. Andre installerer specifikke private præfikser plus en politikregel, og nogle tilføjer et mark, så kun udvalgt trafik fanges.

Derfor er "VPN'en ændrede ikke min standardrute" ikke bevis på fejl. Undersøg, hvad den faktisk tilføjede, og om den pågældende destination falder inden for de præfikser:

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 at overse i et dump, fordi de ikke ligner en standardrute. En split-tunnel-konfiguration, der glemte at inkludere et præfiks, giver præcis det symptom, du jager: applikationen, der burde bruge tunnelen, opløser og forbinder i stedet lokalt. Sammenlign de installerede præfikser med de destinationer, brugeren faktisk har brug for, ikke med de adresser, du tilfældigvis testede. En split-tunnel-liste, der dækker fileserveren men ikke dens resolver, giver en forbindelse, der opløses til en offentlig adresse og derefter fejler godkendelse, hvilket ligner et adgangskodeproblem men er et ruteproblem.

Den ydre rute skal også overleve

Tunnelen er selv trafik. Pakkerne, der bærer den indkapslede nyttelast, går til peerens adresse over det fysiske interface, og den rute må ikke sendes tilbage i tunnelen. Når den gør, får du den karakteristiske fejl, hvor tunnelen etableres og derefter holder op med at føre trafik, fordi transporten for tunnelen nu er inde i tunnelen.

Kontrollér peer-adressen, som du kontrollerede den indre destination, og bekræft, at den opløses til det fysiske interface frem for tunnelen:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

En rekursiv rute, en politikregel der fanger peeren, eller en standardrute, der blev erstattet af en full-tunnel-klient, er de tre sædvanlige årsager. Alle tre er synlige i det ydre opslag, og ingen af dem er synlige i et dump af hovedtabellen taget bagefter.

Hvad routing-output ikke kan fortælle dig

Et korrekt opslag betyder, at kernen ville sende pakken et fornuftigt sted hen. Det betyder ikke, at firewallen tillader den, at IPsec-politikken dækker den, at NAT-reglen oversætter den, eller at den fjerne side har en returrute. Hver af disse er et senere trin, og strongSwan-noterne om forwarding beskriver den kæde, en pakke skal passere i begge ender.

Det tager heller ikke højde for binding på applikationsniveau. En proces kan binde til et interface, sætte et mark eller bruge sin egen resolver og forbinde med et navn, der opløses anderledes end det, du testede. Når opslaget er rigtigt, og forbindelsen stadig fejler, er det næste spørgsmål, hvilken proces der laver den, og om den proces ser den samme tabel som dig.

Så hold diagnosen i rækkefølge: navngiv destinationen og kilden, kør opslaget, læs kun den tabel og regel, som opslaget navngav, og test derefter det næste trin. Den sekvens holder en routingundersøgelse på få minutter og efterlader en registrering, som andre kan følge, hvilket en indsat tabel aldrig gør.