VPN-et flytte: kvifor OpenVPN-klienten din framleis ringjer den gamle IP-en

Leverandøren endra den offentlege adressa di, du oppdaterte den dynamiske DNS-posten, og klienten kan framleis ikkje kopla til. Utanfrå ser det ut som om posten ikkje har spreidd seg. Som oftast er posten i orden, og klienten ringjer adressa han løyste opp før flyttinga, fordi ein tunnel som køyrer og ein lagra profil kvar har si eiga oppfatning av kvar tenaren bur. Tre lag må vere samde, og dei vert oppdaterte etter ulike tidsplanar.

Sjå på kva profilen ringjer, ikkje kva DNS seier

Opne tilkoplinga du faktisk brukar, og les remote-linja. Ei numerisk adresse der følgjer aldri ei oppdatering av vertsnamnet, same kor rett posten vert.

Kontroller deretter om profilen du redigerte er den klienten lasta. Importerte profilar er vanlege: ein administrator kan ha teke ein kopi for månader sidan og halde sin eigen versjon, så fila i nedlastingsmappa og oppføringa i appen kan vere ulike. Samanlikn endepunktet i klienten sine eigne tilkoplingsdetaljar før du i det heile feilsøkjer DNS.

To filer, eitt endepunkt — det er det vanlege funnet her.

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

Les klienten sitt neste tilkoplingsforsøk

Start tilkoplinga på nytt med detaljert loggføring, og les linja der adressa han skal kontakte, er namngjeven. Den verdien er den viktige, ikkje den nettlesaren din løyste opp.

Ein resolvarbuffer kan framleis halde det førre svaret, og nokre nettverk held det lengre enn TTL-en til posten krev. Spør resolvaren klienten faktisk brukar, ikkje ein offentleg du testa frå ein annan stad.

Viss loggen viser den nye adressa og tilkoplinga framleis feilar, har problemet flytta seg: pakken går ein stad og ingen svarar. Det er eit spørsmål om ein lyttar, brannmur eller portvideresending, og det ligg på tenarsida snarare enn i oppløysingsvegen til klienten. Hald dei to feila frå kvarandre, fordi å handsame ein utilgjengeleg lyttar som eit DNS-problem sender deg gjennom same løkka to gonger.

Vit kva omstart du gjer

Ikkje alle omstartar bevarer same tilstand, og difor kan ei adresseendring oppføre seg ulikt avhengig av korleis prosessen vert resirkulert. Ein mjuk omstart utløyst av eit signal bevarer meir av konteksten frå førre økt, medan ein full stopp og start byrjar på nytt frå konfigurasjonen. Viss du testar om klienten løyser opp på nytt, vil du ha vegen som byrjar frå konfigurasjonen.

Innstillingar for varig tilstand har òg noko å seie, fordi dei er laga for å bevare det som vart autentisert, ikkje for å jage nye adresser.

Den reinaste testen er ein fersk start frå den tiltenkte profilen, følgd av eit blikk på logglinja som namngjev endepunktet. Alt du lærer av ei delvis bevart økt, er ei utsegn om den økta.

Dei fire alternativa og deira separate jobbar

remote med eit vertsnamn er innstillinga som gjer ny oppløysing mogleg i det heile; ei bokstavleg adresse på den linja utelukkar det. resolv-retry styrer kva som skjer når eit oppslag feilar, og 2.6 set ho allereie som standard til uendeleg. Å leggje ho til endrar difor ingenting, og ho planlegg aldri ein periodisk sjekk etter eit anna svar. Den som seier ho pollar nye adresser, har forveksla gjenoppretting med ferskheit.

persist-remote-ip handlar om kontinuitet snarare enn ferskheit: han brukar endepunktet som sist autentiserte på nytt, gjennom dei mjuke omstartane han støttar. Medan du testar ei flytting, er det det motsette av det du vil. Deaktiver han for testen viss bygget ditt aktiverer han, og gjenopprett han når det nye endepunktet er prova. Står han på, kan ei vellukka attilkopling ikkje fortelje deg noko om DNS.

float godtek ein autentisert peer der adressa endra seg midt i økta, og berre i oppsett som støttar det. Han oppdaterer ikkje DNS, og han vil ikkje følgje ei leverandørendring av seg sjølv. Handsame han som ein robustheitsfunksjon for peers som roamar, ikkje som ein mekanisme for dynamiske adresser for tenarar.

Stadfest det nye endepunktet før du klandrar klienten

Utanfor nettverket ditt, kontroller at den nye adressa har ein lyttar på den konfigurerte porten, og at videresendinga til leverandøren peikar på han. Ein korrekt A-post for ei maskin utan open port gjev nøyaktig det symptomet folk legg på hurtigbufferen.

Kopla deretter til på nytt og stadfest to ting: klienten autentiserte mot det forventa tenarsertifikatet, og økta når ressursen du hadde tenkt. Ei adresseendring senkjer ikkje identitetskrava, og ei tilkopling som lukkast til feil endepunkt er verre enn ei som feilar. OpenVPN 2.6-handboka listar alle fire alternativa med sitt eige omfang, og det er sjekklista som skal liggje ved profilen.

Hald ein veg utanom bandet inn til tenaren før du startar tunnelen som ber administrasjonstilgangen din, på nytt. Den eine førehandsregelen hindrar dei fleste hendingane dette scenarioet skaper.