ddclient ја објавува излезната VPN: поправете го изворот на откривање

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

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

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

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

Адресите на интерфејсот исто така бараат толкување. Адресата на преносен компјутер зад домашен рутер не е јавната WAN адреса, и дури WAN адресата на рутерот може да стои зад NAT на оператор, каде што нејзиното објавување не може да обезбеди влезна достапност.

Репродуцирајте ја вредноста пред да смените нешто

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

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

Насочете го откривањето кон избраниот пат

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

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

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

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

Податоците за најава на рутерот и токените на провајдерот припаѓаат во заштитена конфигурациска датотека, а не во командна линија што завршува во историјата на shell. Деталните траги можат да ги содржат двете, па исчистете ги пред да ги залепите во тикет. Методот на откривање што бара стружење автентифицирана страница на рутерот, исто така, бара тие податоци за најава да продолжат да работат низ ажурирањата на firmware. Чувајте ги со истото внимание како токенот на провајдерот.

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

Проверете ја вредноста, потоа достапноста

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

Дури откако записот е точен, треба да ја тестирате влезната услуга од независна мрежа, со веќе одобрени потребните огнен ѕид и препраќање. Точен A запис не докажува достапна услуга, а статичен закуп на VPN може да го поедностави приватното именување без да го поправи јавното име на домаќин што покажува на погрешниот WAN.