En app bundet til VPN-adressen bruker fortsatt feil rute

En applikasjon binder til VPN-adressen, og forbindelsen forlater likevel via den vanlige standardruten. Ingenting i bindingen feilet; den gjorde nøyaktig det en binding gjør. Å binde en socket til en lokal adresse velger kildeadressen kjernen setter i headeren. Det installerer ikke en rute, og det oppretter ikke en policyregel som sender pakker med den kilden inn i en bestemt tunnel.

Resten av denne kjøreboken er kontrollrekkefølgen jeg bruker, sammen med kommandoen som gir hver observasjon.

Hva en binding faktisk avgjør

En binding tildeler en lokal adresse til socketen. Deretter kjører kjernen det samme ruteoppslaget som den ellers ville ha kjørt, med mindre en policyregel endrer hvilken tabell oppslaget leser.

Derfor kan en pakke gå ut med en VPN-kildeadresse på et fysisk grensesnitt. På den andre siden kommer den fra et privat område nettverket aldri forventet på den veien, returtrafikken har ingen rute tilbake, og forbindelsen henger eller tilbakestilles.

Linux-referansen for IP-sockets dokumenterer bindingens semantikk. Rutedelen bor i ip-rule og ip-route, og det er separate manualer av en grunn.

Bekreft at adressen tilhører dette navnerommet

En adresse du kan binde til, må finnes på et grensesnitt inne i nettverksnavnerommet applikasjonen kjører i. En peer-adresse, en gateway-adresse eller en adresse som bare finnes i et annet navnerom kan ikke bindes, og kallet feiler med EADDRNOTAVAIL.

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

Kjør de tre i samme kontekst som applikasjonen: samme navnerom, og samme bruker hvis du får tak i den. Et gammelt net30-diagram er ikke bevis for hvilken adresse den nåværende topologien din tildelte klienten. Les grensesnittet som faktisk er oppe.

Les oppslaget for den kilden og destinasjonen

Én kommando svarer på spørsmålet bindingen ikke svarte på:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

Den første linjen skriver ut ruten en pakke fra den kilden til den destinasjonen ville ta, inkludert det utgående grensesnittet og den foretrukne kilden. Hvis den navngir det fysiske grensesnittet, er bindingen og ruten uenige, og pakken går ut med en kilde som veien ikke kan komme tilbake til.

Deretter forteller ip rule show deg om noen regel ville ha valgt en annen tabell. Prioriteter betyr noe her, fordi den første regelen som passer vinner, og en regel som fanger alt over din gjør regelen din usynlig.

Installer bare en policyregel hvis det er designet

Kildebasert ruting er et bevisst design, ikke en reparasjon for én applikasjon. Hvis policyeieren vil at trafikk fra tunnelens subnett skal bruke tunnelen, hører regelen hjemme i den eierens konfigurasjon og ikke i en engangskommando på laptopen din.

En brukbar form er en egen tabell med en standardrute gjennom tunnelen, pluss en regel som sender VPN-kildeområdet inn i den tabellen. Legg til unntakene designet trenger, fordi en tabell som bare inneholder en tunnelstandard vil fange destinasjoner som skal forbli lokale eller nås over den fysiske veien.

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

Rull tilbake med ip rule del og ip route flush table 100. Alt som legges til slik forsvinner ved omstart med mindre en behandler skriver det, noe som både er en sikkerhetsegenskap og en grunn til ikke å ha den eneste kopien i shell-historikken din.

Verifiser med tre observasjoner

Noter kilden applikasjonen ba om, ruten oppslaget valgte, og kilden serveren faktisk så.

Disse tre kan være uenige, og hver uenighet peker et annet sted. Et opptak på tunnelgrensesnittet beviser at pakken gikk ut med riktig kilde. Et opptak på det fysiske grensesnittet beviser at den gikk ut feil vei. Servervisningen er den eneste som beviser veien ende til ende.

Hvis applikasjonen tilbyr en bind-til-enhet-funksjon eller en rutingmodus per app, behandle den som en annen mekanisme med andre begrensninger. Lignende innstillinger fører ikke alle til den samme kjernebeslutningen.