ddclient publikigas la VPN-eliron: ripari la malkovran fonton

Via DNS-nomo nun solviĝas al adreso de VPN-provizanto, kaj la ĝisdatiga protokolo aspektas tute sana. Tiu kombino estas normala. Rete bazita malkovra provo demandas al ekstera servo, kiun fonton ĝi vidas, kaj kiam la peto eliras tra plen-tunela VPN, la respondo estas la VPN-eliro anstataŭ via hejma WAN-adreso. La ĝisdatigilo faris sian taskon; la tasko celis malĝustan observadon.

Konfirmu, kion la nomo devas atingi

Publika nomo por envena hejma servo bezonas adreson, per kiu aprobitaj envenaj konektoj povas atingi tiun servon. Publikigi komunan eliron de provizanto ne aranĝas envenan plusendadon tie, kaj neniu kvanto da DNS-agordo kreas tiun plusendadon. Decidu tion antaŭ ol tuŝi la ĝisdatigilon, ĉar ĝi determinas, kiu adreso estas ĝusta.

Privata nomo por tunela adreso de VPN-kliento estas alia problemo kun alia respondo: ĝi apartenas al privata DNS, kaj ĝi tute ne bezonas publikan malkovran servon. Miksi la du postulojn estas kiel funkcianta agordo komencas publikigi adreson, kiun neniu petis.

Interfacaj adresoj ankaŭ bezonas interpreton. La adreso de tekkomputilo malantaŭ hejma enkursigilo ne estas la publika WAN-adreso, kaj eĉ la WAN-adreso de la enkursigilo povas sidi malantaŭ ĉelĉena NAT, kie publikigi ĝin ne povas produkti envenan atingeblon.

Reproduktu la valoron antaŭ ol ŝanĝi ion ajn

Observu la du vojojn aparte. Kun la tunelo supren, provo raportas la eliron; kun la tunelo malsupren, aŭ kun la provo ligita al la fizika interfaco, ĝi raportas la hejman adreson: curl --interface eth0 https://ifconfig.me. Se tiuj du respondoj diferencas, vi reproduktis la difekton sen tuŝi la ĝisdatigilon.

Poste rulu la klienton en reĝimo, kiu kontrolas la agordon sen plenumi ĝisdatigon, ekzemple ddclient -verbose -noexec, kaj legu, kiun malkovran metodon ĝi elektis. La detala eligo nomas la metodon kaj la akiritan valoron, kaj tiu estas la fakto, kiun vi bezonas antaŭ ol redakti ion ajn.

Direktu la malkovron al la elektita vojo

Se la nomo devas publikigi la hejman WAN-adreson, la malkovro devas observi ĝuste tiun adreson. Tri ebloj funkcias, laŭ proksimuma ordo de prefero: lasu la enkursigilon publikigi per sia propra subtenata ĝisdatigilo; uzu la enkursigilan statusan malkovron de ddclient kontraŭ paĝo, kiun la enkursigilo efektive servas; aŭ tenu retprovon sed ligi ĝin al la fizika interfaco, por ke ĝi eliru ekster la tunelo.

Por la vojo de enkursigila statuso, pli novaj eldonoj de ddclient uzas la opcian familion usev4 kaj fwv4, kun laŭvola preterpasŝablono por la ĉirkaŭa paĝa teksto. Kontrolu la README por via instalita versio, ĉar pli malnovaj eldonoj skribas la saman ideon per use kaj fw, kaj opcia nomo kopiita el la malĝusta eldono fiaskas ĉe starto.

Se vi tenas retan malkovron, memoru, ke enkursigo de la provo kaj enkursigo de la ĝisdatiga API-alvoko estas apartaj decidoj. La ĝisdatiga alvoko transdonas la rikordon; la provo decidas la valoron, kiu estos transdonita.

Tenu sekretojn kaj versiojn en ordo

Enkursigilaj akreditaĵoj kaj provizantaj ĵetonoj apartenas al protektita agorda dosiero, ne al komanda linio, kiu finiĝas en la ŝela historio. Detalaj spuroj povas enteni ambaŭ, do redaktu ilin antaŭ ol alglui en bileton. Malkovra metodo, kiu postulas skrapi aŭtentigitan enkursigilan paĝon, ankaŭ postulas, ke vi tenu tiun akreditaĵon funkcianta tra firmvaraĵaj ĝisdatigoj. Konservu ĝin kun la sama zorgo kiel la provizantan ĵetonon.

La ddclient README dokumentas la malkovrajn alirojn kaj iliajn opciajn nomojn. Ne miksu IPv4 kaj IPv6 rezultojn en unu rikordo, kaj ne supozu, ke opcio ĉeestanta en unu eldono ekzistas en alia.

Kontrolu la valoron, poste la atingeblon

Komparu la proponitan adreson kun la celata finpunkto antaŭ ol permesi vivan ĝisdatigon, poste kontrolu aŭtoritatan DNS post unu rajtigita ĝisdatigo kaj kalkulu por solvilaj kaŝmemoroj. Malalta TTL mallongigas la atendojn; ĝi ne faras malĝustan valoron ĝusta.

Nur post kiam la rikordo estas ĝusta, vi testu la envenan servon el sendependa reto, kun la bezonata fajroŝirmilo kaj plusendado jam aprobitaj. Ĝusta A-rikordo ne pruvas atingeblan servon, kaj statika VPN-luo povas simpligi privatan nomadon sen ripari publikan gastigantan nomon, kiu montras al la malĝusta WAN.