Két VPN-kliens egy asztalon: mi ütközik és mi működik

Két kliens verseng az alapértelmezett útvonalért, a feloldóért és a szűrő illesztőprogramokért. Jegyezze fel, ki birtokolja a kimenetet, majd különítse el a második alagutat egy VM-mel vagy egy netns-szel.

A második kliens csatlakozik, az első erőforrásai feloldhatatlanná válnak, és a jegy azt mondja, hogy a munkahelyi VPN tönkretette a személyeset. Semmi sem romlott el hiba értelmében: mindkét kliens azt tette, amire tervezték, és a gépnek csak egy útválasztási táblája van. Az ütközés négy erőforrás körül van, amelyeket mindegyik kliens a sajátjának feltételez. Haladjon végig rajtuk sorrendben, és a javítás általában tervezési döntéssé válik, nem javítássá.

1. lépés: derítse ki, melyik kliens birtokolja a kimenetet

Olvassa el az aktuális kimeneti döntést, mielőtt bármit módosít. Egy nyilvános cím útvonalkeresése megmondja, melyik interfészt és következő ugrást használná a csomag most, és ez a válasz arra, ki nyert. Hasonlítsa össze a kliensek által létrehozott interfésznevekkel, amelyek általában a termék vagy a protokoll nevét viselik. Ha a keresés arra az alagútra mutat, amelyet nem várt, már megtalálta az ütközést.

ip route get 1.1.1.1
ip route show default
route print

Egyes kliensek egyáltalán nem cserélik le az alapértelmezett útvonalat; két felet adnak hozzá, egyet a címterület alsó feléhez és egyet a felsőhöz, amelyek együtt mindent lefednek. Ez láthatóvá hagyja az eredeti alapértelmezett útvonalat, és a kézi javítást helyesnek mutatja, miközben a forgalom továbbra is az alagúton keresztül távozik. Olvassa a metrikát és az előtag hosszát, ne csak az alapértelmezett bejegyzés létezését.

Álljon meg, ha mindkét kliens ugyanazt az előtagot igényli ugyanazzal a metrikával. A kernel választ egyet, a másik pedig csatlakozottnak látszik, miközben semmit sem szállít.

2. lépés: ellenőrizze a feloldót és az átfedő előtagokat

A DNS a második ütközés, és jellegzetes tünetet okoz: a nevek meghiúsulnak, miközben a címek működnek. Minden kliens a saját feloldóját kényszeríti, és a következő lekérdezéseknél az utolsó író nyer. Kérdezze meg a feloldó szolgáltatást, mit használ kapcsolatonként, ahelyett hogy a kliens beállítási oldalát olvasná.

resolvectl status
Get-DnsClientServerAddress
dig +short intranet.corp.example

Ezután hasonlítsa össze a két hálózat által használt privát előtagokat. Ha mindkét fél ugyanabból a tartományból oszt ki, semmilyen kliensoldali megoldás nem javítja, mert a gép nem tudja megmondani, melyik 10.0.0.0/8 cél melyik alagúthoz tartozik. Az egyik felet újra kell számozni vagy lefordítani, és ez a hálózat tulajdonosaival folytatott beszélgetés, nem konfigurációmódosítás. Az átfedés az egyetlen ütközés, ahol az őszinte válasz az, hogy a tervezésnek változnia kell.

Álljon meg itt, ha az előtagok átfedik egymást. A lista későbbi része mind azt feltételezi, hogy nem fedik át.

3. lépés: válasszon olyan elkülönítési mintát, amely tartós

A megbízható minták elkerülik, hogy két kliens ugyanazon útválasztási tábla ellen fusson. Egyetlen kliens olyan osztott alagút-szabályzattal, amely mindkét privát hálózatot eléri a legegyszerűbb, feltéve hogy a célok nem fednek át, és a szabályzat tulajdonosa egyetért. A virtuális gép vagy a hálózati névtér a következő szint, mert mindegyik saját táblát és saját feloldót kap.

sudo ip netns add vpn2
sudo ip netns exec vpn2 ip link show
sudo ip netns exec vpn2 curl -sI https://intranet.corp.example/

A névtér ugyanazt az elkülönítést adja, mint a virtuális gép, a második operációs rendszer nélkül, de durva élei vannak: az alagút eszközét át kell helyezni bele, és az alkalmazást belül kell elindítani. Az elkülönített fizikai eszköz gyakran a legkevésbé meglepő választás egy személyes VPN-hez egy felügyelt munkahelyi kliens mellett. Az egyik alagút egy másikba rétegzése nem elkülönítési minta; a belső végpontnak a külső alagúton keresztül elérhetőnek kell maradnia, és az elrendezés emellett MTU- és késleltetési problémákat is hoz.

Válasszon egy mintát, és írja le, miért. Ha egy alkalmazás névterét osztott alagúttal keveri a többiek számára, az eredeti ütközést nehezebben hibakereshető formában hozza újra létre.

4. lépés: ellenőrizze mindkét hálózatot ugyanabból a munkamenetből

Teszteljen egy erőforrást mindegyik privát hálózaton abból a környezetből, ahol az alkalmazás valóban fut, nem a saját héjából, ha az alkalmazás névtéren belül fut. Ellenőrizze együtt a kimeneti interfészt, a feloldott címet és a válaszkódot, mert az egyik siker elrejtheti a másik kettő hibáját. Ismételje meg újraindítás után, mert az határozza meg, ki nyer, hogy a kliensek milyen sorrendben indulnak. Pont ezt a sorrendet felejtik el feljegyezni az emberek.

curl -sI https://intranet.corp.example/
curl -sI https://files.personal.example/
ip route get 10.20.30.40

Jegyezze fel a kliensverziókat, az interfészeket, a feloldó állapotát és az egyes hálózatok előtagjait. Amikor egy kliens frissül és megváltoztatja az útvonal-viselkedését, ez a feljegyzés a különbség egy ötperces javítás és egy újjáépítés között. A következő ember nem fogja osztani az emlékét arról, melyik alagút jött fel először.

A lista akkor teljes, ha meg tudja nevezni az alapértelmezett útvonalat birtokló interfészt, az egyes nevek által használt feloldót, a második alagutat elkülönítő mintát és az újraindítás után hálózatonként egy kérés eredményét. Ennél kevesebb egy olyan konfiguráció, amely ma véletlenül működik.

Kapcsolódó cikkek