App bundet til en grænseflade? Dens VPN-rute er ikke standarden

Én applikation på maskinen går ud gennem VPN, en anden gør ikke, og begge brugere sværger, at de ikke har ændret noget. Forskellen er ofte en bindingsbeslutning, som applikationen selv træffer: en socket knyttet til en enhed, en kildeadresse valgt før forbindelsen eller et navnerum med sin egen routingtabel. Hver af dem ændrer, hvilken vej der gælder, og ingen af dem vises i en generisk IP-kontrol i browseren.

Tre forskellige bindinger, tre forskellige virkninger

Binding til en enhed og binding til en kildeadresse er beslægtede handlinger med forskellige konsekvenser. En enhedsbinding kan tvinge trafik ud gennem én grænseflade og omgå det normale ruteopslag for den socket. En kildeadressebinding går stadig gennem rutevalget, men den valgte kilde kan matche en politikregel og sende pakken et andet sted hen. Forskellen lyder akademisk, indtil en regel ruter efter kilde. Så afgør den alt.

Et netværksnavnerum er det tredje tilfælde. Det har sine egne grænseflader og sin egen routingtabel, så en applikation derinde slet ikke påvirkes af værtens standard. Behandler man alle tre som det samme, får man selvsikre forklaringer, der ikke overlever den første test.

Afgør, hvad appen faktisk sætter

Læs applikationens netværkskonfiguration eller dens dokumenterede adfærd, før du rører ved ruter. Hvis den tilbyder et grænsefladevalg, et kildeadressefelt eller en navnerumsmulighed, er den indstilling det første, der skal undersøges. Hvis ikke, kan bindingen være intern og kun synlig gennem sporing eller dens egen diagnostik.

På Linux har socket-muligheder som SO_BINDTODEVICE et dokumenteret omfang og krav til tilladelser, og en uprivilegeret proces kan måske slet ikke sætte dem. Den begrænsning er et nyttigt spor: hvis muligheden ikke kan anvendes, er applikationen sandsynligvis ikke kilden til forskellen.

Politikrouting læser kilden

Når politikrouting er konfigureret, kan en regel vælge en tabel ud fra pakkens kilde. En socket, der binder en kildeadresse, kan derfor følge en regel, som standardvejen aldrig berører, selv om ingen grænseflade er nævnt udtrykkeligt.

Genskab opslaget med samme adressefamilie, kilde og navnerum, som applikationen bruger. Et generisk ruteopslag fra en shell i værtens navnerum besvarer et andet spørgsmål, og den uoverensstemmelse er den mest almindelige grund til, at en fungerende rute ser brudt ud.

Opdelt tunnel og hjælpeprocesser

Opdelt tunnel pr. app tilføjer endnu et lag. Klienten kan matche applikationens pakke eller proces, og en hjælper, der åbner sin egen socket, er et separat subjekt. En starter og dens baggrundstjeneste kan give forskellige forbindelser under samme synlige navn.

Kontroller, om reglen for opdelt tunnel dækker den proces, der faktisk forbinder. Hvis appen binder til en bestemt grænseflade, og VPN-klienten matcher efter pakke, kan de to beslutninger være uenige, uden at nogen af dem er forkert.

Test appens egen vej

Kør en ny anmodning fra applikationen efter hver ændring. En browser, der viser den udgang, du ønskede, er ikke tilsvarende bevis for et andet program bundet til en anden grænseflade, og cachede forbindelser kan fortsætte med at bruge den gamle vej længe efter en ændret indstilling. Luk den gamle session, før du bedømmer den nye regel. Ellers måler testen fortiden.

Linux-socketreferencen dokumenterer SO_BINDTODEVICE og dens krav. Læs først applikationens egen konfiguration, genskab opslaget i samme kontekst, og afgør først derefter, om ruten eller bindingen skal ændres.