En app bundet til VPN-adressen bruger stadig den forkerte rute

En applikation binder til VPN-adressen, og forbindelsen forlader alligevel gennem den almindelige standardrute. Intet i bindingen fejlede; den gjorde præcis det, en binding gør. At binde en socket til en lokal adresse vælger den kildeadresse, som kernen sætter i headeren. Det installerer ikke en rute og opretter ikke en politikregel, der sender pakker med den kilde ind i en bestemt tunnel.

Resten af denne runbook er den kontrolrækkefølge, jeg bruger, sammen med kommandoen, der giver hver observation.

Hvad en binding reelt afgør

En binding tildeler socketen en lokal adresse. Kernen kører derefter det samme ruteopslag, som den ellers ville have kørt, medmindre en politikregel ændrer, hvilken tabel opslaget læser.

Derfor kan en pakke forlade systemet med en VPN-kildeadresse på et fysisk interface. På den anden side ankommer den fra et privat område, som netværket aldrig forventede på den vej, returtrafikken har ingen rute tilbage, og forbindelsen hænger eller nulstilles.

Linux-referencen for IP-sockets dokumenterer bindingens semantik. Rutedelen bor i ip-rule og ip-route, og det er separate manualer af en grund.

Bekræft, at adressen tilhører dette namespace

En adresse, du kan binde til, skal findes på et interface inde i det netværksnamespace, applikationen kører i. En peer-adresse, en gateway-adresse eller en adresse, der kun findes i et andet namespace, kan ikke bindes, og kaldet fejler med EADDRNOTAVAIL.

ip -br addr show
ip netns identify <pid>
ss -tanp | grep <port>

Kør de tre i samme kontekst som applikationen: samme namespace og samme bruger, hvis du kan få den. Et gammelt net30-diagram er ikke bevis for, hvilken adresse din nuværende topologi har tildelt klienten. Læs det interface, der faktisk er oppe.

Læs opslaget for den kilde og destination

Én kommando besvarer det spørgsmål, bindingen ikke besvarede:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

Den første linje udskriver den rute, en pakke fra den kilde til den destination ville tage, inklusive det udgående interface og den foretrukne kilde. Hvis den nævner det fysiske interface, er bindingen og ruten uenige, og pakken forlader med en kilde, som vejen ikke kan vende tilbage til.

Derefter fortæller ip rule show, om nogen regel ville have valgt en anden tabel. Prioriteter betyder noget her, fordi den første matchende regel vinder, og en regel, der fanger alt over din, gør din regel usynlig.

Installer kun en politikregel, hvis det er designet

Kildebaseret routing er et bevidst design, ikke en reparation for én applikation. Hvis politiksejeren vil have, at trafik fra tunnel-subnettet bruger tunnelen, hører reglen til i den ejers konfiguration og ikke i en engangskommando på din laptop.

En brugbar form er en dedikeret tabel med en standardrute gennem tunnelen plus en regel, der sender VPN-kildeområdet ind i den tabel. Tilføj de undtagelser, designet kræver, fordi en tabel, der kun indeholder en tunnelstandard, vil fange destinationer, der skal forblive lokale eller kunne nås over den fysiske vej.

ip route add default dev tun0 table 100
ip rule add from 10.8.0.2 table 100 priority 100
ip route get 203.0.113.10 from 10.8.0.2

Rul tilbage med ip rule del og ip route flush table 100. Alt, der tilføjes på den måde, forsvinder ved genstart, medmindre en manager skriver det, hvilket både er en sikkerhedsegenskab og en grund til ikke at have den eneste kopi i din shell-historik.

Verificer med tre observationer

Noter den kilde, applikationen anmodede om, den rute opslaget valgte, og den kilde, serveren faktisk så.

De tre kan være uenige, og hver uenighed peger et andet sted hen. En optagelse på tunnel-interfacet beviser, at pakken forlod med den rigtige kilde. En optagelse på det fysiske interface beviser, at den forlod den forkerte vej. Server-side-visningen er den eneste, der beviser vejen end to end.

Hvis applikationen tilbyder en bind-til-enhed-funktion eller en routingtilstand pr. app, skal du behandle den som en anden mekanisme med andre begrænsninger. Lignende indstillinger fører ikke alle til den samme kernebeslutning.