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

Повезани чланци