ddclient publiserer VPN-utgangen: rett oppdagelseskilden

DNS-navnet ditt peker nå på en adresse hos en VPN-leverandør, og oppdateringsloggen ser helt sunn ut. Den kombinasjonen er normal. En webbasert oppdagelsessonde spør en ekstern tjeneste hvilken kilde den ser, og når forespørselen går ut gjennom en full tunnel-VPN, er svaret VPN-utgangen og ikke din hjemme-WAN-adresse. Oppdatereren gjorde jobben sin; jobben var rettet mot en feil observasjon.

Bekreft hva navnet skal nå

Et offentlig navn for en innkommende hjemmetjeneste trenger en adresse som godkjente innkommende tilkoblinger kan nå den tjenesten gjennom. Å publisere en delt leverandørutgang ordner ikke videresending inn dit, og ingen mengde DNS-konfigurasjon skaper den videresendingen. Bestem dette før du rører oppdatereren, fordi det avgjør hvilken adresse som er riktig.

Et privat navn for tunneladressen til en VPN-klient er et annet problem med et annet svar: det hører hjemme i privat DNS, og det trenger slett ikke en offentlig oppdagelsestjeneste. Å blande de to kravene er måten en fungerende konfigurasjon begynner å publisere en adresse ingen har bedt om.

Grensesnittadresser trenger også tolkning. En laptopadresse bak en hjemmeruter er ikke den offentlige WAN-adressen, og selv ruterens WAN-adresse kan ligge bak carrier-grade NAT, der publisering ikke kan gi innkommende tilgjengelighet.

Gjenskap verdien før du endrer noe

Observer de to veiene hver for seg. Med tunnelen oppe rapporterer en sonde utgangen; med tunnelen nede, eller med sonden bundet til det fysiske grensesnittet, rapporterer den hjemadressen: curl --interface eth0 https://ifconfig.me. Hvis de to svarene er ulike, har du gjenskapt feilen uten å røre oppdatereren.

Kjør deretter klienten i en modus som kontrollerer konfigurasjonen uten å utføre en oppdatering, for eksempel ddclient -verbose -noexec, og les hvilken oppdagelsesmetode den valgte. Den detaljerte utskriften navngir metoden og verdien den fikk, og det er det faktumet du trenger før du redigerer noe.

Rett oppdagelsen mot den valgte veien

Hvis navnet skal publisere hjemme-WAN-adressen, må oppdagelsen observere nettopp den adressen. Tre alternativer fungerer, i grov prioritert rekkefølge: la ruteren publisere gjennom sin egen støttede oppdaterer; bruk ddclients ruterstatus-oppdagelse mot en side ruteren faktisk betjener; eller behold en websonde, men bind den til det fysiske grensesnittet slik at den går utenom tunnelen.

For ruterstatus-veien bruker nyere ddclient-utgivelser opsjonsfamilien usev4 og fwv4, med et valgfritt hopp over-mønster for sideteksten rundt. Sjekk README for den installerte versjonen din, fordi eldre utgivelser skriver samme idé med use og fw, og et opsjonsnavn kopiert fra feil utgivelse feiler ved oppstart.

Beholder du weboppdagelse, husk at ruting av sonden og ruting av oppdaterings-API-kallet er separate beslutninger. Oppdateringskallet leverer posten; sonden avgjør verdien som leveres.

Hold hemmeligheter og versjoner i orden

Ruterlegitimasjon og leverandørtokener hører hjemme i en beskyttet konfigurasjonsfil, ikke på en kommandolinje som ender i shell-historikken. Detaljerte spor kan inneholde begge, så rediger dem før du limer dem inn i en sak. En oppdagelsesmetode som krever skraping av en autentisert ruterseide krever også at du holder den legitimasjonen i drift gjennom fastvareoppdateringer. Oppbevar den med samme omhu som leverandørtokenet.

ddclient README dokumenterer oppdagelsestilnærmingene og opsjonsnavnene deres. Ikke bland IPv4- og IPv6-resultater i én post, og ikke anta at en opsjon som finnes i én utgivelse, finnes i en annen.

Verifiser verdien, deretter tilgjengeligheten

Sammenlign den foreslåtte adressen med det tiltenkte endepunktet før du tillater en direktesendt oppdatering, sjekk deretter autoritativ DNS etter én godkjent oppdatering og ta høyde for resolver-buffer. En lav TTL forkorter ventetiden; den gjør ikke en feil verdi riktig.

Først når posten er korrekt, bør du teste den innkommende tjenesten fra et uavhengig nettverk, med den nødvendige brannmuren og videresendingen allerede godkjent. En korrekt A-post beviser ikke en tilgjengelig tjeneste, og en statisk VPN-lease kan forenkle privat navngiving uten å reparere et offentlig vertsnavn som peker på feil WAN.