Beágyazott VPN: melyik alagút viszi a külső kapcsolatot?

Két egyszerre futó VPN-kliens nem hoz létre beágyazott alagutat; két alagutat és vitát hoz létre az útválasztásról. Beágyazott alagút akkor létezik, amikor a belső kliens saját szerveréhez vezető kapcsolatát maga a külső alagút viszi, és ez egy szándékosan épített elrendezés. Ha jól sikerül, a belső szerver a külső szerver címét látja; ha rosszul, az egyik kliens csendben újracsatlakozik a másik körül. Három feltétel dönti el, hogy a beágyazás valódi-e vagy véletlen.

Három feltétel dönti el a beágyazást

Az első az, hogy melyik végpontnak melyik útvonalra van szüksége. Nevezd meg a belső szerver címét, nevezd meg a külső szerver címét, és mondd ki egyértelműen, hogy a belső szerver csak a külső alagúton keresztül érhető el. Minden más ebből a mondatból következik, beleértve azt is, mely útvonalak melyik táblába tartoznak.

A második az, hogy látod-e az útvonalat minden rétegen. Ha nem tudod megkérdezni a kernelt, melyik útvonalat használná egy adott cél, akkor a láncot egy végső kilépő IP-ből következteted, és éppen ez az a bizonyíték, amely nem képes megkülönböztetni a beágyazást a véletlentől.

A harmadik az, hogy mi történik, amikor a külső alagút leesik. A belső alagút leállhat vele, újracsatlakozhat a közönséges hálózaton, vagy blokkolva maradhat, amíg a külső útvonal vissza nem tér, és mindhárom védhető szabály. Nem ugyanaz a szabály, és a legtöbb kliens alapértelmezett viselkedése a második. Az a kliens, amely újracsatlakoztatja a végpontját a fizikai hálózaton, miközben egészséges kapcsolatot mutat, a leggyakoribb módja annak, hogy egy szándékolt lánc csendben két független alagúttá váljon.

Első feltétel: melyik végpontnak melyik útvonalra van szüksége

ip route get 203.0.113.10 közvetlenül megválaszolja ezt a kérdést: kiírja az útvonalat, a forráscímet és azt az interfészt, amelyet a kernel most erre a célra használna.

Futtasd le a belső szerverre, mielőtt a belső kliens elindul, majd még egyszer utána, és hasonlítsd össze. Ha a válasz a fizikai interfészről a külső alagút interfészére vált, a beágyazás abban a pillanatban valódi. Ha nem változik, a belső kliens közvetlenül csatlakozik, bármit mond a panel. Ismételd meg a külső szerver címére, amelyet továbbra is a fizikai interfészen keresztül kell feloldani, mert az az útvonal, amely rekurzívan elkapja mindkét végpontot, az a hiba, amely teljesen leveszi a gépet a hálózatról.

Második feltétel: vizsgáld meg az útvonalat minden rétegen

Az útvonalválasztás egy modern kliensen több, mint a fő tábla. A házirend-szabályok megjelölt csomagokat küldhetnek másik táblába, a kliens a socketjét egy interfészhez kötheti, egy konténernek vagy névtérnek pedig saját táblái vannak. ip rule és ip route show table all a módja annak, hogy kiderítsd, melyik mechanizmus van játékban.

Az a kliens, amely SO_MARK-ot tesz a saját socketjére, vagy úgy van beállítva, hogy egy adott eszközhöz kötődjön, megkerüli az alapértelmezett útvonalat, amelyet azt hitted, hogy elrendeztél. Ez funkció és nem hiba, és azt jelenti, hogy az egyetlen megbízható ellenőrzés az, amely ugyanabban a névtérben fut, mint a kliens. Ha a kliensek konténerekben futnak, az ellenőrzéseket azokban a konténerekben futtasd, ne a gazdagépen.

Harmadik feltétel: mi történik, amikor a külső alagút leesik

A hiba esetén tanúsított viselkedés döntést igényel, nem alapértelmezést. Írd le, mi történjen a belső alagúttal, amikor a külső eltűnik, majd vedd rá a klienseket, hogy ezt tegyék.

A lehetőségek konkrétak. A belső kliens leállítása, amikor a külső útvonal eltűnik, tiszta láncot és nyilvánvaló kiesést ad. Ha hagyjuk közvetlenül újracsatlakozni, az elérhetőséget ad, és csendben eltávolítja azt a tulajdonságot, amelyért a lánc épült. A külső útvonal visszatéréséig tartó blokkolás a legszigorúbb és üzemeltetésileg a legbosszantóbb, mert a külső alagút minden rezdülése látható incidenssé válik.

Teszteld mindhármat ártalmatlan forgalommal és szándékos külső alagút-hibával, mert a konfiguráció olvasása nem mondja meg, melyik van nálad. Öld meg a külső alagutat, figyeld, mit tesz a belső kliens, és ellenőrizd újra az útvonalat, amíg le van állítva. Aztán hozd vissza a külső alagutat, és erősítsd meg, hogy a lánc újra kialakul, ahelyett hogy a belső kliens a közben választott közvetlen útvonalon maradna.

Amit a lánc nem ad meg

A plusz rétegek végpontokat, kulcsokat és hibaállapotokat adnak hozzá; nem adnak hozzá semmilyen anonimitási garanciát, és nem akadályozzák meg a külső üzemeltetőt abban, hogy lássa: létezik alagút. Minden állításnak arról, mitől véd a beágyazás, meg kell neveznie a megfigyelőt, akitől véd.

Az eredmény egy rövid dokumentum, nem működő kapcsolat: melyik végpont melyik útvonalat használja, mi történik külső hiba esetén, és a három parancs, amely megmutatja a jelenlegi állapotot. A strongSwan továbbításról szóló dokumentációja hasznos forrás arról, hogyan továbbítódik az alagút forgalma az interfészek között egy Linux-gazdagépen. Minden kliensfrissítés után futtasd újra az ellenőrzéseket, mert a láncodat létrehozó alapértelmezések nem szerződés. A beágyazott alagút, amelyet nem tudsz megvizsgálni, pletyka állapotfénnyel.