ddclient publisearret de VPN-útgong: reparearje de ûntdekkingsboarne

Jo DNS-namme ferwiist no nei in adres fan in VPN-provider, en it bywurkingslogboek sjocht der folslein sûn út. Dy kombinaasje is normaal. In web-basearre ûntdekkingsprobe freget in eksterne tsjinst hokker boarne er sjocht, en as it fersyk troch in folsleine tunnel-VPN fuortgiet, is it antwurd de VPN-útgong en net jo thús-WAN-adres. De bywurker die syn wurk; it wurk wie rjochte op in ferkearde observaasje.

Befêstigje wat de namme berikke moat

In iepenbiere namme foar in ynkommende thústsjinst hat in adres nedich wêr't goedkarde ynkommende ferbiningen dy tsjinst troch berikke kinne. It publisearjen fan in dielde provider-útgong regelet dêr gjin ynkommende trochstjoering, en gjin inkelde DNS-konfiguraasje makket dy trochstjoering. Beslis dit foardat jo de bywurker oanreitsje, want it bepaalt hokker adres krekt is.

In partikuliere namme foar it tunneladres fan in VPN-klant is in oar probleem mei in oar antwurd: it heart by partikuliere DNS, en it hat hielendal gjin iepenbiere ûntdekkingstsjinst nedich. It mingen fan de twa easken is hoe't in wurkjende konfiguraasje in adres begjint te publisearjen dat nimmen frege hat.

Ynteface-adressen moatte ek ynterpretearre wurde. It adres fan in laptop efter in thúsrouter is net it iepenbiere WAN-adres, en sels it WAN-adres fan de router kin efter carrier-grade NAT sitte, wêr't publisearjen gjin ynkommende berikberens opsmite kin.

Reprodusearje de wearde foardat jo wat feroarje

Observearje de twa paden apart. Mei de tunnel oan rapportearret in probe de útgong; mei de tunnel út, of mei de probe bûn oan de fysike ynterface, rapportearret er it thúsadres: curl --interface eth0 https://ifconfig.me. As dy twa antwurden ferskille, hawwe jo de flater reprodusearre sûnder de bywurker oan te reitsjen.

Run dêrnei de klant yn in modus dy't de konfiguraasje kontrolearret sûnder in bywurking te dwaan, bygelyks ddclient -verbose -noexec, en lês hokker ûntdekkingsmetoade er keas. De wiidweidige útfier neamt de metoade en de wearde dy't er krige, en dat is it feit dat jo nedich hawwe foardat jo wat bewurkje.

Rjochtsje de ûntdekking op it keazen paad

As de namme it thús-WAN-adres publisearje moat, moat de ûntdekking dat adres observearje. Trije opsjes wurkje, yn rûge folchoarder fan foarkar: lit de router publisearje fia syn eigen stipe bywurker; brûk ddclient syn routerstatus-ûntdekking tsjin in side dy't de router wier tsjinnet; of hâld in webprobe mar byn dy oan de fysike ynterface sadat er bûten de tunnel fuortgiet.

Foar it routerstatus-paad brûke nijere ddclient-ferzjes de opsjefamylje usev4 en fwv4, mei in opsjoneel oerslachpatroan foar de omlizzende sidetekst. Kontrolearje de README foar jo ynstallearre ferzje, want âldere ferzjes skriuwe itselde idee mei use en fw, en in opsjenamme kopiearre út de ferkearde ferzje falt by it starten.

As jo webûntdekking hâlde, tink dan dat it rûtesjen fan de probe en it rûtesjen fan de bywurkings-API-oprop aparte besluten binne. De bywurkingsoprôp leveret it record; de probe beslút de wearde dy't levere wurdt.

Hâld geheimen en ferzjes rjochts

Router-ynloggegevens en provider-tokens hearre yn in beskerme konfiguraasjebestân, net op in kommandorigel dy't yn de shell-skiednis bedarret. Wiidweidige spoaren kinne beide befetsje, sadat jo se redigearje foardat jo se yn in ticket plakke. In ûntdekkingsmetoade dy't in autentisearre routerseide skrape moat, freget ek dat jo dy ynloggegevens oer firmware-bywurkings hinne wurkje litte. Bewarje se mei deselde soarch as it provider-token.

ddclient README dokumintearret de ûntdekkingsmetoaden en har opsjenammen. Ming gjin IPv4- en IPv6-resultaten yn ien record, en nim net oan dat in opsje yn in ferzje ek yn in oare bestiet.

Ferifiearje de wearde, dan de berikberens

Fergelykje it foarstelde adres mei it bedoelde einpunt foardat jo in live-bywurking tastean, kontrolearje dan autoritative DNS nei ien autorisearre bywurking en rekkene mei resolver-caches. In lege TTL ferkoartet it wachtsjen; it makket in ferkearde wearde net rjocht.

Pas as it record rjocht is, moatte jo de ynkommende tsjinst testen fan in ûnôfhinklik netwurk, mei de fereaske firewall en trochstjoering al goedkard. In rjocht A-record bewiist gjin berikbere tsjinst, en in statyske VPN-liening kin partikuliere nammejouwing ferienfâldigje sûnder in iepenbiere hostnamme te reparearjen dy't nei de ferkearde WAN wiist.