Ваше DNS име се сада разрешава на адресу VPN провајдера, а дневник ажурирања изгледа потпуно здраво. Та комбинација је нормална. Веб сонда за откривање пита спољну услугу који извор види, и када захтев изађе кроз пун тунел VPN, одговор је излаз VPN-а, а не ваша кућна WAN адреса. Ажурирач је обавио свој посао; посао је био усмерен на погрешно посматрање.

Потврдите до чега име треба да достигне

Јавно име за долазну кућну услугу потребно је адресу преко које одобрене долазне везе могу да достигну ту услугу. Објављивање заједничког излаза провајдера не уређује долазно прослеђивање тамо, и никаква DNS конфигурација не ствара то прослеђивање. Одлучите то пре него што дирнете ажурирач, јер то одређује која је адреса исправна.

Приватно име за адресу тунела VPN клијента је други проблем са другим одговором: припада приватном DNS-у и уопште не захтева јавну услугу откривања. Мешање два захтева је начин на који радна конфигурација почиње да објављује адресу коју нико није тражио.

Адресе интерфејса такође треба тумачити. Адреса преносног рачунара иза кућног рутера није јавна WAN адреса, а чак и WAN адреса рутера може стајати иза carrier-grade NAT-а, где њено објављивање не може дати долазну доступност.

Репродукујте вредност пре него што било шта промените

Посматрајте два пута одвојено. Када је тунел подигнут, сонда пријављује излаз; када је тунел спуштен или је сонда везана за физички интерфејс, пријављује кућну адресу: curl --interface eth0 https://ifconfig.me. Ако се та два одговора разликују, репродуковали сте квар без дирања ажурирача.

Затим покрените клијент у режиму који проверава конфигурацију без извршавања ажурирања, на пример ddclient -verbose -noexec, и прочитајте коју је методу откривања изабрао. Детаљни излаз наводи методу и добијену вредност, а то је чињеница која вам је потребна пре било каквог уређивања.

Усмерите откривање на изабрани пут

Ако име треба да објави кућну WAN адресу, откривање мора да посматра управо ту адресу. Функционишу три опције, грубим редоследом предности: пустите рутер да објављује преко сопственог подржаног ажурирача; користите откривање статуса рутера у ddclient-у према страници коју рутер заиста сервира; или задржите веб сонду, али је вежите за физички интерфејс да излази ван тунела.

За пут статуса рутера новија издања ddclient-а користе фамилију опција usev4 и fwv4, са опционим обрасцем прескакања за околни текст странице. Проверите README за инсталирану верзију, јер старија издања пишу исту идеју са use и fw, а назив опције копиран из погрешног издања пада при покретању.

Ако задржите веб откривање, запамтите да су усмеравање сонде и усмеравање позива API-ја за ажурирање одвојене одлуке. Позив за ажурирање доставља запис; сонда одлучује која ће вредност бити достављена.

Држите тајне и верзије уредно

Акредитиви рутера и токени провајдера припадају заштићеној конфигурационој датотеци, а не командној линији која заврши у историји shell-а. Детаљни трагови могу да садрже обоје, па их очистите пре лепљења у тикет. Метод откривања који захтева стругање аутентификоване странице рутера такође захтева да те акредитиве остану функционалне кроз ажурирања фирмвера. Чувајте их са истом пажњом као токен провајдера.

ddclient README документује приступе откривању и називе њихових опција. Не мешајте резултате IPv4 и IPv6 у једном запису и не претпостављајте да опција присутна у једном издању постоји у другом.

Проверите вредност, а затим доступност

Упоредите предложену адресу са намераваном крајњом тачком пре него што дозволите ажурирање уживо, затим проверите ауторитативни DNS после једног одобреног ажурирања и узмите у обзир кешове резолвера. Низак TTL скраћује чекање; не чини погрешну вредност исправном.

Тек када је запис исправан, тестирајте долазну услугу са независне мреже, уз већ одобрене потребне заштитни зид и прослеђивање. Исправан A запис не доказује доступну услугу, а статични закуп VPN-а може поједноставити приватно именовање без поправљања јавног имена хоста које показује на погрешан WAN.

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