Openbare VPN-configuratie werkt niet meer? Lees de faalfase

Het profiel werkte dinsdag, en vrijdag draait de client dertig seconden en geeft het op. Op je machine is niets veranderd. Dat is precies het punt: een gedownloade configuratie beschrijft één host op één moment, en de operator aan de andere kant heeft geen verplichting om die beschrijving waar te houden. De verleiding is om beveiligingsinstellingen te gaan aanpassen tot de tunnel weer omhoog komt. Juist die neiging zorgt ervoor dat mensen uiteindelijk een profiel draaien met certificaatverificatie uitgeschakeld, wat erger is dan helemaal geen tunnel hebben.

Het bestand beschrijft een moment, geen contract

Een configuratiebestand is een reeks aannames: deze hostnaam luistert op deze poort met dit protocol, presenteert een certificaat dat bij deze naam past, en accepteert deze inloggegevens. Zodra een daarvan niet meer waar is, is het bestand verouderd en hoort de reparatie aan de operatorkant van de grens, niet in jouw instellingen.

Openbare nodelijsten maken dat van nature duidelijk. Nodes worden door vrijwilligers beheerd, ze verschijnen en verdwijnen, adressen worden hergebruikt en poorten worden geblokkeerd door het netwerk waar ze achter zitten. De lijst is een momentopname die opnieuw wordt gegenereerd, en de kopie op je schijf is een foto van een oudere momentopname.

Commerciële diensten veranderen langzamer, maar niet nooit. Certificaatautoriteiten roteren, een listener verhuist van een gedeeld adres naar een eigen adres, een oud protocol wordt uitgefaseerd en een nieuwe cijferlijst arriveert. Elk daarvan is onzichtbaar tot je client probeert te verbinden en een ander antwoord krijgt dan het bestand verwacht.

Lees de faalfase voordat je een instelling aanraakt

De foutmelding zegt welke aanname is gebroken, en elke aanname heeft een heel andere reparatie. Cijfers aanpassen terwijl de hostnaam niet meer resolvet, kost een middag en leert niemand iets.

dig +short vpn.example.net
curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect}\n' --max-time 8 https://vpn.example.net:443/
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

De middelste regel scheidt een geblokkeerde route van een kapotte handshake, en de derde toont de uitgever en geldigheidsdatums van het certificaat dat daadwerkelijk wordt gepresenteerd. Als die uitgever niet degene is die het profiel heeft vastgezet, is het certificaat veranderd, en geen enkele optie aan de clientkant maakt de oude pin weer correct.

Certificaat- en identiteitswijzigingen zijn de stille

De meeste storingen kondigen zichzelf aan. Identiteitswijzigingen niet, omdat een client die een certificaatnaam vastzet een volkomen goed nieuw certificaat weigert met een melding die veel mensen als een bug lezen. De tunnel is in orde. De pin is verouderd.

Zoek de identiteitsopties voordat je iets concludeert:

grep -nE '^(remote|proto|auth|verify-x509-name|tls-crypt|key-direction|ca) ' profile.ovpn
openssl x509 -in profile-ca.crt -noout -subject -dates

Als het profiel een ingebedde CA bevat en de operator is overgestapt op een nieuwe autoriteit, kan het oude bestand de nieuwe server niet valideren. Het CA-blok vervangen door dat van de operator is een legitieme reparatie. De verificatierichtlijn verwijderen is dat niet, en het zijn dezelfde toetsaanslagen met een heel andere uitkomst.

Een client-upgrade kan hetzelfde symptoom geven zonder enige wijziging bij de operator. Opties die stilzwijgend werden getolereerd, worden nu geweigerd, of een verouderd protocol wordt verwijderd. Dat is een compatibiliteitsgrens in je software, en het loont om een tweede profiel met dezelfde client te proberen voordat je de server de schuld geeft.

Alleen de operator kan een geldige vervanging publiceren

Wanneer een node verdwijnt, moet de vervanging van dezelfde bron komen die het origineel heeft gepubliceerd. Een profiel dat in een direct bericht arriveert omdat het «dezelfde servernaam gebruikt», is een niet-geverifieerde configuratie van een onbekende partij, en het importeren geeft die partij controle over je routing.

De controle is goedkoop. Haal het huidige bestand van de gepubliceerde locatie, vergelijk het eindpunt en het protocol met de lijst, en bevestig de vingerafdruk van het CA-materiaal in plaats van de bestandsnaam te vertrouwen:

curl -sS -o current.ovpn https://example.org/nodes/current.ovpn
sha256sum current.ovpn profile.ovpn
grep -nE '^(remote|proto) ' current.ovpn

Als de twee hashes alleen in witruimte verschillen, heb je een opmaakwijziging. Als ze verschillen in eindpunten, heeft de operator iets verplaatst en is het gepubliceerde bestand de autoriteit. Als het gepubliceerde bestand ouder is dan dat van jou, kijk je waarschijnlijk naar een cache, en het verouderde antwoord stuurt je de verkeerde kant op.

Haal de oude vermelding weg en leg vast wat er is gebeurd

Zodra een werkende vervanging is geverifieerd, verwijder je het oude profiel in plaats van het als reserve te houden. Een verouderde vermelding die half verbindt is een valkuil: hij wordt gekozen tijdens een storing, hij faalt langzaam, en degene die debugt, besteedt de eerste tien minuten aan het verkeerde bestand.

Houd een korte registratie buiten de configuratie: de datum, het oude eindpunt, de faalfase en wat het heeft vervangen. Openbare nodes wisselen, en zes weken later komt dezelfde vraag met een ander persoon erbij. Eén regel in een notitiebestand beantwoordt die in seconden.

Als vanaf één netwerk elke node op dezelfde manier faalt en vanaf een ander geen enkele, stop dan met het bewerken van profielen en kijk naar het lokale pad. Een captive portal, een gefilterd poortbereik of een onderscheppende proxy zal identieke fouten geven bij niet-verwante providers, en dat patroon is het enige signaal dat het probleem nooit het bestand was.