VPN-kézfogás lépései: mi történik, mielőtt az adatforgalom elindul

A Csatlakozás megnyomása négy különálló feladatot indít, amelyek egymástól függetlenül sikerülnek vagy hiúsulnak meg. Az ügyfélnek el kell érnie egy figyelőt, meg kell állapodnia abban, ki a partner, kulcsokat kell származtatnia, majd át kell adnia egy működő alagutat a rendszer többi részének. A legtöbb sikertelen kapcsolatot rossz feladatban diagnosztizálják. Ezért az első hiba többet számít, mint a harmadik próbálkozás.

Először érje el a figyelőt

Mielőtt bármilyen identitás kicserélődne, az ügyfél felold egy nevet, útvonalat választ és transzportot nyit egy porthoz. A mindenre válaszoló captive portál, a zárt port és a hibás gépnév mind itt hiúsul meg, és egyik sem hitelesítési probléma. A jelszó megváltoztatása egyiket sem tudja kijavítani. Olvassa el a hiba első sorát, mielőtt hozzányúlna a hitelesítő adatokhoz.

Az időtúllépés, a tanúsítvány elutasítása és az elutasított fiók három különböző hiba, három különböző ellenőrzéssel. Elsőként való szétválogatásuk az, ami megakadályozza, hogy egy hálózati problémát hitelesítőadat-problémaként debugoljanak.

Igazolja a partnert, majd származtasson kulcsokat

Minden protokolnak szüksége van módra, hogy felismerje a szándékolt kiszolgálót, akár beállított nyilvános kulcs, akár tanúsítványlánc révén. A felhasználói bejelentkezés kiegészíti ezt az ellenőrzést, nem helyettesíti. Egy kiszolgáló, amely elfogadja a jelszavát, semmit sem bizonyított a saját identitásáról. Ezért az ügyfélbe beírt közös titok nem helyettesíti annak ellenőrzését, ki válaszolt.

A csere ezután a protokoll saját bemeneteiből származtatja a forgalmi kulcsokat, és a bejelentkezési jelszó általában nem az a kulcs, amelyet minden csomagra rányomnak. A hosszú távú identitásanyag és a rövid életű munkamenet-kulcsok élettartama és feladata eltérő. Pontosan erről a szétválasztásról szól az előretekintő titkosság.

Hibakeresés közben tartsa bekapcsolva az ellenőrzést, mert egy alagút, amely egy ellenőrzés kikapcsolása után kapcsolódik, semmit sem bizonyított azon kívül, hogy az az ellenőrzés valamit tett. Jegyezze fel, mit változtatott, és a következő teszt előtt állítsa vissza.

Három protokoll, három beszélgetés

Egy TLS-alapú OpenVPN-telepítésben a vezérlőcsatorna tárgyalja a biztonsági paramétereket, míg az adatcsatorna szállítja az alagút forgalmát, így az adatcsatorna-beállítás és a tanúsítványprobléma külön helyen él. Az IKEv2 hitelesíti mindkét felet, majd saját élettartamú IPsec biztonsági társulásokat hoz létre. A WireGuard a Noise-alapú cseréjén keresztül származtat kulcsokat, és szándékosan kicsiben tartja az állapotgépet. Annak ismerete, melyiket futtatja a három közül, eldönti, melyik naplót érdemes elolvasni.

A hasonlóan kinéző ügyfelek nem jelentenek alatta felcserélhető üzeneteket, és egy adott termékben létező konfigurációs mezőnek lehet, hogy nincs megfelelője egy másikban. A profil másolása köztük találgatás, nem migráció.

Mit nem tesz a kézfogás

Az útvonalak, a névfeloldás és a célpolitika mind megmaradnak utána. Egy belső webhely elérhetetlen maradhat, mert hiányzik az alhálózatának útvonala, pedig a partner helyesen hitelesítve lett, és az alagút működik. Ha ezt gyenge titkosításként kezeli, a rossz rétegben keres, és ez általában olyan titkosításmódosítással végződik, amely semmit sem javít.

A kulcsfrissítés és az újracsatlakozás a legtöbb állapotjelzésben szintén hasonlónak látszik, és egyik sem mondja meg, hogy a kiesés idején blokkolva volt-e a szokásos forgalom. Csak az ügyfél hiba-politikája válaszol erre a kérdésre, ezért a politikát olvassa, ne az ikont.

Dolgozza fel a szakaszokat a fenti sorrendben, és álljon meg az elsőnél, amely hibát eredményez. Minden későbbi szakasz örökli a korábbiak állapotát, ezért a harmadik szakasz hibája semmit sem mond a negyedikről.

ip -brief address show tun0
ip route get 10.60.7.15
resolvectl query intranet.corp.internal