Offentleg VPN-konfigurasjon slutta å verke? Les feilsteget

Profilen verka tysdag, og fredag spinner klienten i tretti sekund og gir opp. Ingenting på maskinen din har endra seg. Det er nettopp poenget: ein nedlasta konfigurasjon skildrar éin vert i eitt augneblink, og operatøren i den andre enden har inga plikt til å halde den skildringa sann. Freistinga er å byrje å endre tryggingsinnstillingar til tunnelen kjem opp att. Nettopp den impulsen er grunnen til at folk endar med å køyre ein profil med sertifikatverifisering slått av, som er verre enn å ikkje ha nokon tunnel i det heile.

Fila skildrar eit augneblink, ikkje ein kontrakt

Ei konfigurasjonsfil er eit sett påstandar: dette vertsnamnet lyttar på denne porten med denne protokollen, legg fram eit sertifikat som passar til dette namnet, og godtek desse påloggingsdetaljane. Når éin av dei sluttar å vere sann, er fila utdatert, og rettinga høyrer heime på operatøren si side av grensa, ikkje i innstillingane dine.

Offentlege nodelister gjer dette tydeleg av si eiga natur. Nodane vert drivne av frivillige, dei dukkar opp og forsvinn, adresser vert resirkulerte, og portar vert blokkerte av nettverket dei ligg bak. Lista er eit augneblinksbilete som vert generert på nytt, og kopien på disken din er eit fotografi av eit eldre augneblinksbilete.

Kommersielle tenester endrar seg langsomare, men ikkje aldri. Sertifikatstyresmakter roterer, ein lyttar flyttar frå ei delt adresse til ei dedikert, ein gamal protokoll vert avvikla, og ei ny chifferliste landar. Kvar av dei er usynleg til klienten din prøver å kople til og får eit anna svar enn fila ventar.

Les feilsteget før du rører ei innstilling

Feilmeldinga seier kva påstand som braut saman, og kvar påstand har ei heilt anna retting. Å endre chiffrar når vertsnamnet ikkje lenger slår opp, kostar ein ettermiddag og lærer ingen noko.

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 linja skil ein blokkert veg frå eit øydelagt handtrykk, og den tredje viser utgivaren og gyldigheitsdatoane til sertifikatet som faktisk vert lagt fram. Viss den utgivaren ikkje er den profilen pinna, har sertifikatet endra seg, og inga klientinnstilling vil gjere den gamle pinnen riktig att.

Sertifikat- og identitetsendringar er dei stille

Dei fleste feil kunngjer seg sjølve. Identitetsendringar gjer det ikkje, fordi ein klient som pinnar eit sertifikatnamn vil avvise eit heilt fint nytt sertifikat med ei melding mange les som ein programvarefeil. Tunnelen er i orden. Pinnen er utdatert.

Sjå etter identitetsinnstillingane før du konkluderer noko:

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

Viss profilen ber ein innebygd CA og operatøren har gått over til ei ny styresmakt, kan den gamle fila ikkje validere den nye tenaren. Å bytte ut CA-blokka med den operatøren har publisert er ei legitim retting. Å slette verifiseringsdirektivet er det ikkje, og det er dei same tastetrykka med eit heilt anna utfall.

Ein klientoppgradering kan gje same symptomet utan noka endring hos operatøren. Innstillingar som vart stille tolererte, vert no avviste, eller ein utdatert protokoll vert fjerna. Det er ei kompatibilitetsgrense i programvara di, og det er verdt å prøve ein annan profil med same klient før du klandrar tenaren.

Berre operatøren kan publisere ei gyldig erstatning

Når ein node forsvinn, må erstatninga kome frå same kjelde som publiserte originalen. Ein profil som kjem i ei direktemelding fordi han «brukar same tenarnamn», er ein uverifisert konfigurasjon frå ein ukjend part, og import av han gjev den parten kontroll over rutinga di.

Kontrollen er billeg. Hent den gjeldande fila frå den publiserte staden, samanlikn endepunktet og protokollen med lista, og stadfest fingeravtrykket til CA-materialet i staden for å stole på filnamnet:

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

Viss dei to hasha berre skil seg i mellomrom, har du ei formateringsendring. Viss dei skil seg i endepunkt, har operatøren flytta noko, og den publiserte fila er autoriteten. Viss den publiserte fila er eldre enn den du har, ser du truleg i ein cache, og det utdaterte svaret sender deg i feil retning.

Ta den gamle oppføringa ut og skriv ned kva som skjedde

Når ei fungerande erstatning er stadfesta, slett den gamle profilen i staden for å halde han som reserve. Ei utdatert oppføring som koplar halvvegs til, er ei felle: ho vil verte vald under ei forstyrring, ho vil feile langsamt, og den som feilsøkjer vil bruke dei første ti minutta på feil fil.

Hald ei kort oversikt utanfor konfigurasjonen: datoen, det gamle endepunktet, feilsteget og kva som erstatta det. Offentlege nodar skiftar, og seks veker seinare kjem det same spørsmålet med ein annan person. Éi linje i ei notatfil svarar på det på sekund.

Viss frå eitt nettverk kvar node feilar på same måte og frå eit anna ingen, slutt å endre profilar og sjå på den lokale vegen. Ein captive portal, eit filtrert portområde eller ein avlyttande proxy vil gje identiske feil hos urelaterte leverandørar, og det mønsteret er det einaste signalet på at problemet aldri var fila.