VPN'en flyttede: hvorfor din OpenVPN-klient stadig ringer til den gamle IP

Udbyderen ændrede din offentlige adresse, du har opdateret den dynamiske DNS-post, og klienten kan stadig ikke forbinde. Udefra ser det ud, som om posten ikke er slået igennem. Det meste af tiden er posten fin, og klienten ringer til den adresse, den opløste før flytningen, fordi en kørende tunnel og en gemt profil hver især har deres egen forestilling om, hvor serveren bor. Tre lag skal være enige, og de opdateres efter forskellige tidsplaner.

Se på, hvad profilen ringer til, ikke hvad DNS siger

Åbn den forbindelse, du faktisk bruger, og læs remote-linjen. En numerisk adresse der følger aldrig en opdatering af værtsnavnet, uanset hvor korrekt posten bliver.

Kontroller derefter, om den profil, du redigerede, er den, klienten har indlæst. Importerede profiler er almindelige: en administrator kan have taget en kopi for måneder siden og beholdt sin egen version, så filen i din downloadmappe og posten i appen kan være uenige. Sammenlign endepunktet i klientens egne forbindelsesoplysninger, før du overhovedet fejlfinder DNS.

To filer, ét endepunkt — det er det sædvanlige fund her.

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

Læs klientens næste forbindelsesforsøg

Genstart forbindelsen med udførlig logning, og læs den linje, hvor den angiver den adresse, den vil kontakte. Den værdi er den vigtige, ikke det, din browser opløste.

En resolvercache kan stadig holde det forrige svar, og nogle netværk holder det længere, end postens TTL kræver. Spørg den resolver, klienten faktisk bruger, i stedet for en offentlig, du testede fra et andet sted.

Hvis loggen viser den nye adresse, og forbindelsen stadig fejler, har problemet flyttet sig: pakken går et sted hen, og ingen svarer. Det er et spørgsmål om en lytter, en firewall eller portvideresendelse, og det ligger på serversiden snarere end i klientens opløsningsvej. Hold de to fejl adskilt, fordi behandling af en utilgængelig lytter som et DNS-problem sender dig gennem den samme løkke to gange.

Ved, hvilken genstart du laver

Ikke alle genstarter bevarer samme tilstand, og derfor kan en adresseændring opføre sig forskelligt alt efter, hvordan processen genbruges. En blød genstart udløst af et signal bevarer mere af den forrige sessions kontekst, mens et fuldt stop og start begynder forfra fra konfigurationen. Hvis du tester, om klienten opløser igen, vil du have den vej, der starter fra konfigurationen.

Indstillinger for vedholdenhed betyder også noget, fordi de er beregnet til at bevare det, der blev godkendt, snarere end at jagte nye adresser.

Den reneste test er en frisk start fra den tilsigtede profil efterfulgt af et kig på loglinjen, der angiver endepunktet. Alt, hvad du lærer af en delvist bevaret session, er en udtalelse om den session.

De fire muligheder og deres adskilte opgaver

remote med et værtsnavn er den indstilling, der overhovedet gør ny opløsning mulig; en bogstavelig adresse på den linje udelukker det. resolv-retry styrer, hvad der sker, når et opslag fejler, og 2.6 sætter den allerede som standard til uendelig. At tilføje den ændrer derfor intet, og den planlægger aldrig et periodisk tjek efter et andet svar. Enhver, der siger, at den afstemmer nye adresser, har forvekslet genopretning med friskhed.

persist-remote-ip handler om kontinuitet snarere end friskhed: den genbruger det endepunkt, der sidst godkendte, på tværs af de bløde genstarter, den understøtter. Mens du tester en flytning, er det det modsatte af, hvad du vil. Deaktiver den til testen, hvis dit build aktiverer den, og gendan den, når det nye endepunkt er bevist. Efterladt aktiveret kan en vellykket genopkobling ikke fortælle dig noget om DNS.

float accepterer en godkendt peer, hvis adresse ændrede sig midt i sessionen, og kun i opsætninger, der understøtter det. Den opdaterer ikke DNS og vil ikke selv følge en udbyderændring. Behandl den som en robusthedsfunktion til peers, der roamer, ikke som en mekanisme til dynamiske adresser til servere.

Bekræft det nye endepunkt, før du bebrejder klienten

Uden for dit netværk skal du kontrollere, at den nye adresse har en lytter på den konfigurerede port, og at udbyderens videresendelse peger på den. En korrekt A-post for en maskine uden åben port giver præcis det symptom, folk tilskriver caching.

Genopret derefter forbindelsen, og bekræft to ting: klienten godkendte mod det forventede servercertifikat, og sessionen når den ressource, du havde til hensigt. En adresseændring sænker ikke identitetskravene, og en forbindelse, der lykkes til det forkerte endepunkt, er værre end en, der fejler. OpenVPN 2.6-manualen lister alle fire muligheder med deres eget omfang, og det er tjeklisten, der skal ligge ved profilen.

Hold en vej uden om båndet ind til serveren, før du genstarter den tunnel, der bærer din administrative adgang. Den ene forholdsregel forhindrer de fleste af de hændelser, dette scenarie frembringer.