Miért töri el a második VPN-alagút az elsőt?

Egy második VPN-kliens telepítése egy ügyfélhálózat eléréséhez a szokásos módja ennek az indulásnak, és az első alagút elsötétül, miközben mindkét kliens sikert jelent. Mindegyik kliens telepített egy alapértelmezett útvonalat, a második konkrétabb volt, és a kernel most azt követi mindenre, kivéve az első alagút saját külső kapcsolatát. Semmi nem omlott össze, és egyik profil sem hibás. Az egyik útvonal lecserélte a másikat, és a megoldás eldönteni, melyik alagút birtokolja az alapértelmezettet.

A tünet: a második kliens csendben nyer

OpenVPN: a redirect-gateway def1 opció nem írja felül a 0.0.0.0/0 útvonalat. Hozzáadja a 0.0.0.0/1 és 128.0.0.0/1 útvonalat: együtt minden IPv4-címet lefednek, és minden előtag hosszában legyőzi a sima alapértelmezettet. Az eredeti alapértelmezett a táblában marad, és többé nem használják rendes forgalomra, a VPN-kiszolgálóhoz vezető gazdagép-útvonal pedig megakadályozza, hogy az alagút elkapja a saját külső csomagjait. Mindkét kliens ezt teszi, és a második egyszerűen később telepíti a párját.

Ezért tűnik az első alagút halottnak, nem pedig leválasztottnak. A felülete fent van, a vezérlőcsatornája él, és már semmilyen alkalmazásforgalom nem éri el. A fordított panasz ugyanazt a hiányzó pusht mutatja: a telefon, amely csatlakozik, de nem küld semmit, általában olyan kiszolgálóval beszél, amely soha nem hirdette a redirect-gatewayt, így az eszköz megtartja a saját alapértelmezettjét, és csak a poolt éri el.

Készíts útvonal-pillanatképet a második kliens csatlakozása előtt és után. A táblában megjelenő két félútvonal jelenti a teljes változást, és mindkét panaszt megmagyarázzák. Semmi másnak nem kell elmozdulnia a táblában ahhoz, hogy a tünet megjelenjen. Ezért állítja helyre a második kliens eltávolítása azonnal az elsőt.

Olvasd el, melyik alagút nyer valójában

Ne a kliensek indítási sorrendjéből vagy a tálcán lévő ikonból következtesd a győztest. Kérdezd meg a kernelt, melyik útvonalat használná a két magánhálózaton kívüli célra, és olvasd el a visszakapott felületet.

ip route show
ip route get 198.51.100.24
route print -4
Find-NetRoute -RemoteIPAddress 198.51.100.24

Az első kettő a Linux válasza, az utolsó kettő a Windows megfelelője. Futtasd őket, amíg mindkét alagút fent van, majd bontsd az egyiket, és futtasd újra. A két kimenet közötti különbség az a tény, amelyre a megoldás kiválasztása előtt szükséged van, és kevesebb időt vesz igénybe, mint bármelyik kliens naplójának elolvasása.

Jegyezd fel az eredményt, beleértve a felület nevét és az egyező előtagot. Az a jegy, amely szerint a második VPN eltörte az elsőt, a tünet leírása, nem olyan útvonal-állítás, amelyre bárki támaszkodhat. A lekérdezés ténnyé teszi, amelyet a következő mérnök egyetlen paranccsal megismételhet.

Windows: akadályozd meg, hogy egy profil birtokolja az alapértelmezettet

A Windows tárolt profilokat tart, és a beépített kliens engedi, hogy az egyik a másiktól függjön, így az első automatikusan feljön, amikor a második tárcsáz. A legutóbb csatlakozott profil hajlamos megtartani az alapértelmezettet, tehát a gyakorlati tulajdonos az utolsó tárcsázás, nem az első. Adj minden profilnak saját push-útvonalakat, és kapcsold be a split tunnelinget annál, amelyiknek nem szabad birtokolnia az alapértelmezettet.

Set-VpnConnection -Name "Contoso" -SplitTunneling $true
rasdial Contoso

A split tunneling ezt megváltoztatja: csak a kiszolgáló által pusholt előtagok kerülnek a táblába, ami az első alagútnál hagyja az alapértelmezettet. A terv továbbra is meghiúsul, ha mindkét kiszolgáló alapértelmezett útvonalat pushol, mert akkor az utolsó kapcsolat nyer, és ezen egyetlen kliensoldali beállítás sem változtat. Javítsd a push-t a kiszolgálói oldalon, vagy fogadj el egy tulajdonost.

Az alkalmazás által indított profilok más funkció, és érdemes tudni róluk: egy Windows-profil elindulhat, amikor egy megnevezett végrehajtható fájl elindul, és a forgalomszűrők döntik el, mit szállít. Ez profilbeállítás, nem tűzfalszabály, és más problémát old meg, mint az alapértelmezett útvonal konfliktusa.

Linux: tartsd a második alagutat a fő táblán kívül

Két openvpn --config-példány futtatása egy gépen mindkét klienst ugyanabba a táblába teszi, és három lehetőség választja szét őket növekvő izolációval. A legkönnyebb teljesen megakadályozni, hogy a második kliens szerkessze a táblát: route-nopull és explicit útvonalak, vagy egy route-up szkript, amely csak azt telepíti, amit szándékozol. Akkor a második alagút pontosan az általad megnevezett előtagokat szállítja, és semmi mást. Akkor te döntöd el, melyik előtag hová megy, ahelyett hogy utólag fedezed fel.

A házirend-alapú útválasztás a középső lehetőség. Egy szabály külön táblát választ egy forráscímhez vagy tűzfaljelöléshez, és az a tábla szállítja a második alagút útvonalait. A fordított útvonal szűrése itt a csapda, mert a válasz, amely más felületen érkezik, mint amelyet a tábla választana, eldobódik, ezért ellenőrizd a rp_filter beállítást, mielőtt arra jutsz, hogy az alagút elromlott.

ip rule add from 10.44.7.0/24 table 100
ip route add default dev tun1 table 100
sysctl net.ipv4.conf.all.rp_filter

A hálózati névterek a legnehezebb és legtisztább lehetőség. Indítsd a második klienst a ip netns belsejében, adj neki egy veth-párt, és lépj be abba a névtérbe, hogy használd. Az interferencia megszűnik, mert minden névtér saját táblákkal rendelkezik ahelyett, hogy egyet osztana meg, ami megéri a plusz beállítást, ha mindkét alagútnak hetekig fent kell maradnia.

Alkalmazásonként, és a láncolás külön problémaként

Néha csak egy programnak kellene a második alagutat használnia. Linuxon a felhasználó, cgroup vagy port szerinti házirend-útválasztás eléri ezt az eredményt, és egyetlen cél egy felülethez rögzíthető anélkül, hogy az alapértelmezettet egyáltalán érintenénk. Az az alkalmazás, amely a socketjét egy felülethez rögzíti, egyáltalán nem konzultál az útválasztási táblával, így egy indító tovább használhatja a fizikai adaptert, amíg a saját beállításain belül nem választanak címet.

A láncolás más művelet, mint két alagút egymás melletti futtatása. Az A láncolása B fölött azt jelenti, hogy a belső kiszolgáló címének elérhetőnek kell lennie a külső alagút belsejéből. A külső kliens sem tekintheti a belső kliens titkosított csomagjait szivárgásnak. Egy kliens egy virtuális gépen belül a durva, de megbízható változat; mindkettő egy hoszton a fenti útválasztási munkát igényli, plusz egy külső útvonalat a belső kiszolgáló felé, amely soha nem lép be a belső alagútba.

Írd fel az alapértelmezett tulajdonosát, az egyes alagutak által szállított előtagok listáját és a DNS-útvonalat. Ez a három tény a következő incidenst kereséssé teszi vizsgálat helyett.