ddclient publicerar VPN-utgången: rätta upptäcktskällan

Ditt DNS-namn pekar nu på en adress hos en VPN-leverantör, och uppdateringsloggen ser helt frisk ut. Den kombinationen är normal. En webbaserad upptäcktssond frågar en extern tjänst vilken källa den ser, och när begäran går ut genom en full tunnel-VPN är svaret VPN-utgången och inte din hemma-WAN-adress. Uppdateraren gjorde sitt jobb; jobbet var riktat mot en felaktig observation.

Bekräfta vad namnet ska nå

Ett publikt namn för en inkommande hemmatjänst behöver en adress som godkända inkommande anslutningar kan nå tjänsten genom. Att publicera en delad leverantörsutgång ordnar ingen inkommande vidarebefordran där, och ingen DNS-konfiguration skapar den vidarebefordran. Bestäm detta innan du rör uppdateraren, eftersom det avgör vilken adress som är rätt.

Ett privat namn för tunneladressen hos en VPN-klient är ett annat problem med ett annat svar: det hör hemma i privat DNS och behöver inte alls någon publik upptäcktstjänst. Att blanda de två kraven är hur en fungerande konfiguration börjar publicera en adress som ingen bett om.

Gränssnittsadresser behöver också tolkning. En laptopadress bakom en hemrouter är inte den publika WAN-adressen, och till och med routerns WAN-adress kan ligga bakom carrier-grade NAT, där publicering inte kan ge inkommande nåbarhet.

Återskapa värdet innan du ändrar något

Observera de två vägarna var för sig. Med tunneln uppe rapporterar en sond utgången; med tunneln nere, eller med sonden bunden till det fysiska gränssnittet, rapporterar den hemadressen: curl --interface eth0 https://ifconfig.me. Om de två svaren skiljer sig har du återskapat felet utan att röra uppdateraren.

Kör sedan klienten i ett läge som kontrollerar konfigurationen utan att utföra en uppdatering, till exempel ddclient -verbose -noexec, och läs vilken upptäcktsmetod den valde. Den utförliga utskriften namnger metoden och värdet den fick, och det är det faktum du behöver innan du redigerar något.

Rikta upptäckten mot den valda vägen

Om namnet ska publicera hemma-WAN-adressen måste upptäckten observera just den adressen. Tre alternativ fungerar, i grov prioritetsordning: låt routern publicera via sin egen stödda uppdaterare; använd ddclients routerstatus-upptäckt mot en sida som routern faktiskt betjänar; eller behåll en webbsond men bind den till det fysiska gränssnittet så att den går utanför tunneln.

För routerstatus-vägen använder nyare ddclient-versioner optionsfamiljen usev4 och fwv4, med ett valfritt överhoppningsmönster för den omgivande sidtexten. Kontrollera README för din installerade version, eftersom äldre versioner skriver samma idé med use och fw, och ett optionsnamn kopierat från fel version misslyckas vid start.

Om du behåller webbupptäckten, kom ihåg att routning av sonden och routning av uppdateringens API-anrop är separata beslut. Uppdateringsanropet levererar posten; sonden avgör vilket värde som levereras.

Håll hemligheter och versioner i ordning

Routeruppgifter och leverantörstoken hör hemma i en skyddad konfigurationsfil, inte på en kommandorad som hamnar i shell-historiken. Utförliga spår kan innehålla båda, så redigera dem innan du klistrar in dem i ett ärende. En upptäcktsmetod som kräver skrapning av en autentiserad routersida kräver också att du håller de uppgifterna fungerande genom firmwareuppdateringar. Förvara dem med samma omsorg som leverantörstokenet.

ddclient README dokumenterar upptäcktsmetoderna och deras optionsnamn. Blanda inte IPv4- och IPv6-resultat i en post, och anta inte att ett alternativ som finns i en version finns i en annan.

Verifiera värdet och sedan nåbarheten

Jämför den föreslagna adressen med den avsedda ändpunkten innan du tillåter en liveuppdatering, kontrollera sedan auktoritativ DNS efter en godkänd uppdatering och räkna med resolver-cachar. En låg TTL förkortar väntetiden; den gör inte ett felaktigt värde rätt.

Först när posten är korrekt bör du testa den inkommande tjänsten från ett oberoende nätverk, med den nödvändiga brandväggen och vidarebefordran redan godkända. En korrekt A-post bevisar inte en nåbar tjänst, och en statisk VPN-lease kan förenkla privat namngivning utan att reparera ett publikt värdnamn som pekar på fel WAN.