ddclient publiceert de VPN-uitgang: repareer de ontdekkingsbron

Je DNS-naam verwijst nu naar een adres van een VPN-provider, en het updatelog ziet er volkomen gezond uit. Die combinatie is normaal. Een webgebaseerde ontdekkingsprobe vraagt een externe dienst welke bron hij ziet, en wanneer het verzoek via een volledige tunnel-VPN naar buiten gaat, is het antwoord de VPN-uitgang en niet je thuis-WAN-adres. De updater deed zijn werk; het werk was op de verkeerde waarneming gericht.

Bevestig wat de naam moet bereiken

Een openbare naam voor een inkomende thuisdienst heeft een adres nodig waarop goedgekeurde inkomende verbindingen die dienst kunnen bereiken. Het publiceren van een gedeelde provideruitgang regelt daar geen inkomende doorsturing, en geen enkele DNS-configuratie creëert die doorsturing. Beslis dit voordat je de updater aanraakt, want het bepaalt welk adres juist is.

Een privénaam voor het tunneladres van een VPN-client is een ander probleem met een ander antwoord: die hoort in privé-DNS en heeft helemaal geen openbare ontdekkingsdienst nodig. De twee eisen vermengen is hoe een werkende configuratie een adres begint te publiceren waar niemand om vroeg.

Interfaceadressen vragen ook om interpretatie. Het adres van een laptop achter een thuisrouter is niet het openbare WAN-adres, en zelfs het WAN-adres van de router kan achter carrier-grade NAT zitten, waar publicatie geen inkomende bereikbaarheid kan opleveren.

Reproduceer de waarde voordat je iets verandert

Observeer de twee paden afzonderlijk. Met de tunnel omhoog rapporteert een probe de uitgang; met de tunnel omlaag, of met de probe aan de fysieke interface gebonden, rapporteert hij het thuisadres: curl --interface eth0 https://ifconfig.me. Als die twee antwoorden verschillen, heb je de fout gereproduceerd zonder de updater aan te raken.

Start daarna de client in een modus die de configuratie controleert zonder een update uit te voeren, bijvoorbeeld ddclient -verbose -noexec, en lees welke ontdekkingsmethode hij koos. De uitgebreide uitvoer noemt de methode en de verkregen waarde, en dat is het feit dat je nodig hebt voordat je iets bewerkt.

Richt de ontdekking op het gekozen pad

Als de naam het thuis-WAN-adres moet publiceren, moet de ontdekking dat adres observeren. Drie opties werken, in grove volgorde van voorkeur: laat de router publiceren via zijn eigen ondersteunde updater; gebruik de routerstatus-ontdekking van ddclient tegen een pagina die de router echt serveert; of houd een webprobe maar bind die aan de fysieke interface zodat hij buiten de tunnel uitgaat.

Voor het routerstatus-pad gebruiken nieuwere ddclient-versies de optiefamilie usev4 en fwv4, met een optioneel overslaanpatroon voor de omliggende paginatekst. Controleer de README voor je geïnstalleerde versie, want oudere versies schrijven hetzelfde idee met use en fw, en een optienaam die uit de verkeerde versie is gekopieerd, mislukt bij het starten.

Houd je webontdekking, bedenk dan dat het routeren van de probe en het routeren van de update-API-aanroep aparte beslissingen zijn. De update-aanroep levert het record; de probe bepaalt de waarde die wordt geleverd.

Houd geheimen en versies op orde

Routerreferenties en provider-tokens horen in een beveiligd configuratiebestand, niet op een commandoregel die in de shell-geschiedenis belandt. Uitgebreide traces kunnen beide bevatten, dus redigeer ze voordat je ze in een ticket plakt. Een ontdekkingsmethode die een geauthenticeerde routerpagina moet scrapen, vereist ook dat je die referentie over firmware-updates heen laat werken. Bewaar ze met dezelfde zorg als het provider-token.

De ddclient README documenteert de ontdekkingsbenaderingen en hun optienamen. Meng geen IPv4- en IPv6-resultaten in één record, en ga er niet van uit dat een optie uit de ene versie in een andere bestaat.

Verifieer de waarde en dan de bereikbaarheid

Vergelijk het voorgestelde adres met het beoogde eindpunt voordat je een live-update toestaat, controleer daarna na één geautoriseerde update de gezaghebbende DNS en reken op resolver-caches. Een lage TTL verkort het wachten; hij maakt een verkeerde waarde niet juist.

Pas als het record correct is, zou je de inkomende dienst moeten testen vanaf een onafhankelijk netwerk, met de vereiste firewall en doorsturing al goedgekeurd. Een correct A-record bewijst geen bereikbare dienst, en een statische VPN-lease kan privénaamgeving vereenvoudigen zonder een openbare hostnaam te repareren die naar de verkeerde WAN wijst.