Az Azure P2S VPN nem tudja feloldani egy privát végpont nevét

Csatlakozik a point-to-site alagúthoz, pingeli a privát címet, megnyitja az alkalmazást, és helyette 403-at vagy tanúsítványhibát kap. Mindkét tünet a DNS-re mutat, de két különböző hiba: az egyik azt jelenti, hogy a kliens a nyilvános címet oldotta fel, a másik azt, hogy a privát címet oldotta fel, majd olyan nevet adott meg, amelyet a tanúsítvány nem fed le. Vegye sorra az alábbi ellenőrzéseket, és álljon meg az első hibánál, mert egy hosts bejegyzés vagy egy gyorsítótárazott válasz minden későbbi ellenőrzést rossz okból sikerre vihet. Ezt a sorrendet egy szövegfájlban tartom a VPN-profiljaim mellett, mert a javítás semmit sem változtat az alagúton, és mindent megváltoztat abban, amit a kliens tud.

Kezdje azzal a címmel, amelyet a kliens valóban megkap

Kérdezze meg közvetlenül a feloldót ahelyett, hogy az alkalmazásban bízna. Windowson a nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net megmutatja, melyik nézetet kapta a kliens. A nyilvános válasz azt jelenti, hogy semmi sem fog elérni a végpontig; a végpont privát címe azt jelenti, hogy a DNS elkészült, és a következő ellenőrzés maga a kapcsolat.

A privát végpont nem nevezi át a szolgáltatást. A fiók vagy az alkalmazás megtartja a szokásos teljesen minősített nevét, a végpont pedig csak azt a címet változtatja meg, amelyre ez a név a virtuális hálózaton belüli kliensek számára feloldódik. Ezért ugyanaz a gépnév oldódik fel privát módon a hálózat egyik VM-jéről, és nyilvános módon arról a laptopról, amely soha nem kapta meg a privát nézetet.

Ellenőrizze a zónát, annak kapcsolatát és a rekordot az alagút előtt

Három feltételnek kell egyszerre teljesülnie: a privát zóna létezik, a virtuális hálózathoz van kapcsolva, amelyen a VPN-átjáró és a kliensek belépnek az Azure-ba, és tartalmaz egy A rekordot a végpont számára, amely a privát címre mutat. Kapcsolja a zónát egy nem odatartozó hálózathoz, és az átjáró továbbra is a nyilvános rekordot oldja fel, miközben az alagúton minden egészségesnek látszik.

A zónanevek szolgáltatásokhoz tartoznak, nem általában a privát kapcsolatokhoz. Az App Service általában a privatelink.azurewebsites.net nevet használja, a tárolásnak és az SQL-nek saját névtere van, és egy másik szolgáltatás zónájának kölcsönvétele olyan zónát eredményez, amely létezik, és semmi hasznosat nem válaszol.

Adjon a kliensnek olyan feloldót, amelyet valóban el tud érni

A 168.63.129.16 Azure-beli virtuális gépekről válaszol, és nem DNS-kiszolgáló a point-to-site alagút túloldalán lévő laptop számára. A kliensnek az alagúton keresztül elérhető feloldóra van szüksége: az Azure DNS Private Resolver bejövő végpontjára, a virtuális hálózaton belüli továbbítóra, vagy a VPN-kliensprofilban hordozott DNS-kiszolgáló bejegyzésekre, hogy a kliens közvetlenül a virtuális hálózatot kérdezze.

A beállított, de elérhetetlen feloldó pontosan úgy viselkedik, mint ha nem lenne feloldó, és a tünet időtúllépés, nem hibás válasz, ezért olvassák félre tűzfalproblémaként. Olyan lekérdezéssel tesztelje, amelyet az alagútnak kell szállítania, nem olyan nyilvános névvel, amely a helyi kapcsolaton amúgy is sikerült volna.

Ha továbbít a beállítások toljása helyett, azt a névteret továbbítsa, amely a privát zónáé, a privatelink.azurewebsites.net-t a teljes azurewebsites.net helyett. Az a feltételes továbbító, amely lenyeli a teljes szülő utótagot, a szolgáltatás minden keresését az Azure-ba küldi, azokat is, amelyeknek helyben kellene maradniuk.

Használja azt a nevet, amelyre a tanúsítványt kiállították

Amikor a cím helyes, előjön a második hiba. A tárolás és az App Service közzétesz egy privatelink aliast, és ez az alias nem feltétlenül a tanúsítványban szereplő név. A privatelink.blob.core.windows.net címre küldött AzCopy-feltöltés elbukott az ellenőrzésen; ugyanaz a feltöltés a <account>.blob.core.windows.net/<container> címre a privát címre oldódott fel és átment, így megkerülés nélkül a privát úton maradt.

A szabály böngészőben és az App Service esetében is érvényes: azzal a gépnévvel kapcsolódjon, amelyet a tanúsítvány lefed, és hagyja, hogy a DNS adja a privát címet. Ne nyúljon az ellenőrzés megkerüléséhez, mert az egy elnevezési hibát biztonsági visszaeséssé változtat. A sikeres ping bizonyítja az útvonalat, és semmit sem mond a kézfogáson belüli névről, ezért maradnak ezek külön ellenőrzések.

Négy lépéses sorrend, amely minden réteget elkülönít

1. Erősítse meg, hogy a VPN-kliens a point-to-site készletből kapott címet, és van útvonala a végpont privát címéhez.
2. Oldja fel azt a pontos nevet, amelyet az alkalmazás használ, és hasonlítsa össze a választ a végpont címével.
3. Nyisson TCP-kapcsolatot a végpont felé a szolgáltatás portján, majd olvassa ki az ezen a kapcsolaton bemutatott tanúsítványnevet.
4. Csak ezután tesztelje az engedélyezést, mert egy működő útvonal és egy érvényes tanúsítvány még nem ad hozzáférést az erőforráshoz.

A helyes cím mellett elutasított kapcsolat a hálózati biztonsági csoportra vagy a privát végpont kapcsolatának állapotára mutat, nem a DNS-re, ezért ezeket ellenőrizze, mielőtt újra szerkesztené a feloldó beállításait. A TLS-név eltérése visszaküldi az URL gépnevéhez és a tanúsítvány subject mezőjéhez. Tartsa együtt a feloldás kimenetét, a tanúsítvány nevét és a pontos URL-t; ez a három érték a legtöbb ilyen esetet megmagyarázza az átjáró érintése nélkül.

Használjon a virtuális hálózaton belüli VM-et kontrollként. Ha a név ott privát módon, az alagútból pedig nyilvános módon oldódik fel, a zóna és a rekord helyes, és az egyetlen különbség a kliens feloldási útvonala, amely gyorsabban megerősíthető, mint a végpont konfigurációjának újabb átnézése.

A kliensek is gyorsítótáraznak. Egy rekord, amely tíz perccel ezelőtt nyilvánosan válaszolt, a zóna javítása után is válaszol, ezért az újratesztelés előtt ürítse a gyorsítótárat. Windowson a ipconfig /flushdns törli a kliens gyorsítótárát; a névfeloldási házirend szabályai azonban megmaradnak, eldöntik, melyik utótag melyik kiszolgálóra megy, és továbbra is a nemrég lecserélt feloldóhoz küldhetik a névteret.

Hová való a hosts bejegyzés

A végpont címének felvétele egy hosts fájlba jó diagnosztika és rossz tervezés. Bizonyítja, hogy a név és a cím közötti leképezés a hiányzó darab, és lehetővé teszi minden későbbi lépés tesztelését, de láthatatlan a felhasználói számára, elromlik, amikor a végpont címe megváltozik, és elrejti a zónát, amelynek válaszolnia kellene.

A bennmaradt tesztbejegyzés rosszabb az elavult gyorsítótárnál, mert a hiba irányától függően a javított útvonalat töröttnek vagy a törött útvonalat javítottnak láttathatja. Távolítsa el a végső futás előtt, és csak az éles feloldóval oldjon fel.

A rövid nevekhez keresési utótag kell, a teljesen minősített nevekhez nem, ezért először a teljesen minősített nevet tesztelje, majd döntse el, hogy a munkafolyamatnak szüksége van-e a kliensprofilon keresztül tolt utótagra. A Microsoft szolgáltatásonként dokumentálja a zónaneveket és rekordformákat a privát végpontok DNS-irányelveiben; olvassa el a saját szolgáltatása bejegyzését, ahelyett hogy egy másikból másolna zónát.