Trinn i VPN-håndtrykk: hva som skjer før trafikken flyter

Å trykke Koble til starter fire separate jobber som lykkes eller feiler uavhengig. Klienten må nå en lytter, bli enig om hvem motparten er, utlede nøkler og deretter overlevere en fungerende tunnel til resten av systemet. De fleste mislykkede tilkoblinger diagnostiseres i feil jobb. Derfor betyr den første feilen mer enn det tredje forsøket.

Nå frem til lytteren først

Før noen identitet utveksles, slår klienten opp et navn, velger en rute og åpner en transport til en port. En captive portal som svarer på alt, en lukket port og et feil vertsnavn feiler alle her, og ingen av dem er et autentiseringsproblem. Å endre et passord kan ikke rette noen av de tre. Les den første linjen i feilen før du rører ved påloggingsinformasjonen.

En tidsavbrudd, en sertifikatavvisning og en avvist konto er tre forskjellige feil med tre forskjellige kontroller. Å sortere dem først er det som hindrer at et nettverksproblem blir feilsøkt som et påloggingsproblem.

Bevis motparten, utled deretter nøkler

Hver protokoll trenger en måte å gjenkjenne den tiltenkte serveren på, enten via en konfigurert offentlig nøkkel eller en sertifikatkjede. En brukerpålogging kommer i tillegg til den kontrollen, ikke i stedet for den. En server som godtar passordet ditt, har ikke bevist noe om sin egen identitet. Derfor er en delt hemmelighet som skrives inn i en klient, ikke en erstatning for å verifisere hvem som svarte.

Utvekslingen utleder deretter trafikknøkler fra protokollens egne inndata, og påloggingspassordet er vanligvis ikke nøkkelen som stemples på hver pakke. Langsiktig identitetsmateriale og kortlevde sesjonsnøkler har ulik levetid og ulike oppgaver. Det er denne adskillelsen forward secrecy handler om.

Hold verifiseringen aktiv mens du feilsøker, fordi en tunnel som kobles til etter at du har deaktivert en kontroll, ikke har bevist annet enn at kontrollen gjorde noe. Noter hva du endret, og sett det tilbake før neste test.

Tre protokoller, tre samtaler

I en TLS-basert OpenVPN-utrulling forhandler kontrollkanalen sikkerhetsparametere mens datakanalen bærer tunneltrafikken, så et datakanalvalg og et sertifikatproblem ligger på forskjellige steder. IKEv2 autentiserer begge deltakerne og etablerer deretter IPsec-sikkerhetsassosiasjoner med egne levetider. WireGuard utleder nøkler gjennom sin Noise-baserte utveksling og holder tilstandsmaskinen bevisst liten. Å vite hvilken av de tre du kjører avgjør hvilken logg som er verdt å lese.

Klienter som ser like ut betyr ikke at meldingene under kan byttes om, og et konfigurasjonsfelt som finnes i ett produkt, har kanskje ingen motpart i et annet. Å kopiere en profil mellom dem er en gjetning og ikke en migrering.

Hva håndtrykket ikke gjør

Ruter, navneoppslag og destinasjonspolicy består alle etterpå. Et internt nettsted kan forbli utilgjengelig fordi undernettets rute mangler, selv om motparten ble autentisert riktig og tunnelen er oppe. Å behandle det som svak kryptering sender deg til å lete i feil lag, og det ender vanligvis med en chifferendring som ikke retter noe.

Nøkkelrotasjon og gjentilkobling ser også like ut i de fleste statusvisninger, og ingen av dem forteller deg om vanlig trafikk ble blokkert under avbruddet. Bare klientens feilpolicy svarer på det spørsmålet, så les policyen i stedet for ikonet.

Arbeid gjennom trinnene i rekkefølgen ovenfor og stopp ved det første som gir en feil. Hvert senere trinn arver tilstanden fra de tidligere, så en feil i tredje trinn sier ingenting om det fjerde.

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