Kial privata finpunkto ankoraŭ respondas per publika adreso

La tekokomputilo konektiĝas, la tunelo raportas sin aktiva, kaj la stokada konto daŭre rifuzas ĉiun peton. La privata finpunkto ekzistas, la vojo al ĝia subreto ekzistas, kaj la nomo aŭ respondas per publika adreso aŭ malsukcesas solviĝi. Nenio misas ĉe la tunelo: la kliento neniam sciis, kiu servilo devus respondi pri tiu nomo. Sekvu la peton eksteren kaj la manko fariĝos evidenta.

Komencu ĉe la solvilo de la kliento

Demandu la klienton, kiun servilon ĝi demandas dum la tunelo estas aktiva. Profilo de punkto-al-ejo liveras tiun adreson, kaj profilo, kiu liveras nenion, lasas la operaciumon fali reen al la adaptilaj defaŭltoj.

Publikaj solviloj havas neniun vidon de privata zono, do ili respondas el la interreto, kio estas ekzakte ilia tasko. La unua kontrolo do estas la uzata solvila adreso, ne la tunelo kaj ne la finpunkto.

Legu, kio efektive estas la respondo

Solvu la servan nomon kaj legu la adreson, kiu revenas. Publika respondo signifas, ke la peto atingis servilon, kiu ne povas vidi la zonon. Neniu respondo signifas, ke la nomo ekzistas nur private kaj nenio atingebla de la kliento tenas ĝin.

Tiuj du rezultoj kaŭzas similajn aplikaĵajn erarojn kaj apartenas al malsamaj posedantoj. Unu estas problemo pri elekto de solvilo, la alia estas mankanta zona ligilo.

Enskribo en hosts pruvas la vojon, poste mensogas

Meti la finpunktan adreson en la lokan dosieron hosts estas la plej rapida maniero pruvi, ke la tunelo kaj la fajroŝirmilo de la servo jam funkcias. Se la peto sukcesas kun tiu enskribo, nur la nomosolvado estas difektita. Ĝi ankaŭ estas ŝanĝo por unu maŝino, kiu kovras precize unu nomon.

Ĝi ne helpas la duan konton, la duan finpunkton aŭ kolegon, kaj ĝi rompiĝas sen averto, kiam la finpunkto estas rekreita ĉe nova adreso.

Pli malbone, ĝi igas vian maŝinon konduti alie ol ĉiuj aliaj, kaj tiel solvila difekto postvivas semajnon da esplorado. Uzu ĝin por konfirmi la vojon, poste forigu ĝin kaj riparu la kaŭzon.

Ligu la zonon kaj disdonu solvilon

Du kondiĉoj devas validi samtempe. La privata zono devas esti ligita al la virtuala reto, kie loĝas la finpunkto, kaj la kliento devas sendi siajn petojn al servilo, kiu povas legi tiun zonon. Enira finpunkto de DNS Private Resolver provizas tian adreson ene de la reto kaj respondas al petoj alvenantaj tra la tunelo. Metu tiun adreson en la VPN-profilo kaj aldonu la privatan sufikson, kiun la kliento apliku.

Jam ekzistanta loka solvilo povas atingi la saman rezulton per kondiĉa plusendilo direktita al la zono.

Retaj reguloj ĉe la solvilo valoras same multe kiel enkursigado. Se la enira regulo ekskludas la VPN-klientan amplekson, petoj tempolimas anstataŭ redoni malĝustan respondon. Ĝuste tiu tempolimo resendas homojn al enkursiga tabelo, kie nenio misas.

Kontrolu nomon, pordon kaj identecon laŭ ordo

Laboru laŭ ordo: solvu la nomon, konfirmu ke la respondo estas privata, malfermu la pordon, poste faru aŭtentikigitan peton. Ĉiu etapo havas sian propran posedanton kaj sian propran malsukcesan subskribon.

Privata respondo sekvata de tempolimo indikas vojon aŭ fajroŝirmilon. Publika respondo indikas la solvilon. Kompletigita konekto, kiu redonas identecan eraron, apartenas al la servo.

Ankoraŭ unu malsukceso apartenas al ĉi tiu listo. Fajroŝirmilo de servo, kiu permesas klientan adreson, ĉesas kongrui, kiam la baseno donas tiun adreson al alia sesio post rekonekto. Legu la vokantan adreson, kiun la servo registris, anstataŭ tiun, kiun la kliento kredas havi. La du malkongruas pli ofte, ol homoj atendas. La gvidilo pri Azure DNS Private Resolver kovras la zonan ligilon kaj la plusendan aranĝon.