VPN persikėlė: kodėl jūsų OpenVPN klientas vis dar skambina senuoju IP

Tiekėjas pakeitė jūsų viešąjį adresą, jūs atnaujinote dinaminį DNS įrašą, o klientas vis dar negali prisijungti. Iš išorės atrodo, kad įrašas neišplito. Dažniausiai įrašas tvarkingas, o klientas skambina adresu, kurį išsprendė prieš perkėlimą, nes veikiantis tunelis ir išsaugotas profilis kiekvienas turi savo nuomonę apie tai, kur gyvena serveris. Trys sluoksniai turi sutarti, ir jie atnaujinami pagal skirtingus grafikus.

Žiūrėkite, kuo skambina profilis, o ne ką sako DNS

Atidarykite ryšį, kurį iš tikrųjų naudojate, ir perskaitykite remote eilutę. Skaitmeninis adresas ten niekada neseka hosname atnaujinimo, kad ir koks teisingas taptų įrašas.

Tada patikrinkite, ar jūsų redaguotas profilis yra tas, kurį įkėlė klientas. Importuoti profiliai įprasti: administratorius prieš mėnesius galėjo pasidaryti kopiją ir pasilikti savo versiją, todėl failas jūsų atsisiuntimų aplanke ir įrašas programoje gali skirtis. Palyginkite galinį tašką paties kliento ryšio duomenyse, prieš pradėdami taisyti DNS.

Du failai, vienas galinis taškas — tai čia įprastas radinys.

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

Perskaitykite kitą kliento prisijungimo bandymą

Paleiskite ryšį iš naujo su išsamiais žurnalais ir perskaitykite eilutę, kurioje nurodytas adresas, su kuriuo jis susisieks. Būtent ši reikšmė svarbi, o ne ta, kurią išsprendė jūsų naršyklė.

Rezolverio podėlis gali dar laikyti ankstesnį atsakymą, o kai kurie tinklai jį laiko ilgiau, nei reikalauja įrašo TTL. Klauskite rezolverio, kurį klientas iš tikrųjų naudoja, o ne viešo, kurį bandėte kitur.

Jei žurnalas rodo naują adresą, o ryšys vis tiek nepavyksta, problema pasislinko: paketas kažkur eina ir niekas neatsako. Tai klausytojo, ugniasienės ar prievado persiuntimo klausimas, ir jis yra serverio pusėje, o ne kliento sprendimo kelyje. Laikykite šias dvi problemas atskirai, nes nepasiekiamo klausytojo traktavimas kaip DNS problemos veda jus du kartus tuo pačiu ratu.

Žinokite, kokį paleidimą iš naujo darote

Ne visi paleidimai iš naujo išsaugo tą pačią būseną, todėl adreso pokytis gali elgtis skirtingai priklausomai nuo to, kaip procesas perdirbamas. Signalo sukeltas švelnus paleidimas iš naujo išsaugo daugiau ankstesnės sesijos konteksto, o visiškas sustabdymas ir paleidimas pradedami iš naujo nuo konfigūracijos. Jei tikrinate, ar klientas vėl sprendžia, jums reikia kelio, kuris prasideda nuo konfigūracijos.

Išsaugojimo nustatymai taip pat svarbūs, nes jie skirti išlaikyti tai, kas buvo autentifikuota, o ne vytis naujus adresus.

Švariausias testas yra naujas paleidimas iš numatyto profilio, o po to žvilgsnis į žurnalo eilutę, kurioje nurodytas galinis taškas. Viskas, ką sužinosite iš iš dalies išsaugotos sesijos, yra teiginys apie tą sesiją.

Keturios parinktys ir jų atskiri darbai

remote su hosnamu yra nustatymas, kuris apskritai leidžia pakartotinį sprendimą; tiesioginis adresas toje eilutėje tai paneigia. resolv-retry valdo, kas nutinka, kai paieška nepavyksta, o 2.6 jau pagal nutylėjimą nustato begalinį. Todėl jo pridėjimas nieko nekeičia, ir jis niekada neplanuoja periodinės patikros dėl kito atsakymo. Kas sako, kad jis apklausia naujus adresus, supainiojo atkūrimą su šviežumu.

persist-remote-ip yra apie tęstinumą, o ne šviežumą: jis pakartotinai naudoja galinį tašką, kuris paskutinis autentifikavosi, per jo palaikomus švelnius paleidimus. Kol bandote perkėlimą, tai yra priešingybė to, ko norite. Išjunkite jį testui, jei jūsų rinkinys jį įjungia, o tada atkurkite, kai naujasis galinis taškas įrodytas. Palikus įjungtą, sėkmingas prisijungimas gali nieko nepasakyti apie DNS.

float priima autentifikuotą partnerį, kurio adresas pasikeitė sesijos viduryje, ir tik tose sąrankose, kurios tai palaiko. Jis neatnaujina DNS ir savarankiškai neseka tiekėjo pasikeitimo. Traktuokite jį kaip atsparumo funkciją klajojantiems partneriams, o ne kaip dinaminio adreso mechanizmą serveriams.

Patvirtinkite naująjį galinį tašką, prieš kaltindami klientą

Iš išorės savo tinklo patikrinkite, ar naujasis adresas turi klausytoją sukonfigūruotame prieveiksmyje, ir ar tiekėjo persiuntimas į jį nurodo. Teisingas A įrašas mašinai be atviro prievado sukuria būtent tą simptomą, kurį žmonės priskiria podėliui.

Tada prisijunkite iš naujo ir patikrinkite du dalykus: klientas autentifikavosi prie laukiamo serverio sertifikato, ir sesija pasiekia numatytą išteklių. Adreso pakeitimas nesumažina tapatybės reikalavimų, o ryšys, kuris pavyksta prie neteisingo galinio taško, yra blogesnis už nepavykusį. OpenVPN 2.6 vadove išvardytos visos keturios parinktys su savo apimtimi, ir tai yra kontrolinis sąrašas, kurį reikia laikyti prie profilio.

Prieš paleisdami iš naujo tunelį, kuriuo keliauja jūsų administravimo prieiga, pasirūpinkite keliu į serverį už juostos. Ši viena atsargumo priemonė užkerta kelią daugumai incidentų, kuriuos sukelia šis scenarijus.