Offentlig VPN-konfigurasjon sluttet å virke? Les feilsteget

Profilen virket tirsdag, og fredag spinner klienten i tretti sekunder og gir opp. Ingenting på maskinen din har endret seg. Det er nettopp poenget: en nedlastet konfigurasjon beskriver én vert i ett øyeblikk, og operatøren i den andre enden har ingen plikt til å holde den beskrivelsen sann. Fristelsen er å begynne å redigere sikkerhetsinnstillinger til tunnelen kommer opp igjen. Nettopp den impulsen er grunnen til at folk ender med å kjøre en profil med sertifikatverifisering slått av, som er verre enn å ikke ha noen tunnel i det hele tatt.

Filen beskriver et øyeblikk, ikke en kontrakt

En konfigurasjonsfil er et sett påstander: dette vertsnavnet lytter på denne porten med denne protokollen, presenterer et sertifikat som passer til dette navnet, og godtar disse påloggingsdetaljene. Når én av dem slutter å være sann, er filen utdatert, og rettelsen hører hjemme på operatørens side av grensen, ikke i innstillingene dine.

Offentlige nodelister gjør dette tydelig av sin natur. Nodene drives av frivillige, de dukker opp og forsvinner, adresser resirkuleres, og porter blokkeres av nettverket de ligger bak. Listen er et øyeblikksbilde som genereres på nytt, og kopien på disken din er et fotografi av et eldre øyeblikksbilde.

Kommersielle tjenester endrer seg langsommere, men ikke aldri. Sertifikatmyndigheter roterer, en lytter flytter fra en delt adresse til en dedikert, en gammel protokoll avvikles, og en ny chifferliste lander. Hver av dem er usynlig til klienten din prøver å koble til og får et annet svar enn filen forventer.

Les feilsteget før du rører en innstilling

Feilmeldingen sier hvilken påstand som brast, og hver påstand har en helt annen rettelse. Å redigere chiffere når vertsnavnet ikke lenger slår opp, koster en ettermiddag og lærer ingen noe.

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

Den midterste linjen skiller en blokkert vei fra et ødelagt håndtrykk, og den tredje viser utstederen og gyldighetsdatoene til sertifikatet som faktisk presenteres. Hvis den utstederen ikke er den profilen pinnet, har sertifikatet endret seg, og ingen klientinnstilling vil gjøre den gamle pinnen riktig igjen.

Sertifikat- og identitetsendringer er de stille

De fleste feil kunngjør seg selv. Identitetsendringer gjør ikke, fordi en klient som pinner et sertifikatnavn vil avvise et helt fint nytt sertifikat med en melding mange leser som en programvarefeil. Tunnelen er i orden. Pinnen er utdatert.

Se etter identitetsinnstillingene før du konkluderer noe:

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

Hvis profilen bærer en innebygd CA og operatøren har gått over til en ny myndighet, kan den gamle filen ikke validere den nye serveren. Å erstatte CA-blokken med den operatøren har publisert er en legitim rettelse. Å slette verifiseringsdirektivet er det ikke, og det er de samme tastetrykkene med et helt annet utfall.

En klientoppgradering kan gi samme symptom uten noen endring hos operatøren. Innstillinger som ble stiltiende tolerert, avvises nå, eller en utdatert protokoll fjernes. Det er en kompatibilitetsgrense i programvaren din, og det er verdt å prøve en annen profil med samme klient før du klandrer serveren.

Bare operatøren kan publisere en gyldig erstatning

Når en node forsvinner, må erstatningen komme fra samme kilde som publiserte originalen. En profil som kommer i en direktemelding fordi den «bruker samme servernavn», er en uverifisert konfigurasjon fra en ukjent part, og import av den gir den parten kontroll over rutingen din.

Kontrollen er billig. Hent den gjeldende filen fra det publiserte stedet, sammenlign endepunktet og protokollen med listen, og bekreft fingeravtrykket til CA-materialet i stedet for å stole på filnavnet:

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

Hvis de to hashene bare skiller seg i mellomrom, har du en formateringsendring. Hvis de skiller seg i endepunkter, har operatøren flyttet noe, og den publiserte filen er autoriteten. Hvis den publiserte filen er eldre enn den du har, ser du sannsynligvis i en cache, og det utdaterte svaret sender deg i feil retning.

Ta den gamle oppføringen ut og skriv ned hva som skjedde

Når en fungerende erstatning er verifisert, slett den gamle profilen i stedet for å beholde den som reserve. En utdatert oppføring som halvveis kobler til, er en felle: den vil bli valgt under en forstyrrelse, den vil feile langsomt, og den som feilsøker vil bruke de første ti minuttene på feil fil.

Hold en kort oversikt utenfor konfigurasjonen: datoen, det gamle endepunktet, feilsteget og hva som erstattet det. Offentlige noder skifter, og seks uker senere kommer det samme spørsmålet med en annen person. Én linje i en notatfil svarer på det på sekunder.

Hvis fra ett nettverk hver node feiler på samme måte og fra et annet ingen, slutt å redigere profiler og se på den lokale veien. En captive portal, et filtrert portområde eller en avlyttende proxy vil gi identiske feil hos urelaterte leverandører, og det mønsteret er det eneste signalet på at problemet aldri var filen.