App gebonden aan een interface? Het VPN-pad is niet de standaard

Eén applicatie op de machine gaat via de VPN naar buiten en een andere niet, en beide gebruikers zweren dat ze niets hebben veranderd. Het verschil is vaak een bindingsbeslissing van de applicatie zelf: een socket gekoppeld aan een apparaat, een bronadres dat vóór de verbinding is gekozen, of een naamruimte met een eigen routetabel. Elk verandert welk pad geldt, en geen ervan verschijnt in een algemene IP-controle in de browser.

Drie verschillende bindingen, drie verschillende effecten

Binden aan een apparaat en binden aan een bronadres zijn verwante bewerkingen met verschillende gevolgen. Een apparaatbinding kan verkeer dwingen via één interface naar buiten te gaan en de normale routeopzoeking voor die socket omzeilen. Een bronadresbinding gaat nog steeds door routekeuze, maar de gekozen bron kan overeenkomen met een beleidsregel en het pakket elders heen sturen. Het onderscheid klinkt academisch totdat een regel op bron routeert. Dan beslist het alles.

Een netwerknaamruimte is het derde geval. Die heeft eigen interfaces en een eigen routetabel, dus een applicatie erin ondervindt helemaal geen invloed van de standaard van de host. Alle drie als hetzelfde behandelen levert zelfverzekerde verklaringen op die de eerste test niet overleven.

Bepaal wat de app werkelijk instelt

Lees de netwerkconfiguratie van de applicatie of het gedocumenteerde gedrag voordat je routes aanraakt. Biedt het een interfacekeuze, een bronadresveld of een naamruimteoptie, dan is die instelling het eerste dat moet worden onderzocht. Zo niet, dan kan de binding intern zijn en alleen zichtbaar via tracing of de eigen diagnostiek.

Op Linux hebben socketopties zoals SO_BINDTODEVICE een gedocumenteerde reikwijdte en rechtenvereisten, en een proces zonder privileges kan ze misschien helemaal niet instellen. Die beperking is een nuttige aanwijzing: als de optie niet kan worden toegepast, is de applicatie waarschijnlijk niet de bron van het verschil.

Beleidsroutering leest de bron

Wanneer beleidsroutering is geconfigureerd, kan een regel een tabel kiezen op basis van de bron van het pakket. Een socket die een bronadres bindt, kan daardoor een regel volgen die het standaardpad nooit raakt, zelfs als geen interface expliciet is genoemd.

Reproduceer de opzoeking met dezelfde adressenfamilie, bron en naamruimte die de applicatie gebruikt. Een algemene routeopzoeking vanuit een shell in de naamruimte van de host beantwoordt een andere vraag, en die mismatches zijn de meest voorkomende reden dat een werkende route kapot lijkt.

Split-tunneling en hulpprocessen

Split-tunneling per app voegt nog een laag toe. De client kan het pakket of proces van de applicatie matchen, en een helper die zijn eigen socket opent is een apart subject. Een launcher en zijn achtergronddienst kunnen verschillende verbindingen opleveren onder dezelfde zichtbare naam.

Controleer of de split-tunnelregel het proces dekt dat daadwerkelijk verbindt. Als de app aan een bepaalde interface bindt en de VPN-client op pakket matcht, kunnen de twee beslissingen verschillen zonder dat een van beide fout is.

Test het eigen pad van de app

Voer na elke wijziging een nieuw verzoek uit vanuit de applicatie. Een browser die de gewenste uitgang toont, is geen gelijkwaardig bewijs voor een ander programma dat aan een andere interface is gebonden, en gecachte verbindingen kunnen nog lang het oude pad gebruiken nadat een instelling is gewijzigd. Sluit de oude sessie voordat je de nieuwe regel beoordeelt. Anders meet de test het verleden.

De Linux-socketreferentie documenteert SO_BINDTODEVICE en de vereisten. Lees eerst de eigen configuratie van de applicatie, reproduceer de opzoeking in dezelfde context en beslis pas daarna of de route of de binding moet veranderen.