VPN-et flyttet: hvorfor OpenVPN-klienten din fortsatt ringer den gamle IP-en

Leverandøren endret den offentlige adressen din, du oppdaterte den dynamiske DNS-posten, og klienten kan fortsatt ikke koble til. Utenfra ser det ut som om posten ikke har spredt seg. Som oftest er posten i orden, og klienten ringer adressen den løste opp før flyttingen, fordi en kjørende tunnel og en lagret profil hver har sin egen oppfatning av hvor serveren bor. Tre lag må være enige, og de oppdateres etter ulike tidsplaner.

Se på hva profilen ringer, ikke hva DNS sier

Åpne tilkoblingen du faktisk bruker, og les remote-linjen. En numerisk adresse der følger aldri en oppdatering av vertsnavnet, uansett hvor riktig posten blir.

Kontroller deretter om profilen du redigerte er den klienten lastet. Importerte profiler er vanlige: en administrator kan ha tatt en kopi for måneder siden og beholdt sin egen versjon, så filen i nedlastingsmappen og oppføringen i appen kan være ulike. Sammenlign endepunktet i klientens egne tilkoblingsopplysninger før du i det hele tatt feilsøker DNS.

To filer, ett endepunkt — det er det vanlige funnet her.

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

Les klientens neste tilkoblingsforsøk

Start tilkoblingen på nytt med detaljert logging, og les linjen der adressen den skal kontakte, navngis. Den verdien er den viktige, ikke den nettleseren din løste opp.

En resolverbuffer kan fortsatt holde det forrige svaret, og noen nettverk holder det lenger enn postens TTL krever. Spør resolveren klienten faktisk bruker, ikke en offentlig du testet fra et annet sted.

Hvis loggen viser den nye adressen og tilkoblingen fortsatt feiler, har problemet flyttet seg: pakken går et sted og ingen svarer. Det er et spørsmål om en lytter, brannmur eller portvideresending, og det ligger på serversiden snarere enn i klientens oppløsningsvei. Hold de to feilene fra hverandre, fordi å behandle en utilgjengelig lytter som et DNS-problem sender deg gjennom samme løkke to ganger.

Vit hvilken omstart du gjør

Ikke alle omstarter bevarer samme tilstand, og derfor kan en adresseendring oppføre seg ulikt avhengig av hvordan prosessen resirkuleres. En myk omstart utløst av et signal bevarer mer av forrige økts kontekst, mens en full stopp og start begynner på nytt fra konfigurasjonen. Hvis du tester om klienten løser opp på nytt, vil du ha veien som starter fra konfigurasjonen.

Innstillinger for vedvarende tilstand betyr også noe, fordi de er laget for å bevare det som ble autentisert, ikke for å jage nye adresser.

Den reneste testen er en fersk start fra den tiltenkte profilen, fulgt av et blikk på logglinjen som navngir endepunktet. Alt du lærer av en delvis bevart økt, er en uttalelse om den økten.

De fire alternativene og deres separate jobber

remote med et vertsnavn er innstillingen som gjør ny oppløsning mulig i det hele tatt; en bokstavelig adresse på den linjen utelukker det. resolv-retry styrer hva som skjer når et oppslag feiler, og 2.6 setter den allerede som standard til uendelig. Å legge den til endrer derfor ingenting, og den planlegger aldri en periodisk sjekk etter et annet svar. Den som sier den poller nye adresser, har forvekslet gjenoppretting med friskhet.

persist-remote-ip handler om kontinuitet snarere enn friskhet: den gjenbruker endepunktet som sist autentiserte, gjennom de myke omstartene den støtter. Mens du tester en flytting, er det det motsatte av det du vil. Deaktiver den for testen hvis bygget ditt aktiverer den, og gjenopprett den når det nye endepunktet er bevist. Står den på, kan en vellykket gjenoppkobling ikke fortelle deg noe om DNS.

float godtar en autentisert peer hvis adresse endret seg midt i økten, og bare i oppsett som støtter det. Den oppdaterer ikke DNS, og den vil ikke følge en leverandørendring av seg selv. Behandle den som en robusthetsfunksjon for peers som roamer, ikke som en mekanisme for dynamiske adresser for servere.

Bekreft det nye endepunktet før du klandrer klienten

Utenfor nettverket ditt, kontroller at den nye adressen har en lytter på den konfigurerte porten, og at leverandørens videresending peker på den. En korrekt A-post for en maskin uten åpen port gir nøyaktig det symptomet folk tilskriver hurtigbuffer.

Koble deretter til på nytt og bekreft to ting: klienten autentiserte mot det forventede servercertifikatet, og økten når ressursen du hadde tenkt. En adresseendring senker ikke identitetskravene, og en tilkobling som lykkes til feil endepunkt er verre enn en som feiler. OpenVPN 2.6-håndboken lister alle fire alternativene med sitt eget omfang, og det er sjekklisten som skal ligge ved profilen.

Hold en vei utenom båndet inn til serveren før du starter tunnelen som bærer administrasjonstilgangen din på nytt. Det ene forholdsregelen hindrer de fleste hendelsene dette scenariet skaper.