Offentlig VPN-konfiguration slutade fungera? Läs felsteget

Profilen fungerade i tisdags, och på fredagen snurrar klienten i trettio sekunder och ger upp. Ingenting på din maskin har ändrats. Det är precis poängen: en nedladdad konfiguration beskriver en värd i ett ögonblick, och operatören i andra änden har ingen skyldighet att hålla den beskrivningen sann. Frestelsen är att börja redigera säkerhetsinställningar tills tunneln kommer upp igen. Just den impulsen är anledningen till att folk till slut kör en profil med certifikatverifiering avstängd, vilket är värre än att inte ha någon tunnel alls.

Filen beskriver ett ögonblick, inte ett avtal

En konfigurationsfil är en uppsättning påståenden: det här värdnamnet lyssnar på den här porten med det här protokollet, presenterar ett certifikat som matchar namnet och accepterar de här inloggningsuppgifterna. När något av dem slutar vara sant är filen inaktuell och rättelsen hör hemma på operatörens sida av gränsen, inte i dina inställningar.

Offentliga nodlistor gör detta tydligt av sin natur. Noderna drivs av volontärer, de dyker upp och försvinner, adresser återanvänds och portar blockeras av nätverket de ligger bakom. Listan är en ögonblicksbild som genereras om, och kopian på din disk är ett fotografi av en äldre ögonblicksbild.

Kommersiella tjänster förändras långsammare, men inte aldrig. Certifikatmyndigheter roterar, en lyssnare flyttar från en delad adress till en dedikerad, ett gammalt protokoll avvecklas och en ny chifferlista landar. Var och en av dem är osynlig tills din klient försöker ansluta och får ett annat svar än filen förväntar sig.

Läs felsteget innan du rör en inställning

Felmeddelandet säger vilket påstående som brast, och varje påstående har en helt annan rättelse. Att redigera chiffror när värdnamnet inte längre slår upp kostar en eftermiddag och lär ingen något.

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 mellersta raden skiljer en blockerad väg från ett trasigt handskakning, och den tredje visar utfärdaren och giltighetsdatumen för det certifikat som faktiskt presenteras. Om den utfärdaren inte är den profilen pinnat, har certifikatet ändrats, och ingen klientinställning gör den gamla pinnen korrekt igen.

Certifikat- och identitetsändringar är de tysta

De flesta fel tillkännager sig själva. Identitetsändringar gör det inte, eftersom en klient som pinnar ett certifikatnamn kommer att avvisa ett helt bra nytt certifikat med ett meddelande som många läser som en bugg. Tunneln är okej. Pinnen är inaktuell.

Leta efter identitetsinställningarna innan du drar någon slutsats:

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

Om profilen bär en inbäddad CA och operatören har gått över till en ny myndighet kan den gamla filen inte validera den nya servern. Att ersätta CA-blocket med det operatören publicerat är en legitim rättelse. Att radera verifieringsdirektivet är det inte, och det är samma tangenttryckningar med ett helt annat utfall.

En klientuppgradering kan ge samma symptom utan någon ändring hos operatören. Inställningar som tidigare tyst tolererades avvisas nu, eller så tas ett föråldrat protokoll bort. Det är en kompatibilitetsgräns i din programvara, och det är värt att prova en andra profil med samma klient innan du skyller på servern.

Bara operatören kan publicera en giltig ersättning

När en nod försvinner måste ersättningen komma från samma källa som publicerade originalet. En profil som kommer i ett direktmeddelande för att den ”använder samma servernamn” är en overifierad konfiguration från en okänd part, och att importera den ger den parten kontroll över din routing.

Kontrollen är billig. Hämta den aktuella filen från den publicerade platsen, jämför slutpunkten och protokollet med listan och bekräfta fingeravtrycket för CA-materialet i stället för att lita på filnamnet:

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

Om de två hasharna bara skiljer sig i blanksteg har du en formateringsändring. Om de skiljer sig i slutpunkter har operatören flyttat något och den publicerade filen är auktoriteten. Om den publicerade filen är äldre än den du har tittar du förmodligen i en cache, och det inaktuella svaret skickar dig i fel riktning.

Ta bort den gamla posten och skriv ner vad som hände

När en fungerande ersättning är verifierad, radera den gamla profilen i stället för att behålla den som reserv. En inaktuell post som halvt ansluter är en fälla: den väljs under ett avbrott, den misslyckas långsamt, och den som felsöker tillbringar de första tio minuterna med fel fil.

Håll en kort anteckning utanför konfigurationen: datumet, den gamla slutpunkten, felsteget och vad som ersatte den. Offentliga noder skiftar, och sex veckor senare kommer samma fråga med en annan person. En rad i en anteckningsfil besvarar den på sekunder.

Om från ett nätverk varje nod misslyckas på samma sätt och från ett annat ingen, sluta redigera profiler och titta på den lokala vägen. En captive portal, ett filtrerat portintervall eller en avlyssnande proxy ger identiska fel hos orelaterade leverantörer, och det mönstret är den enda signalen om att problemet aldrig var filen.