ddclient публикува изхода на VPN: поправете източника на откриване

Вашето 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.