Stappen van de VPN-handshake: wat er gebeurt voordat verkeer stroomt

Op Verbinden drukken start vier afzonderlijke taken die onafhankelijk slagen of mislukken. De client moet een listener bereiken, overeenkomen wie de peer is, sleutels afleiden en dan een werkende tunnel aan de rest van het systeem overhandigen. De meeste mislukte verbindingen worden in de verkeerde taak gediagnosticeerd. Daarom telt de eerste fout zwaarder dan de derde poging.

Bereik eerst de listener

Voordat er enige identiteit wordt uitgewisseld, lost de client een naam op, kiest een route en opent een transport naar een poort. Een captive portal die alles beantwoordt, een gesloten poort en een verkeerde hostnaam falen allemaal hier, en geen van drieën is een authenticatieprobleem. Een wachtwoord wijzigen kan geen van de drie oplossen. Lees de eerste regel van de fout voordat je inloggegevens aanraakt.

Een time-out, een certificaatweigering en een geweigerd account zijn drie verschillende storingen met drie verschillende controles. Ze eerst sorteren is wat voorkomt dat een netwerkprobleem als inloggegevensprobleem wordt gedebugd.

Bewijs de peer en leid dan sleutels af

Elk protocol heeft een manier nodig om de bedoelde server te herkennen, via een geconfigureerde publieke sleutel of een certificaatketen. Een gebruikerslogin komt bovenop die controle en vervangt hem niet. Een server die uw wachtwoord accepteert, heeft niets over zijn eigen identiteit bewezen. Daarom is een gedeeld geheim dat in een client wordt getypt geen vervanging voor het verifiëren van wie er antwoordde.

De uitwisseling leidt daarna verkeerssleutels af uit de eigen invoer van het protocol, en het loginwachtwoord is doorgaans niet de sleutel die op elk pakket wordt gestempeld. Langetermijn-identiteitsmateriaal en kortlevende sessiesleutels hebben verschillende looptijden en taken. Die scheiding is waar forward secrecy over gaat.

Houd verificatie ingeschakeld tijdens het oplossen van problemen, want een tunnel die verbindt nadat u een controle hebt uitgeschakeld, heeft niets anders bewezen dan dat de controle iets deed. Noteer wat u hebt gewijzigd en zet het terug voor de volgende test.

Drie protocollen, drie gesprekken

In een TLS-gebaseerde OpenVPN-implementatie onderhandelt het controlekanaal over beveiligingsparameters terwijl het datakanaal tunnelverkeer draagt, dus een datakanaaloptie en een certificaatprobleem leven op verschillende plaatsen. IKEv2 authenticeert beide deelnemers en stelt daarna IPsec-beveiligingsassociaties in met hun eigen looptijden. WireGuard leidt sleutels af via zijn op Noise gebaseerde uitwisseling en houdt de toestandsmachine bewust klein. Weten welke van de drie u draait, bepaalt welk logboek het lezen waard is.

Clients die er hetzelfde uitzien betekenen niet dat de berichten eronder uitwisselbaar zijn, en een configuratieveld dat in het ene product bestaat, heeft in het andere misschien geen tegenhanger. Een profiel ertussen kopiëren is een gok en geen migratie.

Wat de handshake niet doet

Routes, naamresolutie en bestemmingsbeleid blijven allemaal daarna bestaan. Een interne site kan onbereikbaar blijven omdat de route van het subnet ontbreekt, ook al is de peer correct geauthenticeerd en staat de tunnel. Dat als zwakke versleuteling behandelen stuurt u naar de verkeerde laag, en het eindigt meestal met een cipherwijziging die niets oplost.

Sleutelvernieuwing en opnieuw verbinden lijken in de meeste statusweergaven ook op elkaar, en geen van beide vertelt u of gewoon verkeer tijdens de onderbreking werd geblokkeerd. Alleen het foutbeleid van de client beantwoordt die vraag, dus lees het beleid en niet het pictogram.

Werk de fasen in de bovenstaande volgorde af en stop bij de eerste die een fout oplevert. Elke latere fase erft de toestand van de eerdere, dus een fout in de derde fase zegt niets over de vierde.

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