ddclient ay naglalathala ng labasan ng VPN: ayusin ang pinagmumulan ng pagtuklas

Ang iyong DNS name ay nagsasalin na ngayon sa isang address ng isang VPN provider, at ang update log ay mukhang ganap na malusog. Ang kombinasyong iyon ay normal. Ang isang web-based na discovery probe ay nagtatanong sa isang panlabas na serbisyo kung anong pinagmulan ang nakikita nito, at kapag lumabas ang kahilingan sa isang full-tunnel VPN, ang sagot ay ang labasan ng VPN at hindi ang iyong home WAN address. Ginawa ng updater ang trabaho nito; ang trabaho ay nakaturo sa maling obserbasyon.

Kumpirmahin kung ano ang dapat maabot ng pangalan

Ang isang pampublikong pangalan para sa isang papasok na serbisyo sa bahay ay nangangailangan ng isang address kung saan maaaring maabot ng mga aprubadong papasok na koneksyon ang serbisyong iyon. Ang paglalathala ng isang ibinahaging labasan ng provider ay hindi nag-aayos ng papasok na pagpapasa doon, at walang configuration ng DNS ang lumilikha ng pagpapasang iyon. Magpasya tungkol dito bago mo hawakan ang updater, dahil ito ang tumutukoy kung aling address ang tama.

Ang isang pribadong pangalan para sa tunnel address ng isang VPN client ay isa pang problema na may isa pang sagot: kabilang ito sa pribadong DNS, at hindi ito nangangailangan ng pampublikong serbisyo ng pagtuklas. Ang paghahalo ng dalawang pangangailangan ay ang paraan kung paano nagsisimulang maglathala ang isang gumaganang configuration ng address na walang hiniling.

Ang mga address ng interface ay nangangailangan din ng interpretasyon. Ang address ng laptop sa likod ng router sa bahay ay hindi ang pampublikong WAN address, at kahit ang WAN address ng router ay maaaring nasa likod ng carrier-grade NAT, kung saan ang paglalathala nito ay hindi makalilikha ng papasok na maabot.

Kopyahin muli ang halaga bago baguhin ang anuman

Obserbahan ang dalawang landas nang hiwalay. Kapag nakaangat ang tunnel, nag-uulat ang probe ng labasan; kapag nakababa ang tunnel, o nakatali ang probe sa pisikal na interface, nag-uulat ito ng address sa bahay: curl --interface eth0 https://ifconfig.me. Kung magkaiba ang dalawang sagot na iyon, nagawa mong muli ang depekto nang hindi hinahawakan ang updater.

Pagkatapos patakbuhin ang client sa isang mode na sinusuri ang configuration nang hindi nagsasagawa ng update, halimbawa ddclient -verbose -noexec, at basahin kung aling paraan ng pagtuklas ang pinili nito. Pinapangalanan ng detalyadong output ang paraan at ang halagang nakuha, at iyon ang katotohanang kailangan mo bago mag-edit ng anuman.

Ituro ang pagtuklas sa piniling landas

Kung kailangang ilathala ng pangalan ang home WAN address, dapat obserbahan ng pagtuklas ang mismong address na iyon. Gumagana ang tatlong opsyon, sa magaspang na pagkakasunod-sunod ng kagustuhan: hayaang maglathala ang router sa pamamagitan ng sarili nitong sinusuportahang updater; gamitin ang pagtuklas ng router status ng ddclient laban sa isang pahinang talagang inihahain ng router; o panatilihin ang web probe ngunit itali ito sa pisikal na interface upang lumabas sa labas ng tunnel.

Para sa landas ng router status, gumagamit ang mga bagong release ng ddclient ng pamilya ng opsyon na usev4 at fwv4, na may opsyonal na pattern ng paglaktaw para sa teksto sa paligid ng pahina. Tingnan ang README para sa na-install na bersyon, dahil isinusulat ng mga lumang release ang parehong ideya sa use at fw, at ang pangalan ng opsyon na kinopya mula sa maling release ay nabigo sa pagsisimula.

Kung panatilihin mo ang web discovery, tandaan na ang routing ng probe at routing ng update API call ay magkahiwalay na desisyon. Ang update call ang naghahatid ng record; ang probe ang nagpapasya kung anong halaga ang ihahatid.

Panatilihing maayos ang mga sikreto at bersyon

Ang mga kredensyal ng router at token ng provider ay nabibilang sa isang protektadong configuration file, hindi sa isang command line na napupunta sa kasaysayan ng shell. Ang mga detalyadong trace ay maaaring maglaman ng pareho, kaya i-redact ang mga ito bago i-paste sa isang ticket. Ang isang paraan ng pagtuklas na nangangailangan ng pag-scrape ng isang authenticated na pahina ng router ay nangangailangan din na panatilihin mong gumagana ang kredensyal na iyon sa mga update ng firmware. Itabi ito nang may parehong pag-iingat gaya ng token ng provider.

ddclient README ay nagdodokumento ng mga paraan ng pagtuklas at ng kanilang mga pangalan ng opsyon. Huwag paghaluin ang mga resulta ng IPv4 at IPv6 sa isang record, at huwag ipagpalagay na ang isang opsyon na nasa isang release ay umiiral sa isa pa.

I-verify ang halaga, pagkatapos ang maabot

Ihambing ang iminungkahing address sa nilalayong endpoint bago payagan ang isang live na update, pagkatapos suriin ang authoritative DNS pagkatapos ng isang awtorisadong update at isaalang-alang ang mga cache ng resolver. Pinapaikli ng mababang TTL ang paghihintay; hindi nito ginagawang tama ang isang maling halaga.

Pagkatapos lamang maging tama ang record dapat mong subukan ang papasok na serbisyo mula sa isang independiyenteng network, kung ang kinakailangang firewall at pagpapasa ay aprubado na. Ang tamang A record ay hindi nagpapatunay ng serbisyong maabot, at ang isang static na pag-upa ng VPN ay maaaring gawing simple ang pribadong pagbibigay ng pangalan nang hindi inaayos ang isang pampublikong hostname na tumuturo sa maling WAN.