ddclient publikon daljen e VPN-së: rregullo burimin e zbulimit

Emri juaj DNS tani zgjidhet në një adresë të një ofruesi VPN, dhe regjistri i përditësimit duket plotësisht i shëndetshëm. Ky kombinim është normal. Një sondë zbulimi e bazuar në web pyet një shërbim të jashtëm çfarë burimi sheh, dhe kur kërkesa del përmes një VPN me tunel të plotë, përgjigja është dalja e VPN-së dhe jo adresa juaj WAN e shtëpisë. Përditësuesi bëri punën e tij; puna ishte e drejtuar nga një vëzhgim i gabuar.

Konfirmoni çfarë duhet të arrijë emri

Një emër publik për një shërbim shtëpiak hyrës ka nevojë për një adresë përmes së cilës lidhjet hyrëse të miratuara mund të arrijnë atë shërbim. Publikimi i një daljeje të përbashkët të ofruesit nuk organizon atje përcjellje hyrëse, dhe asnjë konfigurim DNS nuk e krijon atë përcjellje. Vendoseni këtë përpara se të prekni përditësuesin, sepse përcakton cila adresë është e saktë.

Një emër privat për adresën e tunelit të një klienti VPN është një problem tjetër me një përgjigje tjetër: i përket DNS-së private dhe nuk ka fare nevojë për një shërbim publik zbulimi. Përzierja e dy kërkesave është mënyra se si një konfigurim funksional fillon të publikojë një adresë që askush nuk e kërkoi.

Adresat e ndërfaqes gjithashtu kërkojnë interpretim. Adresa e një laptopi pas një routeri shtëpiak nuk është adresa publike WAN, dhe edhe adresa WAN e routerit mund të jetë pas NAT të operatorit, ku publikimi i saj nuk mund të prodhojë aksesueshmëri hyrëse.

Riprodhoni vlerën përpara se të ndryshoni ndonjë gjë

Vëzhgoni të dy rrugët veçmas. Me tunelin lart, një sondë raporton daljen; me tunelin poshtë, ose me sondën të lidhur me ndërfaqen fizike, ajo raporton adresën e shtëpisë: curl --interface eth0 https://ifconfig.me. Nëse këto dy përgjigje ndryshojnë, e keni riprodhuar defektin pa prekur përditësuesin.

Pastaj ekzekutoni klientin në një mënyrë që kontrollon konfigurimin pa kryer një përditësim, për shembull ddclient -verbose -noexec, dhe lexoni cilën metodë zbulimi zgjodhi. Dalja e detajuar emërton metodën dhe vlerën e marrë, dhe ky është fakti që ju nevojitet përpara çdo redaktimi.

Drejtojeni zbulimin në rrugën e zgjedhur

Nëse emri duhet të publikojë adresën WAN të shtëpisë, zbulimi duhet të vëzhgojë pikërisht atë adresë. Funksionojnë tre opsione, sipas një renditjeje të përafërt preferencë: lëreni routerin të publikojë përmes përditësuesit të vetëm të mbështetur; përdorni zbulimin e statusit të routerit të ddclient kundër një faqeje që routeri vërtet shërben; ose mbani një sondë web, por lidheni me ndërfaqen fizike që të dalë jashtë tunelit.

Për rrugën e statusit të routerit, versionet më të reja të ddclient përdorin familjen e opsioneve usev4 dhe fwv4, me një model anashkalimi opsional për tekstin përreth faqes. Kontrolloni README për versionin e instaluar, sepse versionet e vjetra shkruajnë të njëjtën ide me use dhe fw, dhe një emër opsioni i kopjuar nga versioni i gabuar dështon në nisje.

Nëse mbani zbulimin web, mbani mend se rrugëzimi i sondës dhe rrugëzimi i thirrjes API të përditësimit janë vendime të veçanta. Thirrja e përditësimit dorëzon regjistrin; sonda vendos vlerën që do të dorëzohet.

Mbajini sekretet dhe versionet në rregull

Kredencialet e routerit dhe tokenët e ofruesit i përkasin një skedari konfigurimi të mbrojtur, jo një rreshti komande që përfundon në historikun e shell-it. Gjurmët e detajuara mund t'i përmbajnë të dyja, kështu që redaktojini përpara se t'i ngjitni në një tiketë. Një metodë zbulimi që kërkon gërvishtjen e një faqeje të vërtetuar të routerit kërkon gjithashtu që t'i mbani ato kredenciale funksionale gjatë përditësimeve të firmware. Ruajini me të njëjtin kujdes si tokeni i ofruesit.

ddclient README dokumenton qasjet e zbulimit dhe emrat e opsioneve të tyre. Mos i përzini rezultatet IPv4 dhe IPv6 në një regjistër, dhe mos supozoni se një opsion i pranishëm në një version ekziston në një tjetër.

Verifikoni vlerën, pastaj aksesueshmërinë

Krahasoni adresën e propozuar me pikën fundore të synuar përpara se të lejoni një përditësim të drejtpërdrejtë, pastaj kontrolloni DNS autoritativ pas një përditësimi të autorizuar dhe merrni parasysh memoriet e zgjidhësve. Një TTL i ulët shkurton pritjen; nuk e bën të saktë një vlerë të gabuar.

Vetëm pasi regjistri të jetë i saktë duhet të provoni shërbimin hyrës nga një rrjet i pavarur, me murin e zjarrit dhe përcjelljen e nevojshme të miratuara tashmë. Një regjistër A i saktë nuk dëshmon një shërbim të arritshëm, dhe një qira statike VPN mund të thjeshtojë emërtimin privat pa riparuar një emër hosti publik që tregon në WAN-in e gabuar.