VPN-håndtrykstrin: hvad der sker, før trafikken løber

Når du trykker på Forbind, starter fire separate opgaver, som lykkes eller fejler uafhængigt. Klienten skal nå en lytter, blive enig om, hvem modparten er, udlede nøgler og derefter overdrage en fungerende tunnel til resten af systemet. De fleste mislykkede forbindelser diagnosticeres i den forkerte opgave. Derfor betyder den første fejl mere end det tredje forsøg.

Nå først frem til lytteren

Før nogen identitet udveksles, slår klienten et navn op, vælger en rute og åbner en transport til en port. En captive portal, der svarer på alt, en lukket port og et forkert værtsnavn fejler alle her, og ingen af dem er et godkendelsesproblem. At ændre en adgangskode kan ikke rette nogen af de tre. Læs den første linje af fejlen, før du rører ved legitimationsoplysningerne.

En timeout, en certifikatafvisning og en afvist konto er tre forskellige fejl med tre forskellige kontroller. At sortere dem først er det, der forhindrer, at et netværksproblem bliver fejlsøgt som et legitimationsproblem.

Bevis modparten, udled derefter nøgler

Hver protokol har brug for en måde at genkende den tilsigtede server på, enten via en konfigureret offentlig nøgle eller en certifikatkæde. Et brugerlogin kommer oveni den kontrol, ikke i stedet for den. En server, der accepterer din adgangskode, har ikke bevist noget om sin egen identitet. Derfor er en delt hemmelighed, der tastes ind i en klient, ikke en erstatning for at verificere, hvem der svarede.

Udvekslingen udleder derefter trafiknøgler fra protokollens egne input, og loginadgangskoden er generelt ikke den nøgle, der stemples på hver pakke. Langsigtet identitetsmateriale og kortlivede sessionsnøgler har forskellige levetider og forskellige opgaver. Den adskillelse er, hvad forward secrecy handler om.

Hold verifikationen aktiveret, mens du fejlsøger, fordi en tunnel, der forbinder, efter at du har deaktiveret en kontrol, ikke har bevist andet, end at kontrollen gjorde noget. Noter, hvad du ændrede, og sæt det tilbage før den næste test.

Tre protokoller, tre samtaler

I en TLS-baseret OpenVPN-udrulning forhandler kontrolkanalen sikkerhedsparametre, mens datakanalen bærer tunneltrafik, så en datakanal-indstilling og et certifikatproblem ligger på forskellige steder. IKEv2 godkender begge deltagere og opretter derefter IPsec-sikkerhedsassociationer med deres egne levetider. WireGuard udleder nøgler via sin Noise-baserede udveksling og holder tilstandsmaskinen bevidst lille. At vide, hvilken af de tre du kører, afgør, hvilken log der er værd at læse.

Ens udseende klienter betyder ikke, at meddelelserne underneden kan udskiftes, og et konfigurationsfelt, der findes i ét produkt, har måske ingen modpart i et andet. At kopiere en profil mellem dem er et gæt og ikke en migrering.

Hvad håndtrykket ikke gør

Ruter, navneopløsning og destinationspolitik består alle bagefter. Et internt websted kan forblive utilgængeligt, fordi dets undernetrute mangler, selvom modparten blev godkendt korrekt, og tunnelen er oppe. At behandle det som svag kryptering sender dig til at lede i det forkerte lag, og det ender normalt med en cipherændring, der ikke retter noget.

Nøglefornyelse og genopkobling ser også ens ud i de fleste statusvisninger, og ingen af dem fortæller dig, om normal trafik blev blokeret under afbrydelsen. Kun klientens fejlpolitik svarer på det spørgsmål, så læs politikken i stedet for ikonet.

Kør trinnene i rækkefølgen ovenfor, og stop ved det første, der giver en fejl. Hvert senere trin arver tilstanden fra de tidligere, så en fejl i tredje trin siger intet om det fjerde.

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