La VPN translokiĝis: kial via OpenVPN-kliento ankoraŭ alvokas la malnovan IP

La provizanto ŝanĝis vian publikan adreson, vi ĝisdatigis la dinamikan DNS-rikordon, kaj la kliento ankoraŭ ne povas konektiĝi. De ekstere ŝajnas, ke la rikordo ne disvastiĝis. Plej ofte la rikordo estas en ordo kaj la kliento alvokas la adreson, kiun ĝi solvis antaŭ la translokiĝo, ĉar funkcianta tunelo kaj konservita profilo havas ambaŭ sian propran ideon pri tio, kie loĝas la servilo. Tri tavoloj devas konsenti, kaj ili ĝisdatiĝas laŭ malsamaj horaroj.

Rigardu, kion la profilo alvokas, ne kion diras DNS

Malfermu la konekton, kiun vi fakte uzas, kaj legu la linion remote. Numera adreso tie neniam sekvas ĝisdatigon de gastigantnomo, kiom ajn ĝusta fariĝos la rikordo.

Poste kontrolu, ĉu la profilo, kiun vi redaktis, estas tiu, kiun la kliento ŝargis. Importitaj profiloj oftas: administranto eble antaŭ monatoj prenis kopion kaj konservis sian propran version, do la dosiero en via elŝuta dosierujo kaj la ero en la aplikaĵo povas malkonsenti. Komparu la finpunkton en la propraj konektaj detaloj de la kliento antaŭ ol eĉ sencimigi DNS.

Du dosieroj, unu finpunkto — jen la kutima trovo ĉi tie.

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

Legu la sekvan konektoprovon de la kliento

Restartu la konekton kun detala protokolado kaj legu la linion, kie ĝi nomas la adreson, kiun ĝi kontaktos. Tiu valoro gravas, ne tio, kion solvis via retumilo.

Solvila kaŝmemoro ankoraŭ povas teni la antaŭan respondon, kaj iuj retoj tenas ĝin pli longe ol la TTL de la rikordo postulas. Demandu la solvilon, kiun la kliento fakte uzas, anstataŭ publikan, kiun vi testis de aliloke.

Se la protokolo montras la novan adreson kaj la konekto ankoraŭ malsukcesas, la problemo moviĝis: la paketo iras ien kaj neniu respondas. Tio estas demando pri aŭskultanto, fajroŝirmilo aŭ pordoadresado, kaj ĝi staras ĉe la servila flanko, ne en la solva vojo de la kliento. Tenu tiujn du malsukcesojn aparte, ĉar trakti neatingeblan aŭskultanton kiel DNS-problemon kondukas vin dufoje tra la sama buklo.

Sciu, kiun restartadon vi faras

Ne ĉiuj restartadoj konservas la saman staton, kaj tial adresa ŝanĝo povas konduti malsame laŭ tio, kiel la procezo estas recikligata. Mola restartado kaŭzita de signalo konservas pli da kunteksto de la antaŭa sesio, dum plena halto kaj starto rekomendas de la agordo. Se vi testas, ĉu la kliento re-solvas, vi volas la vojon, kiu komenciĝas de la agordo.

Ankaŭ persistemaj agordoj gravas, ĉar ili celas konservi tion, kio estis aŭtentigita, ne postkuri novajn adresojn.

La plej pura testo estas freŝa starto el la celata profilo, sekvata de rigardo al la protokola linio, kiu nomas la finpunkton. Ĉio, kion vi lernas el parte konservita sesio, estas aserto pri tiu sesio.

La kvar opcioj kaj iliaj apartaj taskoj

remote kun gastigantnomo estas la agordo, kiu entute ebligas re-solvadon; laŭvorta adreso en tiu linio malebligas ĝin. resolv-retry regas, kio okazas kiam serĉo malsukcesas, kaj la 2.6 jam defaŭltigas ĝin al senfina. Aldoni ĝin do ŝanĝas nenion, kaj ĝi neniam planas periodan kontrolon por alia respondo. Kiu diras, ke ĝi enketas novajn adresojn, tiu konfuzis restaŭron kun freŝeco.

persist-remote-ip temas pri kontinueco, ne pri freŝeco: ĝi reuzas la finpunkton, kiu laste aŭtentiĝis, tra la molaj restartadoj, kiujn ĝi subtenas. Dum vi testas translokiĝon, tio estas la malo de tio, kion vi volas. Malŝaltu ĝin por la testo, se via konstruaĵo ŝaltas ĝin, poste restarigu ĝin, kiam la nova finpunkto estas pruvita. Lasita ŝaltita, sukcesa rekonekto eble diras al vi nenion pri DNS.

float akceptas aŭtentigitan samulon, kies adreso ŝanĝiĝis mez-sesie, kaj nur en aranĝoj, kiuj subtenas tion. Ĝi ne refreŝigas DNS, kaj ĝi ne sekvos provizantan ŝanĝon proprainiciate. Traktu ĝin kiel elastecan funkcion por samuloj, kiuj migras, ne kiel mekanismon de dinamikaj adresoj por serviloj.

Konfirmu la novan finpunkton antaŭ ol kulpigi la klienton

De ekstere de via reto, kontrolu, ĉu la nova adreso havas aŭskultanton sur la agordita pordo kaj ĉu la pordadreso de la provizanto montras al ĝi. Ĝusta A-rikordo por maŝino sen malfermita pordo produktas ĝuste tiun simpton, kiun homoj atribuas al kaŝmemoro.

Poste rekonektu kaj kontrolu du aferojn: la kliento aŭtentiĝis kontraŭ la atendata servila atestilo, kaj la sesio atingas la rimedon, kiun vi intencis. Adresa ŝanĝo ne malaltigas la identecajn postulojn, kaj konekto, kiu sukcesas al la malĝusta finpunkto, estas pli malbona ol tiu, kiu malsukcesas. La manlibro de OpenVPN 2.6 listigas ĉiujn kvar opciojn kun ilia propra amplekso, kaj tio estas la kontrol-listo, kiun teni apud la profilo.

Tenu ekster-bandan vojon en la servilon antaŭ ol restartigi la tunelon, kiu portas vian administran aliron. Tiu unu antaŭzorgo malhelpas la plej multajn incidentojn, kiujn ĉi tiu scenaro produktas.