VPN se je preselil: zakaj vaš odjemalec OpenVPN še vedno kliče stari IP

Ponudnik je spremenil vaš javni naslov, posodobili ste dinamični zapis DNS, odjemalec pa se še vedno ne more povezati. Od zunaj je videti, kot da se zapis ni razširil. Najpogosteje je zapis v redu in odjemalec kliče naslov, ki ga je razrešil pred selitvijo, ker imata delujoč tunel in shranjen profil vsak svojo predstavo o tem, kje živi strežnik. Tri plasti se morajo ujemati in posodabljajo se po različnih urnikih.

Poglejte, kaj kliče profil, ne kaj pravi DNS

Odprite povezavo, ki jo dejansko uporabljate, in preberite vrstico remote. Številčni naslov tam nikoli ne sledi posodobitvi imena gostitelja, ne glede na to, kako pravilen postane zapis.

Nato preverite, ali je profil, ki ste ga uredili, tisti, ki ga je naložil odjemalec. Uvoženi profili so pogosti: skrbnik je morda pred meseci vzel kopijo in obdržal svojo različico, zato se datoteka v vaši mapi za prenose in vnos v aplikaciji lahko razlikujeta. Primerjajte končno točko v odjemalčevih lastnih podrobnostih povezave, preden sploh začnete odpravljati napake v DNS.

Dve datoteki, ena končna točka — to je tukaj običajna ugotovitev.

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

Preberite naslednji poskus povezave odjemalca

Ponovno zaženite povezavo s podrobnim beleženjem in preberite vrstico, kjer je naveden naslov, s katerim bo komuniciral. Ta vrednost šteje, ne tista, ki jo je razrešil vaš brskalnik.

Predpomnilnik razreševalnika lahko še vedno hrani prejšnji odgovor, neka omrežja pa ga hranijo dlje, kot zahteva TTL zapisa. Vprašajte razreševalnik, ki ga odjemalec dejansko uporablja, ne javnega, ki ste ga preizkusili od drugod.

Če dnevnik pokaže novi naslov in povezava še vedno ne uspe, se je težava premaknila: paket gre nekam in nihče ne odgovarja. To je vprašanje poslušalca, požarnega zidu ali posredovanja vrat in je na strani strežnika, ne na poti razreševanja odjemalca. Ti dve napaki imejte ločeni, ker obravnavanje nedosegljivega poslušalca kot težave DNS vas dvakrat popelje skozi isto zanko.

Vedite, kateri ponovni zagon izvajate

Vsi ponovni zagoni ne ohranijo istega stanja, zato se lahko sprememba naslova obnaša drugače glede na to, kako se postopek reciklira. Mehki ponovni zagon, ki ga sproži signal, ohrani več konteksta prejšnje seje, medtem ko se popolna zaustavitev in zagon znova začneta od konfiguracije. Če preizkušate, ali odjemalec znova razreši, želite pot, ki se začne pri konfiguraciji.

Tudi nastavitve obstojnosti štejejo, saj so namenjene ohranjanju tega, kar je bilo overjeno, ne pa lovljenju novih naslovov.

Najčistejši preizkus je svež zagon iz predvidenega profila, ki mu sledi pogled na vrstico dnevnika, ki navaja končno točko. Vse, kar se naučite iz delno ohranjene seje, je trditev o tej seji.

Štiri možnosti in njihove ločene naloge

remote z imenom gostitelja je nastavitev, ki ponovno razreševanje sploh omogoča; dobesedni naslov v tej vrstici to izključi. resolv-retry nadzoruje, kaj se zgodi, ko iskanje ne uspe, in 2.6 ga že privzeto nastavi na neskončno. Njegovo dodajanje torej ne spremeni ničesar in nikoli ne načrtuje občasnega preverjanja drugega odgovora. Kdor pravi, da anketira nove naslove, je zamenjal obnovitev s svežino.

persist-remote-ip je o neprekinjenosti, ne o svežini: znova uporabi končno točko, ki se je nazadnje overila, skozi mehke ponovne zagone, ki jih podpira. Medtem ko preizkušate selitev, je to nasprotje tega, kar želite. Onemogočite ga za preizkus, če ga vaša gradnja omogoča, in ga obnovite, ko je nova končna točka dokazana. Če ostane vklopljen, vam uspešna ponovna povezava morda ne pove ničesar o DNS.

float sprejme overjenega partnerja, katerega naslov se je spremenil sredi seje, in le v postavitvah, ki to podpirajo. Ne osveži DNS in sam ne bo sledil spremembi ponudnika. Obravnavajte ga kot funkcijo odpornosti za partnerje, ki se gibljejo, ne kot mehanizem dinamičnih naslovov za strežnike.

Potrdite novo končno točko, preden obtožite odjemalca

Od zunaj svojega omrežja preverite, ali ima novi naslov poslušalca na nastavljenih vratih in ali posredovanje ponudnika kaže nanj. Pravilen zapis A za stroj brez odprtih vrat ustvari natanko tisti simptom, ki ga ljudje pripisujejo predpomnilniku.

Nato se znova povežite in preverite dve stvari: odjemalec se je overil proti pričakovanemu strežniškemu potrdilu in seja doseže vir, ki ste ga nameravali. Sprememba naslova ne zniža zahtev glede identitete in povezava, ki uspe do napačne končne točke, je slabša od tiste, ki ne uspe. Priročnik OpenVPN 2.6 navaja vse štiri možnosti z njihovim lastnim obsegom in to je kontrolni seznam, ki ga je treba imeti ob profilu.

Preden znova zaženete tunel, ki nosi vaš skrbniški dostop, si zagotovite pot do strežnika zunaj pasu. Ta en sam ukrep prepreči večino incidentov, ki jih povzroči ta scenarij.