Steg i VPN-handskakningen: vad som händer innan trafiken flödar

När du trycker på Anslut startas fyra separata uppgifter som lyckas eller misslyckas oberoende av varandra. Klienten måste nå en lyssnare, komma överens om vem motparten är, härleda nycklar och sedan lämna över en fungerande tunnel till resten av systemet. De flesta misslyckade anslutningar diagnostiseras i fel uppgift. Därför betyder det första felet mer än det tredje försöket.

Nå lyssnaren först

Innan någon identitet utbyts slår klienten upp ett namn, väljer en rutt och öppnar en transport till en port. En captive portal som svarar på allt, en stängd port och ett felaktigt värdnamn misslyckas alla här, och ingen av dem är ett autentiseringsproblem. Att byta lösenord kan inte åtgärda någon av de tre. Läs den första raden i felet innan du rör inloggningsuppgifterna.

En timeout, en certifikatavvisning och ett avvisat konto är tre olika fel med tre olika kontroller. Att sortera dem först är det som hindrar att ett nätverksproblem felsöks som ett inloggningsproblem.

Bevisa motparten och härled sedan nycklar

Varje protokoll behöver ett sätt att känna igen den avsedda servern, antingen via en konfigurerad publik nyckel eller en certifikatkedja. En användarinloggning kommer utöver den kontrollen, inte i stället för den. En server som accepterar ditt lösenord har inte bevisat något om sin egen identitet. Därför är en delad hemlighet som skrivs in i en klient ingen ersättning för att verifiera vem som svarade.

Utbytet härleder sedan trafiknycklar från protokollets egna indata, och inloggningslösenordet är vanligtvis inte den nyckel som stämplas på varje paket. Långsiktigt identitetsmaterial och kortlivade sessionsnycklar har olika livslängd och olika uppgifter. Det är den separationen forward secrecy handlar om.

Håll verifieringen påslagen medan du felsöker, eftersom en tunnel som ansluter efter att du stängt av en kontroll inte har bevisat något annat än att kontrollen gjorde något. Anteckna vad du ändrade och sätt tillbaka det före nästa test.

Tre protokoll, tre samtal

I en TLS-baserad OpenVPN-driftsättning förhandlar kontrollkanalen säkerhetsparametrar medan datakanalen bär tunneltrafik, så ett datakanalval och ett certifikatproblem lever på olika ställen. IKEv2 autentiserar båda parterna och upprättar sedan IPsec-säkerhetsassociationer med egna livslängder. WireGuard härleder nycklar genom sitt Noise-baserade utbyte och håller tillståndsmaskinen medvetet liten. Att veta vilket av de tre du kör avgör vilken logg som är värd att läsa.

Klienter som ser likadana ut innebär inte att meddelandena under dem är utbytbara, och ett konfigurationsfält som finns i en produkt har kanske ingen motsvarighet i en annan. Att kopiera en profil mellan dem är en gissning och inte en migrering.

Vad handskakningen inte gör

Rutter, namnsuppslag och destinationspolicy finns alla kvar efteråt. En intern webbplats kan förbli oåtkomlig eftersom dess subnät-rutt saknas, även om motparten autentiserades korrekt och tunneln är uppe. Att behandla det som svag kryptering skickar dig att leta i fel lager, och det slutar oftast med en chifferändring som inte åtgärdar något.

Nyckelrotation och återanslutning ser också likadana ut i de flesta statusvyer, och ingen av dem säger om vanlig trafik blockerades under avbrottet. Bara klientens felpolicy svarar på den frågan, så läs policyn och inte ikonen.

Arbeta igenom stegen i ordningen ovan och stanna vid det första som ger ett fel. Varje senare steg ärver tillståndet från de tidigare, så ett fel i tredje steget säger ingenting om det fjärde.

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