VPN-håndtrykk i praksis: hva som skjer før trafikken går

Når du velger Koble til, settes fire uavhengige oppgaver i gang, og hver av dem kan lykkes eller svikte på egen hånd. Klienten skal finne en lytter, bli enig med motparten om identitet, lage nøkler og til slutt gi en tunnel som virker videre til resten av systemet. Feilsøkingen havner ofte i gal oppgave. Nettopp derfor er den første feilmeldingen viktigere enn forsøk nummer tre.

Finn lytteren først

Før identiteter i det hele tatt utveksles, slår klienten opp et navn, velger vei og åpner en forbindelse mot en port. Et captive portal som svarer på alt, en stengt port og et galt vertsnavn feiler alle i dette steget, og ingen av dem handler om autentisering. Nytt passord hjelper ikke mot noen av de tre. Se på første linje i feilmeldingen før du begynner å justere på innloggingen.

Tidsavbrudd, avvist sertifikat og avvist konto er tre ulike feil som krever tre ulike kontroller. Ved å skille dem tidlig unngår du å feilsøke et nettverksproblem som om det var et innloggingsproblem.

Bevis motparten, lag så nøkler

Protokollen må kunne kjenne igjen serveren den skal snakke med, enten gjennom en oppsatt offentlig nøkkel eller gjennom en kjede av sertifikater. Innloggingen til brukeren er et tillegg til denne kontrollen, og kommer ikke i stedet for den. En server som tar imot passordet ditt, har ikke bevist noe som helst om sin egen identitet. Derfor er en delt hemmelighet skrevet inn i klienten ingen erstatning for å sjekke hvem som faktisk svarte.

Deretter lager utvekslingen trafikknøkler ut fra protokollens egne verdier, og innloggingspassordet er som regel ikke den nøkkelen som settes på hver pakke. Identitetsmateriale som varer lenge og sesjonsnøkler som varer kort, har helt forskjellig levetid og helt forskjellige oppgaver. Det er dette skillet forward secrecy dreier seg om.

La verifiseringen stå på mens du feilsøker, for en tunnel som kobler seg opp etter at du har slått av en kontroll, har bare vist at kontrollen gjorde noe. Skriv ned hva du forandret, og sett det tilbake før neste test.

Tre protokoller, tre samtaler

I en OpenVPN-installasjon over TLS forhandler kontrollkanalen om sikkerhetsparametere mens datakanalen frakter tunneltrafikk, så et valg for datakanalen og et sertifikatproblem befinner seg på hver sin kant. IKEv2 autentiserer begge parter og oppretter så IPsec-sikkerhetsrelasjoner med sine egne levetider. WireGuard lager nøkler gjennom utvekslingen sin basert på Noise og holder tilstandsmaskinen med vilje liten. Hvilken av de tre du faktisk bruker, avgjør hvilken logg det er bryet verdt å lese.

At to klienter ser like ut, betyr ikke at meldingene bak dem kan byttes om, og et felt i konfigurasjonen som finnes i ett produkt, har kanskje ingen motsvarighet i et annet. Å kopiere en profil fra den ene til den andre er gjetting, ikke migrering.

Hva håndtrykket ikke får gjort

Ruter, navneoppslag og regler for hvilke adresser som skal nås, ligger alle sammen der fortsatt. Et internt nettsted kan være utilgjengelig fordi ruten til subnettet mangler, selv når motparten er riktig autentisert og tunnelen er oppe. Behandler du det som svak kryptering, leter du i feil lag, og det ender som regel med en endring av chiffer som ikke løser noe.

Både nøkkelbytte og gjenoppkobling ser omtrent like ut i de fleste statusvisninger, og ingen av dem sier om vanlig trafikk ble stoppet mens avbruddet varte. Det er bare feilpolitikken i klienten som kan svare på det, så les politikken og ikke ikonet.

Gå gjennom trinnene i rekkefølgen over og stopp ved det første som gir en feil. Hvert trinn lenger ned arver tilstanden fra dem før, 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