Miért válaszol még mindig nyilvános címmel egy privát végpont

A laptop csatlakozik, az alagút aktívnak jelenti magát, a tárfiók mégis minden kérést elutasít. A privát végpont létezik, az útvonal az alhálózatához létezik, és a név vagy nyilvános címmel válaszol, vagy egyáltalán nem oldódik fel. Az alagúttal semmi baj: a kliensnek soha nem mondták meg, melyik kiszolgálónak kellene válaszolnia erre a névre. Kövesse a lekérdezést kifelé, és a hiány nyilvánvalóvá válik.

Kezdje a kliens feloldójánál

Kérdezze meg a klienst, melyik kiszolgálót kérdezi, amíg az alagút aktív. A pont-hely profil megadja ezt a címet, és az a profil, amely semmit nem ad, az operációs rendszerre hagyja, hogy visszavesse magát az adapter alapértékeire.

A nyilvános feloldóknak nincs rálátásuk egy privát zónára, ezért az internetről válaszolnak, ami pontosan a dolguk. Az első ellenőrzés tehát a használt feloldó címe, nem az alagút és nem a végpont.

Olvassa el, mi is valójában a válasz

Oldja fel a szolgáltatás nevét, és olvassa el a visszatérő címet. A nyilvános válasz azt jelenti, hogy a lekérdezés olyan kiszolgálóhoz ért, amely nem látja a zónát. A válasz hiánya azt jelenti, hogy a név csak privát módon létezik, és semmi, amit a kliens elérhet, nem tartja.

Ez a két eredmény hasonló alkalmazáshibákat okoz, és különböző tulajdonosokhoz tartozik. Az egyik feloldóválasztási probléma, a másik hiányzó zónakapcsolat.

A hosts bejegyzés bizonyítja az útvonalat, majd hazudik

A végpont címének beírása a helyi hosts fájlba a leggyorsabb módja annak bizonyítására, hogy az alagút és a szolgáltatás tűzfala már működik. Ha a kérés ezzel a bejegyzéssel sikerül, csak a névfeloldás tört el. Ez egyben gépenkénti módosítás, amely pontosan egy nevet fed le.

Nem segít a második fióknak, a második végpontnak vagy egy kollégának, és figyelmeztetés nélkül elromlik, amikor a végpontot új címen újra létrehozzák.

Ráadásul a gépe másképp viselkedik, mint mindenkié, és így él túl egy feloldóhiba egy hetes vizsgálatot. Használja az útvonal megerősítésére, aztán távolítsa el, és javítsa ki az okot.

Kapcsolja össze a zónát, és osszon ki feloldót

Két feltételnek kell egyszerre teljesülnie. A privát zónát ahhoz a virtuális hálózathoz kell kapcsolni, ahol a végpont él, és a kliensnek olyan kiszolgálóhoz kell küldenie a lekérdezéseit, amely olvasni tudja ezt a zónát. A DNS Private Resolver bejövő végpontja ilyen címet biztosít a hálózaton belül, és válaszol az alagúton érkező lekérdezésekre. Tegye ezt a címet a VPN-profilba, és adja hozzá a privát utótagot, amelyet a kliensnek alkalmaznia kell.

A már meglévő helyszíni feloldó ugyanezt az eredményt érheti el a zónára irányított feltételes továbbítóval.

A feloldón lévő hálózati szabályok ugyanannyit számítanak, mint az útválasztás. Ha a bejövő szabály kizárja a VPN-kliensek tartományát, a lekérdezések lejárnak ahelyett, hogy rossz választ adnának. Ez a lejárat az, ami visszaküldi az embereket egy útválasztási táblához, ahol semmi sem rossz.

Ellenőrizze a nevet, a portot és az identitást sorrendben

Sorrendben dolgozzon: oldja fel a nevet, erősítse meg, hogy a válasz privát, nyissa meg a portot, majd küldjön hitelesített kérést. Minden szakasznak megvan a maga tulajdonosa és a maga hiba-aláírása.

A privát választ követő lejárat útvonalra vagy tűzfalra mutat. A nyilvános válasz a feloldóra mutat. Az identitáshibát visszaadó, befejezett kapcsolat a szolgáltatásé.

Még egy hiba tartozik erre a listára. A kliens címet engedélyező szolgáltatás-tűzfal nem egyezik tovább, amikor a készlet az újracsatlakozás után egy másik munkamenetnek adja ezt a címet. A szolgáltatás által rögzített hívó címet olvassa, ne azt, amelyről a kliens azt hiszi, hogy van neki. A kettő gyakrabban tér el, mint ahogy az emberek várják. Az Azure DNS Private Resolver útmutatója lefedi a zónakapcsolatot és a továbbítás elrendezését.