Offentlig VPN-konfiguration holdt op med at virke? Læs fejlstadiet

Profilen virkede tirsdag, og fredag spinner klienten i tredive sekunder og giver op. Der er ikke ændret noget på din maskine. Det er netop pointen: en downloadet konfiguration beskriver én vært på ét tidspunkt, og operatøren i den anden ende har ingen pligt til at holde den beskrivelse sand. Fristelsen er at begynde at redigere sikkerhedsindstillinger, indtil tunnelen kommer op igen. Den tilbøjelighed er grunden til, at folk ender med at køre en profil med certifikatverifikation slået fra, hvilket er værre end slet ingen tunnel.

Filen beskriver et øjeblik, ikke en kontrakt

En konfigurationsfil er et sæt udsagn: dette værtsnavn lytter på denne port med denne protokol, fremviser et certifikat der matcher dette navn, og accepterer disse legitimationsoplysninger. Når blot ét af dem holder op med at være sandt, er filen forældet, og rettelsen hører til på operatørens side af grænsen, ikke i dine indstillinger.

Offentlige nodelister gør det tydeligt i kraft af deres natur. Noder drives af frivillige, de dukker op og forsvinder, adresser genbruges, og porte blokeres af det netværk, de ligger bag. Listen er et øjebliksbillede, der genereres igen, og kopien på din disk er et fotografi af et ældre øjebliksbillede.

Kommercielle tjenester ændrer sig langsommere, men ikke aldrig. Certifikatmyndigheder roterer, en lytter flytter fra en delt adresse til en dedikeret, en gammel protokol udfases, og en ny ciphersuite lander. Hver af dem er usynlig, indtil din klient forsøger at forbinde og får et andet svar, end filen forventer.

Læs fejlstadiet, før du rører ved en indstilling

Fejlmeddelelsen fortæller, hvilket udsagn der fejlede, og hvert udsagn har en helt forskellig udbedring. At redigere ciphers, når værtsnavnet ikke længere slår op, spilder en eftermiddag og lærer ingen noget.

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 linje adskiller en blokeret vej fra et brudt håndtryk, og den tredje viser udstederen og gyldighedsdatoerne for det certifikat, der faktisk fremvises. Hvis den udsteder ikke er den, profilen har pinnet, er certifikatet ændret, og ingen klientindstilling vil gøre den gamle pin korrekt igen.

Certifikat- og identitetsændringer er de stille

De fleste fejl annoncerer sig selv. Identitetsændringer gør ikke, fordi en klient, der pinner et certifikatnavn, afviser et fuldstændig gyldigt nyt certifikat med en meddelelse, som mange læser som en fejl i softwaren. Tunnelen er fin. Pinnen er forældet.

Se efter identitetsindstillingerne, før du konkluderer noget:

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 indlejret CA, og operatøren er skiftet til en ny myndighed, kan den gamle fil ikke validere den nye server. At erstatte CA-blokken med operatørens offentliggjorte er en legitim rettelse. At slette verifikationsdirektivet er ikke, og det er de samme tastetryk med et vidt forskelligt resultat.

En klientopgradering kan give samme symptom uden nogen ændring hos operatøren. Indstillinger, der stiltiende blev tolereret, afvises nu, eller en forældet protokol fjernes. Det er en kompatibilitetsgrænse i din software, og det er værd at prøve en anden profil med samme klient, før du bebrejder serveren.

Kun operatøren kan offentliggøre en gyldig erstatning

Når en node forsvinder, skal erstatningen komme fra samme kilde, som offentliggjorde originalen. En profil, der ankommer i en direkte besked, fordi den «bruger samme servernavn», er en uverificeret konfiguration fra en ukendt part, og import af den giver den part kontrol over din routing.

Kontrollen er billig. Hent den aktuelle fil fra det offentliggjorte sted, sammenlign endpoint og protokol med listen, og bekræft fingeraftrykket af CA-materialet i stedet for at 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 hashes kun adskiller sig i mellemrum, har du en formateringsændring. Hvis de adskiller sig i endpoints, har operatøren flyttet noget, og den offentliggjorte fil er autoriteten. Hvis den offentliggjorte fil er ældre end den, du har, kigger du sandsynligvis i en cache, og det forældede svar sender dig i den forkerte retning.

Tag den gamle post ud og skriv ned, hvad der skete

Når en fungerende erstatning er verificeret, skal du slette den gamle profil i stedet for at beholde den som fallback. En forældet post, der forbinder halvt, er en fælde: den vælges under et udfald, den fejler langsomt, og den person, der fejlretter, bruger de første ti minutter på den forkerte fil.

Hold en kort registrering uden for konfigurationen: datoen, det gamle endpoint, fejlstadiet og hvad der erstattede det. Offentlige noder skifter, og seks uger senere kommer det samme spørgsmål med en anden person på. Én linje i en notesfil besvarer det på sekunder.

Hvis fra ét netværk hver node fejler på samme måde og ingen fejler fra et andet, så hold op med at redigere profiler og se på den lokale vej. En captive portal, et filtreret portinterval eller en aflyttende proxy vil give identiske fejl hos urelaterede udbydere, og det mønster er det eneste signal om, at problemet aldrig var filen.