Toepassing aan ’n koppelvlak gebind? Sy VPN-pad is nie die verstek nie

Een toepassing op die masjien gaan deur die VPN uit en ’n ander nie, en albei gebruikers sweer hulle het niks verander nie. Die verskil is dikwels ’n bindingsbesluit wat die toepassing self maak: ’n socket wat aan ’n toestel gekoppel is, ’n bronadres wat voor die verbinding gekies word, of ’n naamruimte met sy eie roetetabel. Elkeen verander watter pad geld, en nie een daarvan wys in ’n algemene blaaier se IP-toets nie.

Drie verskillende bindings, drie verskillende gevolge

’n Binding aan ’n toestel en ’n binding aan ’n bronadres is verwante bewerkings met verskillende gevolge. ’n Toestelbinding kan verkeer uit een koppelvlak dwing en die normale roeteopsoeking vir daardie socket omseil. ’n Bronadresbinding gaan steeds deur roeteseleksie, maar die gekose bron kan by ’n beleidsreël pas en die pakkie elders heen stuur. Die onderskeid klink akademies totdat ’n reël volgens bron roeteer. Dan besluit dit alles.

’n Netwerknaamruimte is die derde geval. Dit het sy eie koppelvlakke en roetetabel, so ’n toepassing binne-in dit word glad nie deur die gasheer se verstek geraak nie. Om al drie as dieselfde ding te behandel, lewer selfversekerde verklarings wat nie die eerste toets oorleef nie.

Bepaal wat die app werklik instel

Lees die toepassing se netwerkkonfigurasie of sy gedokumenteerde gedrag voordat jy aan roetes raak. As dit ’n koppelvlakkeuse, ’n bronadresveld of ’n naamruimte-opsie bied, is daardie instelling die eerste ding om te ondersoek. Indien nie, is die binding dalk intern en net deur naspeuring of sy eie diagnostiek sigbaar.

Op Linux het socket-opsies soos SO_BINDTODEVICE gedokumenteerde omvang en toestemmingsvereistes, en ’n onbevoorregte proses kan dit dalk glad nie instel nie. Daardie beperking is ’n nuttige leidraad: as die opsie nie toegepas kan word nie, is die toepassing waarskynlik nie die bron van die verskil nie.

Beleidsroetering lees die bron

Wanneer beleidsroetering opgestel is, kan ’n reël ’n tabel op grond van die pakkie se bron kies. ’n Socket wat ’n bronadres bind, kan dus ’n reël volg wat die verstekpad nooit raak nie, selfs al is geen koppelvlak eksplisiet genoem nie.

Herhaal die opsoeking met dieselfde adresfamilie, bron en naamruimte wat die toepassing gebruik. ’n Algemene roeteopsoeking uit ’n dop in die gasheernaamruimte beantwoord ’n ander vraag, en daardie wanverhouding is die algemeenste rede waarom ’n werkende roete stukkend lyk.

Gesplete tonnel en hulpprosesse

Per-toepassing gesplete tonnel voeg nog ’n laag by. Die kliënt kan die toepassingspakket of -proses pas, en ’n helper wat sy eie socket oopmaak, is ’n aparte onderwerp. ’n Laaier en sy agtergronddiens kan verskillende verbindings onder dieselfde sigbare naam lewer.

Kontroleer of die gesplete-tonnelreël die proses dek wat werklik verbind. As die app aan ’n spesifieke koppelvlak bind en die VPN-kliënt volgens pakket pas, kan die twee besluite verskil sonder dat een verkeerd is.

Toets die app se eie pad

Voer ’n nuwe versoek uit die toepassing na elke verandering. ’n Blaaier wat die uitgang wys wat jy wou hê, is nie gelykwaardige bewyse vir ’n ander program wat aan ’n ander koppelvlak gebind is nie, en gekaste verbindings kan lank nadat ’n instelling verander het, die ou pad bly gebruik. Sluit die ou sessie voordat jy die nuwe reël beoordeel. Anders meet die toets die verlede.

Die Linux socket-verwysing dokumenteer SO_BINDTODEVICE en sy vereistes. Lees eers die toepassing se eie konfigurasie, herhaal die opsoeking in dieselfde konteks, en besluit eers dan of die roete of die binding moet verander.