ddclient inachapisha kitokeo cha VPN: rekebisha chanzo cha ugunduzi

Jina lako la DNS sasa linatatuliwa hadi anwani ya mtoa huduma wa VPN, na kumbukumbu ya masasisho inaonekana yenye afya kabisa. Mchanganyiko huo ni wa kawaida. Kichunguzi cha ugunduzi kinachotegemea wavuti kinauliza huduma ya nje ni chanzo gani inachokiona, na ombi linapotoka kupitia VPN ya handaki kamili, jibu huwa kitokeo cha VPN na si anwani yako ya WAN ya nyumbani. Kisasisishi kilifanya kazi yake; kazi ilielekezwa kwenye uchunguzi usiofaa.

Thibitisha jina linapaswa kufikia nini

Jina la umma kwa huduma ya nyumbani inayoingia linahitaji anwani ambayo kupitia kwayo miunganisho inayoingia iliyoidhinishwa inaweza kufikia huduma hiyo. Kuchapisha kitokeo cha mtoa huduma kilichoshirikiwa hakuandaa upelekaji wa ndani huko, na hakuna usanidi wa DNS unaounda upelekaji huo. Amua hili kabla ya kugusa kisasisishi, kwa sababu huamua anwani ipi ni sahihi.

Jina la faragha kwa anwani ya handaki ya mteja wa VPN ni tatizo lingine lenye jibu lingine: ni la DNS ya faragha, na halihitaji kabisa huduma ya ugunduzi ya umma. Kuchanganya mahitaji mawili ndiyo njia ambayo usanidi unaofanya kazi huanza kuchapisha anwani ambayo hakuna aliy eiomba.

Anwani za kiolesura pia zinahitaji tafsiri. Anwani ya kompyuta ya mkononi nyuma ya ruta ya nyumbani si anwani ya WAN ya umma, na hata anwani ya WAN ya ruta inaweza kuwa nyuma ya NAT ya mtoa huduma, ambapo kuichapisha hakuwezi kuleta ufikivu wa ndani.

Zalisha tena thamani kabla ya kubadilisha chochote

Angalia njia mbili tofauti. Handaki ikiwa juu, kichunguzi huripoti kitokeo; handaki ikiwa chini, au kichunguzi kimefungwa kwenye kiolesura cha kimwili, huripoti anwani ya nyumbani: curl --interface eth0 https://ifconfig.me. Ikiwa majibu hayo mawili ni tofauti, umezalisha tena hitilafu bila kugusa kisasisishi.

Kisha endesha mteja katika hali inayokagua usanidi bila kufanya sasisho, kwa mfano ddclient -verbose -noexec, na soma ni njia ipi ya ugunduzi aliyochagua. Matokeo ya kina hutaja njia na thamani iliyopatikana, na hiyo ndiyo hoja unayohitaji kabla ya kuhariri chochote.

Elekeza ugunduzi kwenye njia iliyochaguliwa

Ikiwa jina linapaswa kuchapisha anwani ya WAN ya nyumbani, ugunduzi lazima uangalie anwani hiyo hiyo. Njia tatu zinafanya kazi, kwa mpangilio wa upendeleo unaokaribia: acha ruta ichapishe kupitia kisasisishi chake kinachotumika; tumia ugunduzi wa hali ya ruta wa ddclient dhidi ya ukurasa ambao ruta inatumikia kwa kweli; au weka kichunguzi cha wavuti lakini kifunge kwenye kiolesura cha kimwili ili kitoke nje ya handaki.

Kwa njia ya hali ya ruta, matoleo mapya ya ddclient hutumia familia ya chaguo usev4 na fwv4, pamoja na muundo wa kuruka wa hiari kwa maandishi ya ukurasa yanayozunguka. Angalia README ya toleo lako lililosakinishwa, kwa sababu matoleo ya zamani huandika wazo hilo hilo kwa use na fw, na jina la chaguo lililonakiliwa kutoka toleo lisilo sahihi hushindwa wakati wa kuanza.

Ikiwa utabakiza ugunduzi wa wavuti, kumbuka kuwa uelekezaji wa kichunguzi na uelekezaji wa mwito wa API ya sasisho ni maamuzi tofauti. Mwito wa sasisho huwasilisha rekodi; kichunguzi huamua thamani itakayowasilishwa.

Weka siri na matoleo katika mpangilio

Vitambulisho vya ruta na tokeni za mtoa huduma vinapaswa kuwa katika faili ya usanidi iliyolindwa, si kwenye mstari wa amri unaoishia katika historia ya shell. Alama za kina zinaweza kuwa na vyote viwili, kwa hiyo zifute kabla ya kubandika kwenye tikiti. Njia ya ugunduzi inayohitaji kukwangua ukurasa wa ruta uliothibitishwa pia inahitaji wewe kuweka vitambulisho hivyo vikifanya kazi katika masasisho ya firmware. Vihifadhi kwa uangalifu sawa na tokeni ya mtoa huduma.

ddclient README inaeleza mbinu za ugunduzi na majina ya chaguo zao. Usichanganye matokeo ya IPv4 na IPv6 katika rekodi moja, na usidhani chaguo lililopo katika toleo moja lipo katika lingine.

Thibitisha thamani, kisha ufikivu

Linganisha anwani iliyopendekezwa na ncha ya mwisho inayokusudiwa kabla ya kuruhusu sasisho la moja kwa moja, kisha angalia DNS yenye mamlaka baada ya sasisho moja lililoidhinishwa na uzingatie akiba za vitatuzi. TTL ya chini hufupisha kusubiri; haifanyi thamani isiyo sahihi kuwa sahihi.

Ni baada ya rekodi kuwa sahihi tu unapaswa kujaribu huduma inayoingia kutoka mtandao huru, huku firewall na upelekaji vinavyohitajika vikiwa vimeidhinishwa tayari. Rekodi sahihi ya A haithibitishi huduma inayofikika, na ukodishaji thabiti wa VPN unaweza kurahisisha uambishaji wa faragha bila kurekebisha jina la mwenyeji la umma linaloelekeza kwenye WAN isiyo sahihi.