Kroky handshakeu VPN: čo sa deje, kým začne tiecť prevádzka

Stlačenie Pripojiť spustí štyri samostatné úlohy, ktoré uspejú alebo zlyhajú nezávisle. Klient musí dosiahnuť poslucháča, dohodnúť, kto je protistrana, odvodiť kľúče a potom odovzdať fungujúci tunel zvyšku systému. Väčšina neúspešných pripojení sa diagnostikuje v nesprávnej úlohe. Preto je prvá chyba dôležitejšia ako tretí pokus.

Najprv dosiahnite poslucháča

Predtým, ako sa vymení akákoľvek identita, klient preloží meno, vyberie trasu a otvorí transport na port. Captive portál, ktorý odpovedá na všetko, zatvorený port a nesprávne meno hostiteľa tu zlyhajú a žiadna z týchto vecí nie je problém autentizácie. Zmena hesla nemôže opraviť ani jednu z tých troch. Prečítajte si prvý riadok chyby, kým sa dotknete prihlasovacích údajov.

Časový limit, odmietnutie certifikátu a odmietnutý účet sú tri rôzne poruchy s tromi rôznymi kontrolami. Práve ich prvé roztriedenie bráni tomu, aby sa sieťový problém ladil ako problém údajov.

Preukážte protistranu, potom odvodte kľúče

Každý protokol potrebuje spôsob, ako rozpoznať zamýšľaný server, či už nakonfigurovaným verejným kľúčom alebo reťazou certifikátov. Prihlásenie používateľa je k tejto kontrole navyše, nie jej náhradou. Server, ktorý prijme vaše heslo, nepreukázal nič o svojej vlastnej identite. Preto zdieľané tajomstvo napísané do klienta nenahrádza overenie toho, kto odpovedal.

Výmena potom odvodzuje prevádzkové kľúče z vlastných vstupov protokolu a prihlasovacie heslo zvyčajne nie je kľúč, ktorý sa razia na každý paket. Dlhodobý identitný materiál a krátkodobé kľúče relácie majú rôznu životnosť a rôzne úlohy. Práve o tomto oddelení hovorí dopredná utajenosť.

Ponechajte overovanie zapnuté pri riešení problémov, pretože tunel, ktorý sa pripojí po vypnutí kontroly, nepreukázal nič iné ako to, že kontrola niečo robila. Poznamenajte si, čo ste zmenili, a pred ďalším testom to vráťte.

Tri protokoly, tri rozhovory

V nasadení OpenVPN založenom na TLS vyjednáva riadiaci kanál bezpečnostné parametre, zatiaľ čo dátový kanál prenáša prevádzku tunela, takže voľba dátového kanála a problém s certifikátom žijú na rôznych miestach. IKEv2 autentizuje oboch účastníkov a potom vytvára bezpečnostné asociácie IPsec s vlastnou životnosťou. WireGuard odvodzuje kľúče svojou výmenou založenou na Noise a stavový automat drží zámerne malý. Znalosť toho, ktorý z troch prevádzkujete, rozhoduje o tom, ktorý log stojí za prečítanie.

Podobne vyzerajúci klienti neznamenajú zameniteľné správy pod povrchom a konfiguračné pole, ktoré existuje v jednom produkte, nemusí mať pendant v inom. Kopírovanie profilu medzi nimi je odhad, nie migrácia.

Čo handshake nerobí

Trasy, preklad mien a politika cieľa všetky zostávajú potom. Interná lokalita môže zostať nedostupná, pretože chýba trasa jej podsiete, aj keď je protistrana správne autentizovaná a tunel beží. Považovať to za slabé šifrovanie vás pošle hľadať do nesprávnej vrstvy, a zvyčajne to skončí zmenou šifry, ktorá nič neopraví.

Obnova kľúčov a opätovné pripojenie tiež vyzerajú v väčšine stavových displejov rovnako a ani jedno nehovorí, či bola bežná prevádzka počas výpadku zablokovaná. Na túto otázku odpovedá iba politika zlyhania klienta, takže čítajte politiku, nie ikonu.

Prejdite fázy v uvedenom poradí a zastavte sa na prvej, ktorá vyprodukuje chybu. Každá ďalšia fáza dedí stav predchádzajúcich, takže zlyhanie v tretej fáze nič nehovorí o štvrtej.

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