Proč privátní koncový bod stále odpovídá veřejnou adresou

Notebook se připojí, tunel hlásí, že je aktivní, a účet úložiště přesto odmítá každý požadavek. Privátní koncový bod existuje, trasa do jeho podsítě existuje a jméno buď odpovídá veřejnou adresou, nebo se vůbec nepřeloží. S tunelem není nic špatně: klientovi nikdy nebylo řečeno, který server má za toto jméno odpovídat. Projděte dotaz směrem ven a mezera bude zjevná.

Začněte u resolveru klienta

Zeptejte se klienta, který server dotazuje, dokud je tunel aktivní. Profil typu bod na lokalitu tuto adresu dodává, a profil, který nic nedodává, nechává operační systém vrátit se k výchozím hodnotám adaptéru.

Veřejné resolvery nemají o privátní zóně žádné povědomí, takže odpovídají z internetu, což je přesně jejich úkol. První kontrola je proto adresa používaného resolveru, ne tunel a ne koncový bod.

Přečtěte si, čím odpověď skutečně je

Přeložte název služby a přečtěte adresu, která se vrátí. Veřejná odpověď znamená, že dotaz dorazil na server, který zónu nevidí. Žádná odpověď znamená, že jméno existuje jen privátně a nic, co klient dosáhne, ho nedrží.

Tyto dva výsledky způsobují podobné chyby aplikace a patří různým vlastníkům. Jeden je problém volby resolveru, druhý je chybějící propojení zóny.

Záznam v hosts dokáže cestu a pak lže

Zapsání adresy koncového bodu do místního souboru hosts je nejrychlejší způsob, jak dokázat, že tunel i firewall služby už fungují. Pokud požadavek s tímto záznamem uspěje, je rozbité pouze překládání jmen. Je to také úprava pro jeden stroj, která pokrývá přesně jedno jméno.

Nepomůže druhému účtu, druhému koncovému bodu ani kolegovi a bez varování se rozbije, když se koncový bod znovu vytvoří na nové adrese.

Horší je, že váš stroj se chová jinak než všechny ostatní, a právě tak přežije závada resolveru týden vyšetřování. Použijte ho k potvrzení cesty, pak ho odstraňte a opravte příčinu.

Propojte zónu a přidělte resolver

Musí platit dvě podmínky současně. Privátní zóna musí být připojena k virtuální síti, kde koncový bod žije, a klient musí posílat dotazy serveru, který tuto zónu umí číst. Příchozí koncový bod DNS Private Resolver poskytuje takovou adresu uvnitř sítě a odpovídá na dotazy přicházející tunelem. Vložte tuto adresu do profilu VPN a přidejte privátní příponu, kterou má klient uplatňovat.

Již existující místní resolver může dosáhnout stejného výsledku pomocí podmíněného přesměrování namířeného na zónu.

Síťová pravidla na resolveru platí stejně jako směrování. Pokud příchozí pravidlo vylučuje rozsah klientů VPN, dotazy vyprší, místo aby vrátily špatnou odpověď. Právě toto vypršení posílá lidi zpět k tabulce tras, kde nic není špatně.

Kontrolujte jméno, port a identitu popořadě

Postupujte popořadě: přeložte jméno, potvrďte, že odpověď je privátní, otevřete port a poté odešlete ověřený požadavek. Každá fáze má svého vlastníka a svůj podpis selhání.

Privátní odpověď následovaná vypršením ukazuje na trasu nebo firewall. Veřejná odpověď ukazuje na resolver. Dokončené spojení, které vrací chybu identity, patří službě.

Do tohoto seznamu patří ještě jedno selhání. Firewall služby, který povoluje adresu klienta, přestane odpovídat, když fond po opětovném připojení přidělí tuto adresu jiné relaci. Čtěte adresu volajícího, kterou služba zaznamenala, ne tu, o které si klient myslí, že ji má. Ty dvě se rozcházejí častěji, než lidé čekají. Pokyny Azure DNS Private Resolver pokrývají propojení zóny a uspořádání přesměrování.