App bunden til eit grensesnitt? VPN-vegen er ikkje standardvalet

Éin applikasjon på maskina går ut gjennom VPN, ein annan gjer det ikkje, og begge brukarane sver på at dei ikkje har endra noko. Skilnaden er ofte ei bindingsavgjerd som applikasjonen sjølv tek: ein socket knytt til ei eining, ei kildeadresse vald før tilkoplinga eller eit namnerom med si eiga rutetabell. Kvar av dei endrar kva veg som gjeld, og ingen av dei synest i ein generell IP-kontroll i nettlesaren.

Tre ulike bindingar, tre ulike verknader

Binding til ei eining og binding til ei kildeadresse er nærskylde handlingar med ulike følgjer. Ei einingsbinding kan tvinge trafikk ut gjennom eit grensesnitt og gå utanom det vanlege ruteoppslaget for den socketen. Ei kildeadressebinding går framleis gjennom rutevalet, men kjelda som vert vald kan treffe ei policyregel og sende pakken ein annan stad. Skilnaden høyrest akademisk ut heilt til ei regel ruter etter kjelde. Då avgjer ho alt.

Eit nettverksnamnerom er det tredje tilfellet. Det har eigne grensesnitt og si eiga rutetabell, så ein applikasjon der inne vert ikkje påverka av standarden til verten i det heile. Behandlar ein alle tre som det same, får ein sjølvsikre forklaringar som ikkje overlever den første testen.

Avgjer kva appen faktisk set

Les nettverkskonfigurasjonen til applikasjonen eller den dokumenterte åtferda før du rører ruter. Tilbyr han eit grensesnittval, eit kildeadressefelt eller eit namneromsval, er den innstillinga det første som bør undersøkjast. Viss ikkje, kan bindinga vere intern og berre synleg gjennom sporing eller eigen diagnostikk.

På Linux har socketval som SO_BINDTODEVICE eit dokumentert omfang og krav til løyve, og ein upriviligert prosess kan kanskje ikkje setje dei i det heile. Den avgrensinga er eit nyttig spor: viss valet ikkje kan nyttast, er applikasjonen truleg ikkje kjelda til skilnaden.

Policyruting les kjelda

Når policyruting er konfigurert, kan ei regel velje ei tabell ut frå kjelda til pakken. Ein socket som bind ei kildeadresse kan difor følgje ei regel som standardvegen aldri rører, sjølv om ingen grensesnitt er nemnde eksplisitt.

Gjer oppslaget på nytt med same adressefamilie, kjelde og namnerom som applikasjonen brukar. Eit generelt ruteoppslag frå eit skal i namnerommet til verten svarar på eit anna spørsmål, og det avviket er den vanlegaste grunnen til at ein fungerande rute ser øydelagd ut.

Delt tunnel og hjelpeprosessar

Delt tunnel per app legg til endå eit lag. Klienten kan matche pakken eller prosessen til applikasjonen, og ein hjelpar som opnar sin eigen socket er eit eige subjekt. Ein startar og bakgrunnstenesta hans kan gje ulike tilkoplingar under same synlege namn.

Kontroller om regelen for delt tunnel dekkjer prosessen som faktisk koplar til. Viss appen bind til eit bestemt grensesnitt og VPN-klienten matcher etter pakke, kan dei to avgjerdene vere usamde utan at nokon av dei er feil.

Test den eigen vegen til appen

Køyr ei ny førespurnad frå applikasjonen etter kvar endring. Ein nettlesar som viser utgangen du ønskte, er ikkje likeverdig prov for eit anna program bunde til eit anna grensesnitt, og bufra tilkoplingar kan halde fram med å bruke den gamle vegen lenge etter at ei innstilling er endra. Lat den gamle økta stengje før du vurderer den nye regelen. Elles måler testen fortida.

Linux-referansen for sockets dokumenterer SO_BINDTODEVICE og krava. Les den eigen konfigurasjonen til applikasjonen først, gjer oppslaget på nytt i same samanheng, og avgjer først då om ruta eller bindinga må endrast.