Pangalan ng VPN endpoint kumpara sa pangalan ng pribadong serbisyo: dalawang may-ari

Dalawang pangalan ang maaaring maglarawan sa iisang sangay at sumagot sa lubos na magkaibang tanong. Sinasabi ng vpn.branch.example sa malayong peer kung saan hahanapin ang VPN endpoint, at dapat itong maresolba bago umiral ang anumang tunel. Sinasabi ng inventory.branch.example sa awtorisadong gumagamit kung saan nakatira ang pribadong aplikasyon, at mahalaga lamang ito kapag nakaangat na ang tunel. Walang ginagawa ang pagpapanatili ng isa para sa ikalawa.

Pangalanan ang dalawang record bago i-debug ang alinman sa kanila

Isulat ang dalawa kasama ang kanilang mga may-ari. Para sa endpoint, itala kung sino ang nag-a-update ng pampublikong address at kung paano nire-refresh ng VPN client ang sagot nito. Para sa serbisyo, itala kung sino ang may-ari ng pribadong address, aling zone ang may hawak ng record at aling mga resolver ang dapat sumagot para dito.

Pinipigilan ng maikling listahang iyon ang pinakakaraniwang maling diagnosis sa larangang ito: ang i-restart ang gumaganang tunel ng sangay para ayusin ang record na nabubuhay nang buo sa loob nito. Ang tunel ay ang transportasyon para sa pangalan ng serbisyo; hindi ito ang awtoridad nito.

Kapag may iminumungkahing pagbabago, itanong kung alin sa dalawang record ang tinatamaan nito. Kung walang makasagot, hindi pa handa ang pagbabago para i-iskedyul.

Dapat maresolba ang endpoint bago umiral ang anumang tunel

Ipagpalagay na ang koneksyon sa internet ng sangay ay tumatanggap ng bagong pampublikong address. Inilalathala ng updater ng endpoint ang bagong address, at dapat mabasa ng malayong implementasyon ng VPN ang binagong sagot. Alinmang resolver ang nagbibigay ng sagot na iyon ay dapat maabot nang walang tunel, kung hindi ay hinahabol ng client ang pangalan na maaari lamang nitong maresolba pagkatapos kumonekta sa bagay na hindi nito mahanap.

Sulit sabihin nang tuwiran ang dependency sa pagsisimula, dahil madali itong malikha nang aksidente kapag lahat ng panloob na resolver ay nasa likod ng VPN. Panatilihin ang landas bago ang tunel para sa paghahanap ng endpoint, at kumpirmahin ang pag-uugali ng muling pagkonekta ng client sa halip na ipagpalagay na agad na nakukuha ang bagong sagot.

May mga hangganan din ang dynamic na DNS na hindi malalampasan ng pag-update ng record. Ang pag-update ng record ay hindi nagbubukas ng port ng firewall, hindi gumagawa ng NAT mapping at hindi nagpapatunay ng pagkakakilanlan ng peer. Ang inilathalang address na may saradong port ay nagbibigay ng client na tama ang resolusyon at hindi pa rin makakonekta sa kahit ano.

Sa wakas, ang tumatakbong client ay maaaring magpatuloy gamit ang naka-cache na endpoint hanggang muling kumonekta. Paghiwalayin sa iyong mga tala ang paglalathala, cache at patakaran sa muling pagkonekta, upang ang lumang peer ay hindi mapagkamalang sira na updater.

Inilalarawan ng pangalan ng serbisyo kung saan nakatira ang aplikasyon

Ngayon ipagpalagay na nananatiling malusog ang tunel ngunit lumilipat ang inventory server mula 172.26.14.20 patungong 172.26.14.35. Hindi apektado ang pampublikong record ng endpoint, samantalang kailangang magbago ang pribadong record ng serbisyo. Ang paggamit ng address na nakalaan para sa serbisyong iyon, o static na pagtatalaga, ay ginagawang mas bihira ito; ang awtorisadong landas ng pag-update ang humahawak sa mga pagkakataong sinasadya ito.

Dalawang mekanismo ng pag-update ang pinaghahalo dito. Ang RFC 2136 ay naglalarawan ng protocol para sa pagdaragdag at pagtanggal ng mga DNS record sa isang zone, samantalang ang isang komersyal na tagapagbigay ng dynamic na DNS ay maaaring maglabas ng lubos na ibang HTTP API para sa ibang layunin. Ang paggamit ng isa ay hindi nangangahulugang naroroon ang ikalawa sa iyong kapaligiran. Suriin kung aling mekanismo ang talagang tinatanggap ng iyong zone bago magsulat ng updater laban dito.

Ang tamang pribadong sagot ay unang kondisyon lamang. Upang magamit ito ng malayong tumatawag, kailangan ng client ng resolver na nagdadala ng pribadong zone, patakarang nagpapahintulot ng mga query sa resolver na iyon, at pagpapasa para sa address na bumabalik. Ang pangalan na nare-resolba sa address na hindi maabot ng client ay gumagawa ng timeout na mukhang sira ng server.

Subukan ang dalawang landas nang hiwalay

Suriin ang endpoint mula sa labas ng tunel at ang serbisyo mula sa loob, at itago ang mga resulta bilang dalawang malayang katotohanan:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

Kung mabigo ang unang query, ang problema ay ang pampublikong paglalathala o ang landas ng resolusyon bago ang tunel, at walang panloob na pagbabago ang makakatulong. Kung ang ikalawa ay nagbabalik ng address ngunit ang ikatlo ay walang ipinapakitang ruta sa tunel, maayos ang antas ng DNS at hindi maayos ang patakaran ng pagpapasa.

Patakbuhin ang pares pagkatapos ng bawat pagbabago ng address, at itala kung aling record ang gumalaw. Ang pagturnover na nagsasabi lamang ng «na-update ang DNS» ay nag-iiwan sa susunod na inhinyero na hulaan kung alin sa dalawang lifecycle ang talagang tumakbo.