Үй VPN серверіне динамикалық DNS керек пе?

Динамикалық DNS атауды түзеп, кіру жолын түзетпейді. Үш тексеру атау үй VPN серверіне жеткілікті ме, әлде кіру бағыты бұзылған ба — соны шешеді.

Менен сұрайтын үй VPN ақауларының көбі DNS ақауы емес, алайда адамдар алдымен динамикалық DNS жазылымын сатып алады. Бірдеңені конфигурацияламас бұрын, хост атауы шынымен бұзылған бөлік пе — соны шешіңіз. Жаңартқыш провайдер берген мекенжай өзгергенде жазбаны қайта жазады; ол портты аша алмайды, оператор NAT-ынан өте алмайды және жұмыс істеп тұрған WireGuard сессиясына оның соңғы нүктесі өзгергенін байқата алмайды. Динамикалық DNS толық шешім бе, әлде оның бір жолы ғана ма — мұны үш шарт шешеді.

Бірінші шарт: мекенжайыңыз шынымен өзгереді

Тұрғын үй мекенжайлары қарапайым себептермен өзгереді: модем электр қуаты үзілгеннен кейін қайта синхрондалады, провайдер пулды қайта теңестіреді, ұзақ үзілістен кейін жаңа жалдау келеді. Кейбір желілерде олар сирек өзгереді, мен бір мекенжайдың бір жыл бойы тұрғанын көрдім; бизнес тарифтерде көбінесе статикалық мекенжай болады. Егер он екі айда ештеңе өзгермесе, қолмен өңдейтін бір A жазбасы — тірі ұстайтын бір демон кем.

Болжам жасамай, өлшеңіз. Маршрутизатордың күй бетіндегі WAN мекенжайын оқып, оны сыртқы әлем көретін мәнмен салыстырыңыз. Мұны LAN-дағы машинадан іске қосыңыз:

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

Егер екі мән өзгеше болса, маршрутизаторыңыздың алдында бірдеңе аударып тұр және ешбір хост атауын жаңарту оны түзетпейді. 100.64.0.0/10 ішіндегі мекенжай — оператор деңгейіндегі NAT үшін ортақ ауқым, дұрыс жаңартылған атаудың сырттан әлі де уақыты бітуінің әдеттегі себебі осы.

Екінші шарт: клиенттер атауды қайта іздейді

Қысқа TTL — адамдар өткізіп жіберетін бөлік. Рекурсивті шешушілер жазбаның TTL-ін сақтайды, бірақ клиент стектері бөлек кэштейді және көтеріліп тұрған туннель ештеңені қайта шешпейді. Жөндеу кезінде жазбаны 60-300 секундқа қойыңыз; бұл ескірген жауап берілетін терезені қысқартады және қосылған сессияны көшірмейді.

OpenVPN әр қайта қосылғанда жолды remote vpn.example.net 1194 қайта шешеді, ал resolv-retry infinite іздеу сәтсіз болғанда шығып кетудің орнына қайта көруге мәжбүрлейді. Серверде float орныққан сессияға бастапқы мекенжайы өзгерген серіктесті ұстануға мүмкіндік береді. WireGuard тікелейірек: wg-quick up конфигурация қолданылғанда Endpoint шешеді, ал клиент туннельді қайта құрғанда оны қайта шешеді, сондықтан ескі мекенжайға әлі де сәтті өтетін қол алысу тоқтағанға дейін сәтті болады.

Осы айырма жоспарды қалыптастырады. Клиенттер сұраныс бойынша қосылса, мекенжай өзгерісі бір қайта қосылуға тұрарлық. Олар сессияны күндер бойы ашық ұстаса, келесі қол алысуда туннель өледі деп күтіңіз және клиентті қайта көруге мәжбүрлеңіз, оның тұрақты қалатынын болжамаңыз.

Үшінші шарт: кіру жолы әлі ашық

Динамикалық DNS атаудың қайда сілтейтінін ғана өзгертеді, басқа ештеңені. Маршрутизатордағы порт бағыттауы, VPN хостындағы firewall ережесі және провайдердің кіріс пакеттеріне рұқсаты — бәрі жазба маңызды болмас бұрын болуы керек. Бағыттау нені нысанаға алатынын қараңыз: егер ол интерфейске емес, WAN мекенжайына бекітілсе, мекенжай өзгерісі бағыттауды үнсіз бұзады да, кінә жазбаға жүктеледі.

Сырттан сынаңыз. Wi-Fi өшірілген ұялы деректердегі телефон — ең арзан адал сынақ; сол LAN-дағы ноутбук олай емес. Атау жария мекенжайыңызға шешілгенде және маршрутизаторда NAT ілмегі болмаса, ішкі сынақ сәтсіз болады, ал жазба мүлде дұрыс, осы себепті көбісі ешқашан қате болмаған жазбаны өңдеуге кетеді.

Үшеуі де орындалғанда нені іске қосу керек

Кіші хост үшін ddclient — ең аз таңқаларлық жаңартқыш. Ең аз конфигурация провайдер көретін мекенжайды жариялайды, бұл қос 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

Оны shell циклінің орнына бірнеше минут сайын systemd таймерінен іске қосыңыз және сәттілікті болжаудың орнына провайдердің жауабын журналға жазыңыз. Тіркелгі деректерін кілт ретінде ұстаңыз, өйткені ол әр клиенттің қайда жіберілетінін шешеді: тіркелгі құпиясөзінің орнына шектеулі жаңарту токенін пайдаланыңыз, файлды 0600 режимінде ұстаңыз және жаңартуларды HTTPS арқылы жіберіңіз.

Міндеттеме алмас бұрын тексеріңіз

Бір іздеу қалған әлемнің не көретінін айтады және өзгерістен кейін күту керек TTL-ді басып шығарады:

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

Ол мекенжайды маршрутизатордың WAN мекенжайымен салыстырыңыз. Егер сәйкессе, атау өз жұмысын істеп тұр, ал әлі сәтсіз болатыны — кіріс қолжетімділігі, кілт немесе қайта шешпеген клиент. Егер өзгеше болса, жаңартқыш қате интерфейсті жариялайды, көбінесе ол маршрутизатордың өзінде емес, маршрутизатор артындағы VPN хостында жұмыс істегендіктен.

Бір минуттық кері қайтаруды ұстаңыз: соңғы жұмыс істеген мекенжайды және алдыңғы TTL-ді жазып қойыңыз, провайдердің қолайсыз түстен кейінгі уақытында екеуін де қолмен жариялай аласыз.

Жауап жоқ болғанда

Егер бірінші немесе үшінші шарт орындалмаса, конфигурация емес, шешім өзгереді. Оператор NAT-ының артында практикалық таңдауыңыз — провайдерден жария мекенжай сұрау, кіру нүктесін тұрақты мекенжайлы шағын VPS-ке көшіру, немесе өз кездесуін ұстайтын қабатты пайдалану. Егер мекенжай статикалық болса, жаңартқышты өткізіп жіберіңіз: бір A жазбасы, IPv6 қолдансаңыз бір AAAA жазбасы, сол порт бағыттауы.

Клиенттер қосылып тұрғанда мекенжай өзгерсе, адал түзету клиентте тұрады: қайта қосылу логикасы және қайта әрекет ету аралығы, тезірек жаңартқыш емес. Екінші провайдер қосу тек аралықты жасырады.

Алға жылжымас бұрын төрт нәрсені ретімен растаңыз:

  • Жаңартқыш жариялайтын мекенжай маршрутизатордың WAN мекенжайымен сәйкеседі.
  • Жазбаның TTL-і өзгеріс бірнеше минутта көрінетіндей қысқа.
  • Порт бағыттауы интерфейске байланған, тіркелген мекенжайға емес.
  • Соңғы өзгерістен кейін бір нақты клиент қайта қосылып, трафик өткізді.

Егер төртеуі де орындалса, конфигурацияны тыныш қалдырыңыз; келесі ақауыңыз атау мәселесі емес, кілт немесе firewall ережесі. Егер қайсысы болса да орындалмаса, тағы бір қозғалмалы бөлшек қоспас бұрын сол жолды түзетіңіз. RFC 2136 жаңарту механизмінің өзін сипаттайды, егер демонның желіге не салатынын көргіңіз келсе.

Қатысты мақалалар