Zakaj zasebna končna točka še vedno odgovarja z javnim naslovom

Prenosnik se poveže, tunel se javi kot aktiven, shrambni račun pa še vedno zavrne vsako zahtevo. Zasebna končna točka obstaja, pot do njene podomrežja obstaja, in ime bodisi odgovori z javnim naslovom bodisi se sploh ne razreši. S tunelom ni nič narobe: odjemalcu nikoli ni bilo povedano, kateri strežnik naj odgovarja za to ime. Sledite poizvedbi navzven in vrzel postane očitna.

Začnite pri razreševalniku odjemalca

Vprašajte odjemalca, kateri strežnik poizveduje, medtem ko je tunel aktiven. Profil od točke do lokacije zagotovi ta naslov, profil, ki ne zagotovi ničesar, pa prepusti operacijskemu sistemu vrnitev na privzete vrednosti vmesnika.

Javni razreševalniki nimajo nobenega vpogleda v zasebno območje, zato odgovarjajo z interneta, kar je natanko njihovo delo. Prvo preverjanje je zato naslov uporabljenega razreševalnika, ne tunel in ne končna točka.

Preberite, kaj je odgovor v resnici

Razrešite ime storitve in preberite naslov, ki se vrne. Javen odgovor pomeni, da je poizvedba dosegla strežnik, ki območja ne vidi. Brez odgovora pomeni, da ime obstaja samo zasebno in da nič, kar odjemalec doseže, tega ne drži.

Ta dva izida povzročata podobne napake aplikacije in pripadata različnim lastnikom. Eden je težava z izbiro razreševalnika, drugi manjkajoča povezava območja.

Vnos v hosts dokaže pot in nato laže

Vnos naslova končne točke v lokalno datoteko hosts je najhitrejši način, da dokažete, da tunel in požarni zid storitve že delujeta. Če zahteva s tem vnosom uspe, je pokvarjeno samo razreševanje imen. To je tudi sprememba za en stroj, ki pokriva natanko eno ime.

Ne pomaga drugemu računu, drugi končni točki ali sodelavcu in se brez opozorila pokvari, ko se končna točka znova ustvari na novem naslovu.

Še huje, vaš stroj se obnaša drugače od vseh drugih in prav tako napaka razreševalnika preživi teden preiskave. Uporabite jo za potrditev poti, nato jo odstranite in odpravite vzrok.

Povežite območje in razdelite razreševalnik

Dva pogoja morata veljati hkrati. Zasebno območje mora biti povezano z virtualnim omrežjem, kjer končna točka živi, odjemalec pa mora pošiljati poizvedbe strežniku, ki to območje lahko bere. Vhodna končna točka DNS Private Resolver zagotavlja tak naslov znotraj omrežja in odgovarja na poizvedbe, ki prispejo skozi tunel. Vstavite ta naslov v profil VPN in dodajte zasebno pripono, ki jo mora odjemalec uporabiti.

Obstoječi lokalni razreševalnik lahko doseže enak rezultat prek pogojnega posredovalnika, usmerjenega na območje.

Omrežna pravila na razreševalniku štejejo toliko kot usmerjanje. Če vhodno pravilo izključuje obseg odjemalcev VPN, poizvedbe potečejo, namesto da bi vrnile napačen odgovor. Prav ta potek pošilja ljudi nazaj k tabeli poti, kjer ni nič narobe.

Preverite ime, vrata in identiteto po vrsti

Delajte po vrsti: razrešite ime, potrdite, da je odgovor zaseben, odprite vrata in nato izvedite overjeno zahtevo. Vsaka stopnja ima svojega lastnika in svoj podpis okvare.

Zaseben odgovor, ki mu sledi potek, kaže na pot ali požarni zid. Javen odgovor kaže na razreševalnik. Dokončana povezava, ki vrne napako identitete, pripada storitvi.

Na ta seznam spada še ena okvara. Požarni zid storitve, ki dovoli naslov odjemalca, se preneha ujemati, ko sklad po ponovni povezavi dodeli ta naslov drugi seji. Berite naslov klicatelja, ki ga je storitev zabeležila, ne tistega, za katerega odjemalec misli, da ga ima. Ta dva se pogosteje razhajata, kot ljudje pričakujejo. Smernice za Azure DNS Private Resolver pokrivajo povezavo območja in ureditev posredovanja.