Lumipat ang VPN: bakit ang iyong OpenVPN client ay tumatawag pa rin sa lumang IP

Pinalitan ng provider ang iyong pampublikong address, in-update mo ang dynamic na DNS record, at hindi pa rin makakonekta ang client. Mula sa labas, mukhang hindi kumalat ang record. Kadalasan, maayos ang record at tinatawagan ng client ang address na naresolba nito bago ang paglipat, dahil ang tumatakbong tunnel at ang naka-save na profile ay may kanya-kanyang ideya kung saan nakatira ang server. Tatlong layer ang dapat magkasundo, at nag-a-update sila sa magkaibang iskedyul.

Tingnan kung ano ang tinatawagan ng profile, hindi kung ano ang sinasabi ng DNS

Buksan ang koneksyong aktuwal mong ginagamit at basahin ang linyang remote. Ang numerikong address doon ay hindi kailanman sumusunod sa update ng hostname, gaano man katama ang record.

Pagkatapos, tingnan kung ang profile na in-edit mo ang siyang na-load ng client. Karaniwan ang mga na-import na profile: maaaring kumuha ng kopya ang isang manager mga buwan na ang nakalipas at itinago ang sariling bersyon, kaya maaaring magkaiba ang file sa iyong download folder at ang entry sa app. Ihambing ang endpoint sa sariling detalye ng koneksyon ng client bago mo pa simulan ang pag-debug ng DNS.

Dalawang file, isang endpoint — iyon ang karaniwang natatagpuan dito.

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

Basahin ang susunod na pagtatangkang kumonekta ng client

I-restart ang koneksyon nang may detalyadong pag-log at basahin ang linyang nagpangalan ng address na kokontakin nito. Ang halagang iyon ang mahalaga, hindi ang naresolba ng iyong browser.

Maaaring hawak pa ng cache ng resolver ang nakaraang sagot, at may mga network na nagtatago nito nang mas matagal kaysa hinihingi ng TTL ng record. Itanong sa resolver na aktuwal na ginagamit ng client, hindi sa pampublikong sinubukan mo mula sa ibang lugar.

Kung ipinapakita ng log ang bagong address at nabibigo pa rin ang koneksyon, lumipat na ang problema: may pinupuntahan ang packet at walang sumasagot. Ito ay tungkol sa listener, firewall, o port forwarding, at nasa panig ng server ito hindi sa landas ng resolution ng client. Paghiwalayin ang dalawang kabiguan, dahil ang ituring na problema sa DNS ang isang listener na hindi maabot ay dalawang beses kang paiikutin sa parehong loop.

Alamin kung aling restart ang ginagawa mo

Hindi lahat ng restart ay nagpapanatili ng parehong estado, kaya maaaring iba ang kilos ng pagbabago ng address depende sa kung paano nire-recycle ang proseso. Ang malambot na restart na pinukaw ng signal ay nagpapanatili ng higit sa konteksto ng nakaraang session, samantalang ang buong paghinto at pagsisimula ay nagsisimula muli sa configuration. Kung sinusubok mo kung nagre-resolve muli ang client, gusto mo ang landas na nagsisimula sa configuration.

Mahalaga rin ang mga setting ng persistence, dahil ginawa ang mga ito para itago ang na-authenticate, hindi para habulin ang mga bagong address.

Ang pinakamalinis na pagsubok ay isang sariwang simula mula sa nilalayong profile, na sinusundan ng pagsulyap sa log line na nagpangalan ng endpoint. Anumang matututunan mo mula sa bahagyang naitagong session ay isang pahayag tungkol sa session na iyon.

Ang apat na opsyon at ang kanilang hiwalay na gawain

remote na may hostname ang setting na nagpapangyari sa muling pag-resolve; ang literal na address sa linyang iyon ay hindi ito papayagan. Kinokontrol ng resolv-retry ang nangyayari kapag nabigo ang lookup, at itinatakda na ito ng 2.6 sa infinite bilang default. Kaya wala itong binabago kapag idinagdag, at hindi ito kailanman nag-iiskedyul ng pana-panahong pagsusuri para sa ibang sagot. Ang sinumang nagsasabing nagso-survey ito ng mga bagong address ay hinahalo ang pagbangon sa pagiging bago.

persist-remote-ip ay tungkol sa pagpapatuloy hindi sa pagiging bago: ginagamit muli nito ang endpoint na huling nag-authenticate, sa mga malambot na restart na sinusuportahan nito. Habang sinusubok mo ang paglipat, iyon ang kabaligtaran ng gusto mo. I-disable ito para sa pagsubok kung ine-enable ito ng iyong build, at ibalik kapag napatunayan na ang bagong endpoint. Kung iiwan na naka-on, maaaring walang masabi sa iyo ang matagumpay na muling pagkonekta tungkol sa DNS.

float ay tumatanggap ng authenticated peer na nagbago ang address sa kalagitnaan ng session, at sa mga setup lamang na sumusuporta dito. Hindi ito nagre-refresh ng DNS, at hindi nito susundan nang mag-isa ang pagbabago ng provider. Ituring itong feature ng tibay para sa mga peer na gumagalaw, hindi bilang mekanismo ng dynamic na address para sa mga server.

Kumpirmahin ang bagong endpoint bago sisihin ang client

Mula sa labas ng iyong network, tingnan kung may listener ang bagong address sa naka-configure na port at kung nakaturo rito ang forwarding ng provider. Ang tamang A record para sa makinang walang bukas na port ay gumagawa ng eksaktong sintomas na iniaatang ng mga tao sa cache.

Pagkatapos, kumonekta muli at i-verify ang dalawang bagay: nag-authenticate ang client laban sa inaasahang server certificate, at naaabot ng session ang resource na nilayon mo. Ang pagbabago ng address ay hindi nagbababa ng mga pangangailangan sa pagkakakilanlan, at ang koneksyong nagtatagumpay patungo sa maling endpoint ay mas masama kaysa sa nabigo. Inililista ng manual ng OpenVPN 2.6 ang lahat ng apat na opsyon kasama ang sariling saklaw, at iyon ang checklist na dapat itago sa tabi ng profile.

Magtabi ng out-of-band na daan papasok sa server bago mo i-restart ang tunnel na nagdadala ng iyong administratibong access. Ang isang pag-iingat na iyon ay pumipigil sa karamihan ng mga insidenteng nililikha ng senaryong ito.