Prečo privátny koncový bod stále odpovedá verejnou adresou
Prejdite dopyt od notebooku smerom von: ktorý resolver odpovedá, aká adresa sa vracia a čo musí byť prepojené, kým je privátny koncový bod dostupný.
Notebook sa pripojí, tunel hlási, že je aktívny, a účet úložiska napriek tomu odmieta každú požiadavku. Privátny koncový bod existuje, trasa do jeho podsiete existuje a meno buď odpovedá verejnou adresou, alebo sa vôbec nepreloží. S tunelom nie je nič zlé: klientovi nikdy nebolo povedané, ktorý server má za toto meno odpovedať. Prejdite dopyt smerom von a medzera bude zjavná.
Začnite pri resolveri klienta
Opýtajte sa klienta, ktorý server sa dopytuje, kým je tunel aktívny. Profil typu bod na lokalitu túto adresu dodáva a profil, ktorý nič nedodáva, necháva operačný systém vrátiť sa k predvoleným hodnotám adaptéra.
Verejné resolvery nemajú o privátnej zóne žiadne povedomie, takže odpovedajú z internetu, čo je presne ich úlohou. Prvá kontrola je preto adresa používaného resolvera, nie tunel a nie koncový bod.
Prečítajte si, čo je odpoveď v skutočnosti
Preložte názov služby a prečítajte adresu, ktorá sa vráti. Verejná odpoveď znamená, že dopyt dorazil na server, ktorý zónu nevidí. Žiadna odpoveď znamená, že meno existuje len privátne a nič, čo klient dosiahne, ho nedrží.
Tieto dva výsledky spôsobujú podobné chyby aplikácie a patria rôznym vlastníkom. Jeden je problém voľby resolvera, druhý je chýbajúce prepojenie zóny.
Záznam v hosts dokáže cestu a potom klame
Zápis adresy koncového bodu do miestneho súboru hosts je najrýchlejší spôsob, ako dokázať, že tunel aj firewall služby už fungujú. Ak požiadavka s týmto záznamom uspeje, rozbité je len prekladanie mien. Je to aj úprava pre jeden stroj, ktorá pokrýva presne jedno meno.
Nepomôže druhému účtu, druhému koncovému bodu ani kolegovi a bez varovania sa rozbije, keď sa koncový bod znova vytvorí na novej adrese.
Horšie, váš stroj sa správa inak ako všetky ostatné, a práve tak prežije porucha resolvera týždeň vyšetrovania. Použite ho na potvrdenie cesty, potom ho odstráňte a opravte príčinu.
Prepojte zónu a pridelte resolver
Musia platiť dve podmienky súčasne. Privátna zóna musí byť prepojená s virtuálnou sieťou, kde koncový bod žije, a klient musí posielať dopyty serveru, ktorý túto zónu vie čítať. Prichádzajúci koncový bod DNS Private Resolver poskytuje takú adresu vnútri siete a odpovedá na dopyty prichádzajúce tunelom. Vložte túto adresu do profilu VPN a pridajte privátnu príponu, ktorú má klient uplatňovať.
Už existujúci miestny resolver môže dosiahnuť rovnaký výsledok cez podmienené presmerovanie namierené na zónu.
Sieťové pravidlá na resolveri platia rovnako ako smerovanie. Ak prichádzajúce pravidlo vylučuje rozsah klientov VPN, dopyty vypršia, namiesto toho aby vrátili nesprávnu odpoveď. Práve toto vypršanie posiela ľudí späť k tabuľke trás, kde nič nie je zle.
Skontrolujte meno, port a identitu v poradí
Postupujte v poradí: preložte meno, potvrďte, že odpoveď je privátna, otvorte port a potom vykonajte overenú požiadavku. Každá fáza má svojho vlastníka a svoj podpis zlyhania.
Privátna odpoveď nasledovaná vypršaním ukazuje na trasu alebo firewall. Verejná odpoveď ukazuje na resolver. Dokončené spojenie, ktoré vracia chybu identity, patrí službe.
Do tohto zoznamu patrí ešte jedno zlyhanie. Firewall služby, ktorý povoľuje adresu klienta, prestane zodpovedať, keď fond po opätovnom pripojení pridelí túto adresu inej relácii. Čítajte adresu volajúceho, ktorú služba zaznamenala, nie tú, o ktorej si klient myslí, že ju má. Tie dve sa rozchádzajú častejšie, než ľudia čakajú. Pokyny Azure DNS Private Resolver pokrývajú prepojenie zóny a usporiadanie presmerovania.