Нужен ли ви е динамичен 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 loopback, вътрешен тест се проваля, докато записът е напълно правилен, което праща повечето хора да редактират запис, който никога не е бил грешен.

Какво да пуснете, когато и трите са налице

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 описва самия механизъм за обновяване, ако искате да видите какво демонът слага по мрежата.

Подобни статии