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.