Programvare knyttet til VPN-adressen tar fortsatt feil rute

Programvaren knytter seg til VPN-adressen, men trafikken forlater likevel maskinen gjennom den ordinære standardruten. Bind-kallet har ikke feilet; det gjorde akkurat det et bind-kall skal gjøre. Når en socket knyttes til en lokal adresse, velges den kildeadressen som kjernen skriver inn i hodet. Det legges ingen rute inn, og det lages ingen policyregel som dirigerer pakker med denne kilden ned i en bestemt tunnel.

Resten av denne gjennomgangen er den sjekkrekkefølgen jeg bruker, sammen med kommandoen som gir hvert enkelt observasjonspunkt.

Hva et bind-kall egentlig bestemmer

Et bind-kall tildeler socketen en lokal adresse. Deretter utfører kjernen den samme ruteoppslagningen som den ellers ville ha gjort, så fremt ikke en policyregel endrer hvilken tabell oppslagningen leser fra.

Det er derfor en pakke kan gå ut med VPN-adresse som kilde på et fysisk grensesnitt. Hos mottakeren kommer den fra et privatområde som nettet aldri kunne vente på den veien, returtrafikken mangler rute tilbake, og forbindelsen stopper eller nullstilles.

Linux-dokumentasjonen for IP-socketer beskriver semantikken bak bind-kallet. Den halvdelen som gjelder ruting, ligger i ip-rule og ip-route, og at disse er egne manualsider har en grunn.

Kontroller at adressen hører til dette navnerommet

Den adressen du kan knytte deg til, må finnes på et grensesnitt inne i det nettverksnavnerommet programvaren kjører i. En motpartsadresse, en gatewayadresse eller en adresse som bare finnes i et annet navnerom lar seg ikke knytte til, og kallet returnerer EADDRNOTAVAIL.

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

Kjør disse tre i samme sammenheng som programvaren: samme navnerom, og samme bruker dersom du har tilgang til den. Et gammelt net30-diagram beviser ikke hvilken adresse dagens topologi har gitt klienten. Les av det grensesnittet som faktisk er aktivt.

Les ruteoppslagningen for denne kilden og destinasjonen

Én kommando gir svar på spørsmålet bind-kallet lot stå åpent:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

Den første linjen viser ruten en pakke fra denne kilden til denne destinasjonen ville følge, inkludert utgående grensesnitt og foretrukket kildeadresse. Står det fysiske grensesnittet der, er bind-kallet og ruten uenige, og pakken går ut med en kilde som veien ikke fører tilbake til.

Deretter viser ip rule show om noen regel ville ha pekt på en annen tabell. Rekkefølgen har mye å si her, siden den første regelen som passer, vinner, og en regel som fanger opp alt over din, gjør din egen regel usynlig.

Legg bare inn en policyregel dersom det er den tilsiktede designen

Ruting basert på kilde er et bevisst designvalg, ikke en reparasjon for én programvare. Ønsker eieren av policyen at trafikk fra tunnelens subnett skal bruke tunnelen, hører regelen til i den eierens oppsett og ikke i en engangskommando på din maskin.

En form som fungerer, er en egen tabell med standardrute gjennom tunnelen, i tillegg til en regel som sender VPN-kildeområdet inn i tabellen. Husk unntakene designen krever, for en tabell som bare har en tunnelstandard, vil også fange opp destinasjoner som skal holde seg 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. Det som legges inn på denne måten, forsvinner ved omstart med mindre en behandler skriver det ned, noe som både er en sikkerhetsegenskap og en grunn til å ikke la shell-historikken være eneste kopi.

Bekreft med tre observasjonspunkter

Skriv ned kilden programvaren ba om, ruten oppslagningen valgte, og kilden serveren faktisk observerte.

Disse tre kan vise ulike ting, og hver uoverensstemmelse peker mot et eget sted. Et opptak på tunnelgrensesnittet viser at pakken gikk ut med riktig kilde. Et opptak på det fysiske grensesnittet viser at den gikk ut feil vei. Bare det serveren ser, beviser hele veien fra ende til ende.

Tilbyr programvaren et valg om binding til enhet eller en rutemodus per program, må det behandles som en annen mekanisme med andre begrensninger. Innstillinger som ser like ut, ender ikke nødvendigvis i samme kjernebeslutning.