App bunden till ett gränssnitt? Dess VPN-väg är inte standard

En applikation på maskinen går ut via VPN och en annan gör det inte, och båda användarna svär att de inte ändrat något. Skillnaden är ofta ett bindningsbeslut som applikationen själv fattar: en socket knuten till en enhet, en källadress vald före anslutningen eller ett namnutrymme med egen routingtabell. Var och en ändrar vilken väg som gäller, och ingen av dem syns i en allmän IP-kontroll i webbläsaren.

Tre olika bindningar, tre olika effekter

Bindning till en enhet och bindning till en källadress är besläktade operationer med olika konsekvenser. En enhetsbindning kan tvinga trafiken ut genom ett gränssnitt och kringgå den normala ruttuppslagningen för den socketen. En källadressbindning går fortfarande genom ruttvalet, men den valda källan kan matcha en policyregel och skicka paketet någon annanstans. Skillnaden låter akademisk tills en regel routar efter källa. Då avgör den allt.

Ett nätverksnamnutrymme är det tredje fallet. Det har egna gränssnitt och en egen routingtabell, så en applikation där inne påverkas inte alls av värdens standard. Behandlar man alla tre som samma sak får man självsäkra förklaringar som inte överlever det första testet.

Avgör vad appen faktiskt ställer in

Läs applikationens nätverkskonfiguration eller dess dokumenterade beteende innan du rör rutter. Om den erbjuder ett gränssnittsval, ett källadressfält eller ett namnutrymmesalternativ är den inställningen det första som bör undersökas. Om inte kan bindningen vara intern och bara synlig via spårning eller dess egen diagnostik.

På Linux har socketalternativ som SO_BINDTODEVICE ett dokumenterat omfång och krav på behörigheter, och en oprivilegierad process kan kanske inte sätta dem alls. Den begränsningen är en användbar ledtråd: om alternativet inte kan tillämpas är applikationen troligen inte källan till skillnaden.

Policyrouting läser källan

När policyrouting är konfigurerad kan en regel välja en tabell utifrån paketets källa. En socket som binder en källadress kan därför följa en regel som standardvägen aldrig rör, även om inget gränssnitt nämns uttryckligen.

Reproducera sökningen med samma adressfamilj, källa och namnutrymme som applikationen använder. En allmän ruttsökning från ett skal i värdens namnutrymme svarar på en annan fråga, och den diskrepansen är den vanligaste orsaken till att en fungerande rutt ser trasig ut.

Delad tunnel och hjälpprocesser

Delad tunnel per app lägger till ytterligare ett lager. Klienten kan matcha applikationens paket eller process, och en hjälpare som öppnar sin egen socket är ett eget subjekt. En startare och dess bakgrundstjänst kan ge olika anslutningar under samma synliga namn.

Kontrollera om regeln för delad tunnel täcker processen som faktiskt ansluter. Om appen binder till ett visst gränssnitt och VPN-klienten matchar efter paket kan de två besluten gå isär utan att något av dem är fel.

Testa appens egen väg

Kör en ny begäran från applikationen efter varje ändring. En webbläsare som visar den utgång du ville ha är inte likvärdigt bevis för ett annat program bundet till ett annat gränssnitt, och cachade anslutningar kan fortsätta använda den gamla vägen långt efter att en inställning ändrats. Stäng den gamla sessionen innan du bedömer den nya regeln. Annars mäter testet det förflutna.

Linux-referensen för sockets dokumenterar SO_BINDTODEVICE och dess krav. Läs applikationens egen konfiguration först, återskapa sökningen i samma sammanhang och avgör först då om rutten eller bindningen behöver ändras.