Ці патрэбен дынамічны DNS для хатняга VPN-сервера?

Дынамічны 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 і дазвол правайдэра на ўваходныя пакеты — усё гэта павінна існаваць раней, чым запіс мае значэнне. Сачыце, на што нацэлена пераадрасацыя: калі яна прывязаная да адраса 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

Запускайце яго з таймера systemd кожныя некалькі хвілін, а не цыклам shell, і запісвайце адказ правайдэра замест таго, каб меркаваць поспех. Стаўцеся да ўліковых даных як да ключа, бо яны вырашаюць, куды накіроўваецца кожны кліент: выкарыстоўвайце абмежаваны токен абнаўлення, а не пароль уліковага запісу, трымайце файл у рэжыме 0600 і адпраўляйце абнаўленні праз HTTPS.

Праверце, перш чым згадзіцца

Адзін запыт паказвае, што бачыць астатні свет, і друкуе TTL, які трэба перачакаць пасля змены:

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

Параўнайце гэты адрас з адрасам WAN роўтара. Калі яны супадаюць, імя робіць сваю справу, а тое, што ўсё яшчэ не працуе, — гэта ўваходная даступнасць, ключ або кліент, які не перавызначыў. Калі яны розныя, абнаўляльнік публікуе не той інтэрфейс, часта таму, што ён працаваў на хосце VPN за роўтарам, а не на самім роўтары.

Трымайце адкат, які займае хвіліну: запішыце апошні працоўны адрас і папярэдні TTL, каб вы маглі апублікаваць абодва ўручную, пакуль у правайдэра дрэнны дзень.

Калі адказ — не

Калі ўмова першая або трэцяя не выкананая, змяняецца рашэнне, а не канфігурацыя. За NAT аператара вашымі практычнымі варыянтамі з’яўляюцца просьба да правайдэра даць публічны адрас, перанос пункту ўваходу на невялікі VPS са стабільным адрасам, або выкарыстанне накладкі, якая трымае ўласную сустрэчу. Калі адрас статычны, прапусціце абнаўляльнік: адзін запіс A, адзін запіс AAAA, калі вы карыстаецеся IPv6, тая ж пераадрасацыя порта.

Калі адрас змяняецца, пакуль кліенты застаюцца падключанымі, сумленнае выпраўленне жыве на кліенце: логіка перападключэння і інтэрвал паўтору, а не хутчэйшы абнаўляльнік. Другі правайдэр толькі хавае інтэрвал.

Перш чым рухацца далей, пацвердзіце чатыры рэчы па парадку:

  • Адрас, які публікуе абнаўляльнік, супадае з адрасам WAN роўтара.
  • TTL запісу дастаткова кароткі, каб змена праявілася на працягу некалькіх хвілін.
  • Пераадрасацыя порта прывязаная да інтэрфейса, а не да фіксаванага адраса.
  • Адзін рэальны кліент перападключыўся і прапусціў трафік пасля апошняй змены.

Калі ўсе чатыры выконваюцца, пакіньце наладку ў спакоі; наступны збой — гэта ключ або правіла фаервала, а не праблема імёнаў. Калі якое-небудзь не выконваецца, выпраўце гэты радок, перш чым дадаваць яшчэ адну рухомую частку. RFC 2136 апісвае сам механізм абнаўлення, калі вы хочаце ўбачыць, што дэман кладзе ў сетку.

Падобныя артыкулы