App bundet til et grensesnitt? VPN-ruten er ikke standardvalget

Én applikasjon på maskinen går ut gjennom VPN, en annen gjør det ikke, og begge brukerne sverger at de ikke har endret noe. Forskjellen er ofte en bindingsavgjørelse som applikasjonen selv tar: en socket knyttet til en enhet, en kildeadresse valgt før forbindelsen eller et navnerom med sin egen rutetabell. Hver av dem endrer hvilken vei som gjelder, og ingen av dem vises i en generell IP-sjekk i nettleseren.

Tre ulike bindinger, tre ulike virkninger

Binding til en enhet og binding til en kildeadresse er beslektede handlinger med ulike konsekvenser. En enhetsbinding kan tvinge trafikk ut gjennom ett grensesnitt og omgå det vanlige ruteoppslaget for den socketen. En kildeadressebinding går fortsatt gjennom rutevalget, men kilden som velges kan treffe en policyregel og sende pakken et annet sted. Forskjellen høres akademisk ut helt til en regel ruter etter kilde. Da avgjør den alt.

Et nettverksnavnerom er det tredje tilfellet. Det har egne grensesnitt og sin egen rutetabell, så en applikasjon der inne blir ikke påvirket av vertens standard i det hele tatt. Behandler man alle tre som det samme, får man selvsikre forklaringer som ikke overlever den første testen.

Avgjør hva appen faktisk setter

Les applikasjonens nettverkskonfigurasjon eller dens dokumenterte oppførsel før du rører ruter. Tilbyr den et grensesnittvalg, et kildeadressefelt eller et navneromsvalg, er den innstillingen det første som bør undersøkes. Hvis ikke, kan bindingen være intern og bare synlig gjennom sporing eller dens egen diagnostikk.

På Linux har socket-alternativer som SO_BINDTODEVICE et dokumentert omfang og krav til tillatelser, og en upriviligert prosess kan kanskje ikke sette dem i det hele tatt. Den begrensningen er et nyttig spor: hvis alternativet ikke kan brukes, er applikasjonen sannsynligvis ikke kilden til forskjellen.

Policyruting leser kilden

Når policyruting er konfigurert, kan en regel velge en tabell ut fra pakkens kilde. En socket som binder en kildeadresse kan derfor følge en regel som standardveien aldri berører, selv om ingen grensesnitt er nevnt eksplisitt.

Gjenskap oppslaget med samme adressefamilie, kilde og navnerom som applikasjonen bruker. Et generelt ruteoppslag fra et skall i vertens navnerom svarer på et annet spørsmål, og det avviket er den vanligste grunnen til at en fungerende rute ser ødelagt ut.

Delt tunnel og hjelpeprosesser

Delt tunnel per app legger til enda et lag. Klienten kan matche applikasjonens pakke eller prosess, og en hjelper som åpner sin egen socket er et eget subjekt. En startprogram og bakgrunnstjenesten kan gi forskjellige forbindelser under samme synlige navn.

Kontroller om regelen for delt tunnel dekker prosessen som faktisk kobler til. Hvis appen binder til et bestemt grensesnitt og VPN-klienten matcher etter pakke, kan de to beslutningene være uenige uten at noen av dem er feil.

Test appens egen vei

Kjør en ny forespørsel fra applikasjonen etter hver endring. En nettleser som viser utgangen du ønsket, er ikke likeverdig bevis for et annet program bundet til et annet grensesnitt, og bufrede forbindelser kan fortsette å bruke den gamle veien lenge etter at en innstilling er endret. Lukk den gamle økten før du vurderer den nye regelen. Ellers måler testen fortiden.

Linux-referansen for sockets dokumenterer SO_BINDTODEVICE og kravene. Les applikasjonens egen konfigurasjon først, gjenskap oppslaget i samme kontekst, og avgjør først da om ruten eller bindingen må endres.