Egy alkalmazás egy interfészhez kötve? A VPN-útvonala nem az alapértelmezett

Az egyik alkalmazás a gépen a VPN-en keresztül lép ki, a másik nem, és mindkét felhasználó esküszik, hogy semmit nem változtatott. A különbség gyakran magának az alkalmazásnak a kötési döntése: eszközhöz kötött socket, a kapcsolat előtt választott forrás-cím vagy saját útválasztási táblával rendelkező névtér. Mindegyik megváltoztatja, melyik útvonal érvényes, és egyik sem jelenik meg a böngésző általános IP-ellenőrzésében.

Három különböző kötés, három különböző hatás

Az eszközhöz kötés és a forrás-címhez kötés rokon műveletek, de a következményeik eltérnek. Az eszközkötés arra kényszerítheti a forgalmat, hogy egy interfészen lépjen ki, és megkerülheti az adott socket szokásos útvonalkeresését. A forrás-cím kötése továbbra is átmegy az útvonalválasztáson, de a választott forrás egy házirend-szabálynak megfelelve máshová küldheti a csomagot. A megkülönböztetés addig tűnik elméletinek, amíg egy szabály forrás szerint nem irányít. Akkor mindent eldönt.

A hálózati névtér a harmadik eset. Saját interfészei és saját útválasztási táblája vannak, ezért a benne lévő alkalmazásra a gazdagép alapértelmezése egyáltalán nem hat. Ha mindhármat ugyanannak tekintjük, magabiztos magyarázatok születnek, amelyek nem élik túl az első tesztet.

Határozza meg, mit állít be valójában az alkalmazás

Olvassa el az alkalmazás hálózati konfigurációját vagy dokumentált viselkedését, mielőtt az útvonalakhoz nyúl. Ha interfészválasztást, forrás-cím mezőt vagy névtér-beállítást kínál, ez a beállítás az első, amit meg kell vizsgálni. Ha nem, a kötés belső lehet, és csak nyomkövetéssel vagy saját diagnosztikájával válik láthatóvá.

Linuxon az olyan socket-beállításoknak, mint a SO_BINDTODEVICE, dokumentált hatókörük és jogosultsági követelményeik vannak, és egy nem kiemelt folyamat egyáltalán nem tudja beállítani őket. Ez a korlát hasznos nyom: ha a beállítás nem alkalmazható, az alkalmazás valószínűleg nem a különbség forrása.

A házirend-alapú útválasztás olvassa a forrást

Ha házirend-alapú útválasztás van beállítva, egy szabály a csomag forrása alapján választhat táblát. Ezért a forrás-címet kötő socket olyan szabályt követhet, amelyet az alapértelmezett útvonal soha nem érint, még akkor sem, ha egyetlen interfészt sem neveztek meg kifejezetten.

Ismételje meg a keresést ugyanazzal a címcsaláddal, forrással és névtérrel, amelyet az alkalmazás használ. A gazdagép névterében egy shellből indított általános útvonalkeresés más kérdésre válaszol, és ez az eltérés a leggyakoribb oka annak, hogy egy működő útvonal töröttnek látszik.

Osztott alagút és segédfolyamatok

Az alkalmazásonkénti osztott alagút még egy réteget ad hozzá. A kliens az alkalmazás csomagjához vagy folyamatához illeszthet, a saját socketet nyitó segéd pedig külön alany. Egy indító és háttérszolgáltatása ugyanazon látható név alatt különböző kapcsolatokat hozhat létre.

Ellenőrizze, hogy az osztott alagút szabálya lefedi-e a ténylegesen kapcsolódó folyamatot. Ha az alkalmazás egy adott interfészhez köt, a VPN-kliens pedig csomag alapján illeszt, a két döntés ellentmondhat anélkül, hogy bármelyik is hibás lenne.

Tesztelje az alkalmazás saját útvonalát

Minden változtatás után indítson új kérést az alkalmazásból. Az a böngésző, amely a kívánt kilépést mutatja, nem egyenértékű bizonyíték egy másik interfészhez kötött másik program számára, és a gyorsítótárazott kapcsolatok még jóval a beállítás megváltoztatása után is használhatják a régi útvonalat. Zárja be a régi munkamenetet, mielőtt megítéli az új szabályt. Különben a teszt a múltat méri.

A Linux socket-referencia dokumentálja a SO_BINDTODEVICE-t és követelményeit. Először olvassa el az alkalmazás saját konfigurációját, ismételje meg a keresést ugyanabban a környezetben, és csak azután döntse el, hogy az útvonalat vagy a kötést kell-e megváltoztatni.