Kailangan Mo Ba ng Dynamic DNS para sa Home VPN Server?

Karamihan sa mga pagkabigo ng home VPN na itinatanong sa akin ay hindi pagkabigo ng DNS, at gayunman ay bumibili muna sila ng subscription sa dynamic DNS. Bago ka mag-configure ng kahit ano, magpasya kung ang hostname ang bahaging talagang sira. Ang updater ay nagre-rewrite ng record kapag gumalaw ang address na ibinigay sa iyo ng iyong ISP; hindi nito kayang magbukas ng port, makalusot sa carrier NAT, o mapansin ng isang live na sesyon ng WireGuard na nagbago ang endpoint nito. Tatlong kondisyon ang nagpapasya kung ang dynamic DNS ang buong solusyon o isang linya lamang nito.

Kondisyon isa: talagang gumagalaw ang address mo

Gumagalaw ang mga residential address dahil sa karaniwang dahilan: nag-synchronize muli ang modem pagkatapos ng brownout, nire-rebalance ng ISP ang isang pool, may bagong lease pagkatapos ng mahabang outage. Bihira rin silang gumalaw sa ilang linya, at nakita kong tumagal ng isang taon ang parehong address; kadalasang may static na kasama ang business plan. Kung walang nagbago sa labindalawang buwan, ang isang A record na mano-manong ine-edit ay isang daemon na mas kaunti ang iyong pinapanatiling buhay.

Sukatin ito sa halip na manghula. Basahin ang WAN address sa status page ng router, pagkatapos ihambing sa nakikita ng labas na mundo. Patakbuhin ito mula sa isang machine sa LAN:

curl -fsS https://api.ipify.org; echo

Kung magkaiba ang dalawang value, may nagta-translate sa harap ng router mo at walang hostname update na makakaayos nito. Ang address sa loob ng 100.64.0.0/10 ay ang shared range para sa carrier-grade NAT, at iyon ang karaniwang dahilan kung bakit nag-time out pa rin mula sa labas ang isang tamang na-update na pangalan.

Kondisyon dalawa: muling hinahanap ng mga client ang pangalan

Ang maikling TTL ang bahaging nilalaktawan ng mga tao. Ginagalang ng recursive resolver ang TTL ng record, ngunit hiwalay na nag-cache ang client stack, at ang tunnel na nakatayo na ay walang muling nire-resolve. Habang nagde-debug, itakda ang record sa 60-300 segundo; pinaikli nito ang window kung kailan ine-serve ang lumang sagot, at hindi nito inililipat ang konektadong sesyon.

OpenVPN ay muling nire-resolve ang linyang remote vpn.example.net 1194 sa bawat muling pagkonekta, at resolv-retry infinite ay pinipilit itong muling subukan sa halip na umalis kapag nabigo ang lookup. Sa server, float ay nagpapahintulot sa isang established session na sundan ang peer na nagbago ang source address. Ang WireGuard ay mas deretso: wg-quick up ay nire-resolve ang Endpoint kapag inilapat ang configuration, at muling nire-resolve ito ng client kapag itinayo niyang muli ang tunnel, kaya ang handshake na pumapasa pa rin laban sa lumang address ay patuloy na pumapasa hanggang sa tumigil ito.

Hububog ng pagkakaibang iyon ang plano. Kung kumokonekta ang mga client kapag kailangan, isang reconnect ang halaga ng pagbabago ng address. Kung bukas ang sesyon nila nang ilang araw, asahan na mamamatay ang tunnel sa susunod na handshake, at hayaang muling subukan ng client sa halip na ipalagay na nananatili ito.

Kondisyon tatlo: bukas pa rin ang daang papasok

Binabago ng dynamic DNS ang kung saan nakaturo ang pangalan at wala nang iba. Ang port forward sa router, ang firewall rule sa VPN host, at ang pagpayag ng ISP sa papasok na packet ay dapat umiiral bago maging mahalaga ang record. Pagmasdan kung ano ang puntirya ng forward: kung naka-pin ito sa WAN address sa halip na sa interface, tahimik na sisirain ng pagbabago ng address ang forward at ang record ang sisisihin.

Subukan mula sa labas. Ang teleponong nasa cellular data na patay ang Wi-Fi ang pinakamurang tapat na pagsubok; ang laptop sa parehong LAN ay hindi. Kapag nag-resolve ang pangalan sa pampublikong address mo at walang NAT loopback ang router, nabibigo ang pagsubok mula sa loob habang perpektong tama ang record, at iyon ang nagpapadala sa karamihan na i-edit ang record na hindi kailanman nagkamali.

Ano ang patakbuhin kapag natugunan ang tatlo

Ang ddclient ang pinakamaliit na nakakagulat na updater para sa maliit na host. Ang minimal na configuration ay naglalathala ng address na nakikita ng provider, na umiiwas sa pagkakamali ng dobleng NAT:

protocol=dyndns2
use=web, web=https://api.ipify.org
server=updates.your-dns-provider.net
login=vpn-home
password=update-token
vpn.example.net

Patakbuhin ito mula sa systemd timer tuwing ilang minuto sa halip na shell loop, at i-log ang sagot ng provider sa halip na ipalagay ang tagumpay. Tratuhin ang credential na parang susi, dahil ito ang nagpapasya kung saan ipinapadala ang bawat client: gumamit ng limitadong update token sa halip na password ng account, itago ang file sa mode 0600, at ipadala ang mga update sa HTTPS.

Beripikahin bago mag-commit

Ang isang lookup ay nagsasabi kung ano ang nakikita ng natitirang mundo, at ini-print nito ang TTL na kailangan mong hintayin pagkatapos ng pagbabago:

dig +noall +answer vpn.example.net @1.1.1.1

Ihambing ang address na iyon sa WAN address ng router. Kung tugma, ginagawa ng pangalan ang trabaho nito at ang nabibigo pa rin ay papasok na maabot, isang susi, o isang client na hindi muling nag-resolve. Kung magkaiba, naglalathala ang updater ng maling interface, kadalasan dahil tumakbo ito sa VPN host sa likod ng router sa halip na sa router mismo.

Magtabi ng rollback na tumatagal ng isang minuto: itala ang huling gumaganang address at ang dating TTL, upang mailathala mo ang dalawa nang mano-mano habang may masamang hapon ang provider.

Kapag ang sagot ay hindi

Kung nabigo ang kondisyon isa o tatlo, ang desisyon ang nagbabago at hindi ang configuration. Sa likod ng carrier NAT, ang praktikal na opsyon mo ay humingi ng pampublikong address sa ISP, ilipat ang entry point sa maliit na VPS na may stable na address, o gumamit ng overlay na may sariling tagpuan. Kung static ang address, laktawan ang updater: isang A record, isang AAAA record kung gumagamit ka ng IPv6, parehong port forward.

Kung nagbabago ang address habang konektado ang mga client, nasa client ang tapat na pagwawasto: reconnect logic at retry interval, hindi mas mabilis na updater. Tinatago lamang ng pangalawang provider ang interval.

Bago magpatuloy, tiyakin ang apat na bagay ayon sa pagkakasunod-sunod:

• Tugma ang address na inilalathala ng updater sa WAN address ng router.
• Sapat ang ikli ng TTL ng record upang lumitaw ang pagbabago sa loob ng ilang minuto.
• Nakatali ang port forward sa interface, hindi sa fixed na address.
• May isang tunay na client na muling kumonekta at nagpadala ng trapiko mula noong huling pagbabago.

Kung natugunan ang apat, hayaang ganoon ang setup; ang susunod na pagkabigo mo ay isang susi o firewall rule at hindi problema sa pagpapangalan. Kung may nabigo, ayusin ang linyang iyon bago magdagdag ng isa pang gumagalaw na piyesa. RFC 2136 ang naglalarawan ng mismong mekanismo ng update, kung gusto mong makita kung ano ang inilalagay ng daemon sa kawad.