Ein app bunden til VPN-adressa brukar framleis feil rute

Ein applikasjon bind til VPN-adressa, og sambandet går likevel ut via den vanlege standardruta. Ingenting i bindinga feila; ho gjorde nøyaktig det ei binding gjer. Å binda ein socket til ei lokal adresse vel kjeldeadressa kjernen set i headeren. Det installerer inga rute, og det opprettar ikkje ein policyregel som sender pakkar med den kjelda inn i ein bestemd tunnel.

Resten av denne køyreboka er kontrollrekkjefølgja eg brukar, saman med kommandoen som gjev kvar observasjon.

Kva ei binding faktisk avgjer

Ei binding tildeler ei lokal adresse til socketen. Deretter køyrer kjernen det same ruteoppslaget som han elles ville ha køyrt, med mindre ein policyregel endrar kva tabell oppslaget les.

Difor kan ein pakke gå ut med ei VPN-kjeldeadresse på eit fysisk grensesnitt. På den andre sida kjem han frå eit privatområde nettverket aldri venta på den vegen, returtrafikken har inga rute tilbake, og sambandet heng eller blir nullstilt.

Linux-referansen for IP-socketer dokumenterer semantikken til bindinga. Rutedelen bur i ip-rule og ip-route, og det er separate manualar av ein grunn.

Stadfest at adressa høyrer til dette namnerommet

Ei adresse du kan binda til, må finnast på eit grensesnitt inne i nettverksnamnerommet applikasjonen køyrer i. Ei peer-adresse, ei gateway-adresse eller ei adresse som berre finst i eit anna namnerom kan ikkje bindast, og kallet feilar med EADDRNOTAVAIL.

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

Køyr dei tre i same kontekst som applikasjonen: same namnerom, og same brukar om du får tak i han. Eit gammalt net30-diagram er ikkje prov for kva adresse den noverande topologien din tildelte klienten. Les grensesnittet som faktisk er oppe.

Les oppslaget for den kjelda og den destinasjonen

Éin kommando svarar på spørsmålet bindinga ikkje svara på:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

Den første lina skriv ut ruta ein pakke frå den kjelda til den destinasjonen ville ta, inkludert det utgåande grensesnittet og den føretrekte kjelda. Om ho nemner det fysiske grensesnittet, er bindinga og ruta usamde, og pakken går ut med ei kjelde som vegen ikkje kan kome tilbake til.

Deretter fortel ip rule show deg om nokon regel ville ha valt ein annan tabell. Prioritetar tel her, fordi den første regelen som passar vinn, og ein regel som fangar alt over din gjer regelen din usynleg.

Installer berre ein policyregel om det er designet

Kjeldebasert ruting er eit medvite design, ikkje ein reparasjon for ein applikasjon. Vil policyeigaren at trafikk frå subnettet til tunnelen skal bruka tunnelen, høyrer regelen heime i konfigurasjonen til den eigaren og ikkje i ein eingongskommando på laptoppen din.

Ein brukande form er ein eigen tabell med ei standardrute gjennom tunnelen, pluss ein regel som sender VPN-kjeldeområdet inn i den tabellen. Legg til unntaka designet treng, fordi ein tabell som berre inneheld ein tunnelstandard vil fanga destinasjonar som skal bli verande lokale eller nåast over den fysiske vegen.

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 blir lagt til slik forsvinn ved omstart med mindre ein behandlar skriv det, noko som både er ein tryggleikseigenskap og ein grunn til ikkje å ha den einaste kopien i shell-historia di.

Verifiser med tre observasjonar

Noter kjelda applikasjonen bad om, ruta oppslaget valde, og kjelda serveren faktisk såg.

Desse tre kan vera usamde, og kvar usemje peikar ein annan stad. Eit opptak på tunnelgrensesnittet provar at pakken gjekk ut med rett kjelde. Eit opptak på det fysiske grensesnittet provar at han gjekk ut feil veg. Servervisinga er den einaste som provar vegen ende til ende.

Om applikasjonen tilbyr ein bind-til-eining-funksjon eller ein rutingmodus per app, handsam han som ein annan mekanisme med andre avgrensingar. Liknande innstillingar fører ikkje alle til den same kjerneavgjerda.