ddclient publiserer VPN-utgangen: rett oppdagingskjelda

DNS-namnet ditt peikar no på ei adresse hos ein VPN-leverandør, og oppdateringsloggen ser heilt sunn ut. Den kombinasjonen er normal. Ei nettbodydd oppdagingssonde spør ein ekstern teneste kva kjelde ho ser, og når førespurnaden går ut gjennom ein full tunnel-VPN, er svaret VPN-utgangen og ikkje heime-WAN-adressa di. Oppdateraren gjorde jobben sin; jobben var retta mot ei feil observasjon.

Stadfest kva namnet skal nå

Eit offentleg namn for ei innkomande heimeteneste treng ei adresse som godkjende innkomande tilkoplingar kan nå tenesta gjennom. Å publisere ein delt leverandørutgang ordnar ikkje videresending inn dit, og inga mengd DNS-konfigurasjon skaper den videresendinga. Avgjer dette før du rører oppdateraren, fordi det avgjer kva adresse som er rett.

Eit privat namn for tunneladressa til ein VPN-klient er eit anna problem med eit anna svar: det høyrer til i privat DNS, og det treng slett ikkje ein offentleg oppdagingsteneste. Å blande dei to krava er måten ein fungerande konfigurasjon byrjar å publisere ei adresse ingen har bede om.

Grensesnittadresser treng òg tolking. Adressa til ein berbar PC bak ein heimeruter er ikkje den offentlege WAN-adressa, og sjølv WAN-adressa til ruteren kan liggje bak carrier-grade NAT, der publisering ikkje kan gje innkomande tilgjenge.

Gjenskap verdien før du endrar noko

Observer dei to vegane kvar for seg. Med tunnelen oppe rapporterer sonden utgangen; med tunnelen nede, eller med sonden bunden til det fysiske grensesnittet, rapporterer ho heimeadressa: curl --interface eth0 https://ifconfig.me. Viss dei to svara er ulike, har du gjenskapt feilen utan å røre oppdateraren.

Køyr deretter klienten i ein modus som kontrollerer konfigurasjonen utan å utføre ein oppdatering, til dømes ddclient -verbose -noexec, og les kva oppdagingsmetode han valde. Den detaljerte utskrifta nemner metoden og verdien han fekk, og det er det faktumet du treng før du redigerer noko.

Rett oppdaginga mot den valde vegen

Viss namnet skal publisere heime-WAN-adressa, må oppdaginga observere nettopp den adressa. Tre alternativ fungerer, i grov prioritert rekkjefølgje: la ruteren publisere gjennom sin eigen støtta oppdaterar; bruk ruterstatus-oppdaginga til ddclient mot ei side ruteren faktisk tener; eller hald ei nettsonde, men bind ho til det fysiske grensesnittet slik at ho går utanom tunnelen.

For ruterstatus-vegen brukar nyare ddclient-utgåver opsjonsfamilien usev4 og fwv4, med eit valfritt hopp over-mønster for sideteksten rundt. Sjekk README for den installerte versjonen din, fordi eldre utgåver skriv same idé med use og fw, og eit opsjonsnamn kopiert frå feil utgåve feilar ved oppstart.

Held du nettoppdaging, hugs at ruting av sonden og ruting av oppdaterings-API-kallet er separate avgjerder. Oppdateringskallet leverer posten; sonden avgjer verdien som blir levert.

Hald hemmelege og versjonar i orden

Ruterlegitimasjon og leverandørtoken høyrer i ei verna konfigurasjonsfil, ikkje på ei kommandoline som endar i shell-historia. Detaljerte spor kan innehalde begge, så rediger dei før du limer dei inn i ei sak. Ein oppdagingsmetode som krev skraping av ei autentisert ruterseide, krev òg at du held den legitmasjonen i drift gjennom fastvareoppdateringar. Oppbevar han med same omhug som leverandørtokenet.

ddclient README dokumenterer oppdagingstilnærmingane og opsjonsnamna deira. Ikkje blande IPv4- og IPv6-resultat i ein post, og ikkje gå ut frå at ein opsjon som finst i ei utgåve, finst i ei anna.

Stadfest verdien, deretter tilgjenge

Samanlikn den føreslåtte adressa med det tiltenkte endepunktet før du tillèt ein direkteoppdatering, sjekk deretter autoritativ DNS etter éin godkjend oppdatering og ta høgde for resolver-buffer. Ein låg TTL kortar ned ventetida; han gjer ikkje ein feil verdi rett.

Først når posten er korrekt, bør du teste den innkomande tenesta frå eit uavhengig nettverk, med den naudsynte brannmuren og videresendinga allereie godkjend. Ein korrekt A-post bevisar ikkje ei tilgjengeleg teneste, og ein statisk VPN-leige kan forenkle privat namngjeving utan å reparere eit offentleg vertsnamn som peikar på feil WAN.