ddclient offentliggør VPN-udgangen: ret opdagelseskilden

Dit DNS-navn peger nu på en adresse hos en VPN-udbyder, og opdateringsloggen ser helt sund ud. Den kombination er normal. En webbaseret opdagelses-sonde spørger en ekstern tjeneste, hvilken kilde den ser, og når anmodningen forlader gennem en fuld tunnel-VPN, er svaret VPN-udgangen og ikke din hjemme-WAN-adresse. Opdatereren gjorde sit arbejde; arbejdet var rettet mod en forkert observation.

Bekræft, hvad navnet skal nå

Et offentligt navn til en indgående hjemmetjeneste har brug for en adresse, gennem hvilken godkendte indgående forbindelser kan nå den tjeneste. At offentliggøre en delt udbyderudgang sørger ikke for indgående videresendelse der, og ingen mængde DNS-konfiguration skaber den videresendelse. Beslut det, før du rører opdatereren, fordi det afgør, hvilken adresse der er den rigtige.

Et privat navn til en VPN-klients tunneladresse er et andet problem med et andet svar: det hører til i privat DNS og har slet ikke brug for en offentlig opdagelsestjeneste. At blande de to krav er måden, hvorpå en fungerende konfiguration begynder at offentliggøre en adresse, som ingen har bedt om.

Interfaceadresser skal også fortolkes. En bærbar adresse bag en hjemmerouter er ikke den offentlige WAN-adresse, og selv routerens WAN-adresse kan ligge bag carrier-grade NAT, hvor offentliggørelse ikke kan give indgående tilgængelighed.

Genskab værdien, før du ændrer noget

Observer de to veje hver for sig. Med tunnelen oppe rapporterer en sonde udgangen; med tunnelen nede, eller med sonden bundet til det fysiske interface, rapporterer den hjemmeadressen: curl --interface eth0 https://ifconfig.me. Hvis de to svar er forskellige, har du genskabt fejlen uden at røre opdatereren.

Kør derefter klienten i en tilstand, der kontrollerer konfigurationen uden at udføre en opdatering, for eksempel ddclient -verbose -noexec, og læs, hvilken opdagelsesmetode den valgte. Det udførlige output angiver metoden og den værdi, den fik, og det er netop det forhold, du har brug for, før du redigerer noget.

Ret opdagelsen mod den valgte vej

Hvis navnet skal offentliggøre hjemme-WAN-adressen, skal opdagelsen observere netop den adresse. Tre muligheder virker, i grov prioriteret rækkefølge: lad routeren offentliggøre gennem sin egen understøttede opdaterer; brug ddclients routerstatus-opdagelse mod en side, som routeren faktisk betjener; eller behold en web-sonde, men bind den til det fysiske interface, så den forlader uden om tunnelen.

Til routerstatus-vejen bruger nyere ddclient-udgivelser optionsfamilien usev4 og fwv4, med et valgfrit springmønster til den omkringliggende sidetekst. Tjek README for din installerede version, fordi ældre udgivelser skriver samme idé med use og fw, og et optionsnavn kopieret fra den forkerte udgivelse fejler ved opstart.

Beholder du webopdagelse, så husk, at routing af sonden og routing af opdaterings-API-kaldet er separate beslutninger. Opdateringskaldet leverer posten; sonden afgør den værdi, der leveres.

Hold styr på hemmeligheder og versioner

Routerlegitimationsoplysninger og udbyderens tokens hører i en beskyttet konfigurationsfil, ikke på en kommandolinje, der ender i shell-historikken. Udførlige spor kan indeholde begge, så rediger dem, før du indsætter dem i en sag. En opdagelsesmetode, der kræver scraping af en autentificeret routerside, kræver også, at du holder de oplysninger kørende gennem firmwareopdateringer. Opbevar dem med samme omhu som udbyderens token.

ddclient README dokumenterer opdagelsestilgangene og deres optionsnavne. Bland ikke IPv4- og IPv6-resultater i én post, og antag ikke, at en option, der findes i én udgivelse, findes i en anden.

Verificer værdien, derefter tilgængeligheden

Sammenlign den foreslåede adresse med det tilsigtede slutpunkt, før du tillader en live-opdatering, og tjek derefter autoritativ DNS efter én godkendt opdatering og tag højde for resolver-caches. En lav TTL forkorter ventetiden; den gør ikke en forkert værdi rigtig.

Først når posten er korrekt, bør du teste den indgående tjeneste fra et uafhængigt netværk med den krævede firewall og videresendelse allerede godkendt. En korrekt A-post beviser ikke en tilgængelig tjeneste, og en statisk VPN-lease kan forenkle privat navngivning uden at reparere et offentligt værtsnavn, der peger på den forkerte WAN.