Waarom ’n private eindpunt steeds met ’n publieke adres antwoord

Die skootrekenaar maak verbinding, die tonnel rapporteer dat hy op is, en die stoorkaart weier steeds elke versoek. Die private eindpunt bestaan, die roete na sy subnet bestaan, en die naam antwoord óf met ’n publieke adres óf dit los nie op nie. Niks is verkeerd met die tonnel nie: die kliënt is nooit meegedeel watter bediener vir daardie naam moet antwoord nie. Volg die navraag uitwaarts en die gaping word duidelik.

Begin by die kliënt se resolver

Vra die kliënt watter bediener hy navraag terwyl die tonnel op is. ’n Punt-tot-terrein-profiel verskaf daardie adres, en ’n profiel wat niks verskaf nie laat die bedryfstelsel terugval op die adapter-verstekke.

Publieke resolvers het geen sig op ’n private sone nie, dus antwoord hulle uit die internet, wat presies hul werk is. Die eerste kontrol is dus die resolver-adres in gebruik, nie die tonnel en nie die eindpunt nie.

Lees wat die antwoord werklik is

Los die diensnaam op en lees die adres wat terugkom. ’n Publieke antwoord beteken die navraag het ’n bediener bereik wat nie die sone kan sien nie. Geen antwoord beteken die naam bestaan slegs privaat en niks wat die kliënt kan bereik, hou dit nie.

Daardie twee uitkomste veroorsaak soortgelyke toepassingsfoute en behoort aan verskillende eienaars. Een is ’n resolver-keuseprobleem, die ander is ’n ontbrekende sone-koppeling.

’n Hosts-inskrywing bewys die pad, dan lieg dit

Om die eindpunt-adres in die plaaslike hosts-lêer te sit is die vinnigste manier om te bewys dat die tonnel en die diens se firewall reeds werk. As die versoek met daardie inskrywing slaag, is slegs naamoplossing stukkend. Dit is ook ’n per-masjien-wysiging wat presies een naam dek.

Dit help nie die tweede rekening, die tweede eindpunt of ’n kollega nie, en dit breek sonder waarskuwing wanneer die eindpunt by ’n nuwe adres herskep word.

Erger nog, dit laat jou masjien anders optree as almal s’n, en dit is hoe ’n resolver-fout ’n week lange ondersoek oorleef. Gebruik dit om die pad te bevestig, haal dit dan uit en maak die oorsaak reg.

Koppel die sone en deel ’n resolver uit

Twee voorwaardes moet gelyktydig geld. Die private sone moet aan die virtuele netwerk gekoppel wees waar die eindpunt woon, en die kliënt moet sy navrae na ’n bediener stuur wat daardie sone kan lees. ’n DNS Private Resolver-inkomende eindpunt verskaf so ’n adres binne die netwerk en antwoord navrae wat oor die tonnel aankom. Sit daardie adres in die VPN-profiel en voeg die private agtervoegsel by wat die kliënt moet toepas.

’n Bestaande plaaslike resolver kan dieselfde uitkoms bereik deur ’n voorwaardelike aanstuurder op die sone gerig.

Netwerk-reëls op die resolver tel net soveel as roetering. As die inkomende reël die VPN-kliënt-reeks uitsluit, verloop navrae eerder as om ’n verkeerde antwoord te gee. Dit is daardie tydverloop wat mense terugstuur na ’n roetetabel waar niks verkeerd is nie.

Kontroleer naam, poort en identiteit in volgorde

Werk in volgorde: los die naam op, bevestig die antwoord is privaat, maak die poort oop, maak dan ’n geauthentiseerde versoek. Elke stadium het sy eie eienaar en sy eie fouthandtekening.

’n Private antwoord gevolg deur ’n tydverloop dui op ’n roete of ’n firewall. ’n Publieke antwoord dui op die resolver. ’n Voltooide verbinding wat ’n identiteitsfout teruggee, behoort aan die diens.

Nog een fout hoort op hierdie lys. ’n Diens-firewall wat ’n kliënt-adres toelaat, hou op pas wanneer die poel daardie adres ná ’n herverbinding aan ’n ander sessie gee. Lees die oproeper-adres wat die diens opgeteken het eerder as die een wat die kliënt dink hy het. Die twee stem meer dikwels nie ooreen as wat mense verwag nie. Die Azure DNS Private Resolver-riglyne dek die sone-koppeling en aanstuur-reëling.