Дали ви треба динамичен 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 го опишува самиот механизам за ажурирање, ако сакате да видите што демонот става на жицата.

Поврзани статии