Менден сураган үй 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 жаңыртуу механизминин өзүн сүрөттөйт, эгер демон тармакка эмне салганын көргүңүз келсе.

Тектеш макалалар