Azure pont-cél kapcsolat létrejön, de egyetlen privát erőforrás sem válaszol
A csatlakozva csak azt jelenti, hogy az alagút felállt. Ellenőrizze, mit tud szállítani az átjáró, hasonlítsa össze a címtartományokat, majd oldjon fel egy nevet, és tesztelje magát a szolgáltatást.
A csatlakozva az alagút állapota, nem állítás az elérhetőségről. Egy pont-cél kliens befejezheti az IKE-t, kaphat címet, és mégis semmit sem ér el, mert az átjáró csak azoknak a hálózatoknak továbbít forgalmat, amelyeket a VNet már ismer. Végezze el ezt az öt ellenőrzést sorrendben, és álljon meg az első hibánál. Az előreszaladás az, ahogy egy DNS-problémát egy órán át tűzfálproblémaként kezelnek.
A sorrend fontosabb, mint a lista.
1. ellenőrzés: döntse el, mit kell szállítania az alagútnak
Az Azure VPN Gateway lezárja az alagutat, és továbbítja a VNethez tartozó forgalmat; ez nemáltalános internetes kijárat. Ha a felhasználók azt várják, hogy böngészésük Azure-on keresztül lépjen ki, a tervezés már azelőtt hibás, hogy bármilyen kliensbeállítás szóba kerülne. Kapcsolja be a split tunnelinget, hogy a helyi internet a helyi úton maradjon, és használjon NAT-példányt vagy hely-hely alagutat, amikor valóban állandó kimenő címre van szükség.
Írja fel, hova kell eljutnia a kliensnek, mielőtt bármit tesztel. A lista nélkül minden részeredmény előrelépésnek látszik.
2. ellenőrzés: hasonlítsa össze a címtartományokat a tanúsítványok előtt
Az átfedést a szélesebb tartományok alapján ítélik meg, ezért két hálózat, amely alhálózati szinten különbözőnek látszik, akkor is ütközik, ha a szülő blokkjaik átfednek. Az átjáró alhálózatának dedikáltnak és az SKU-hoz elég nagynak kell lennie, a kliens címpoolja pedig nem ütközhet a VNet-tel vagy bármivel, ami peeringen keresztül elérhető. Módosítsa a tervet és telepítse újra, mert a kompenzáló útvonalak hozzáadása olyan alagutat hoz létre, amely egyes célokhoz működik, másokhoz pedig megmagyarázhatatlanul nem. A kiépítés itt hangosan meghiúsul, ami a jó eset.
A hitelesítés a következő kapu. A tanúsítványos, a RADIUS- és az Entra ID-profil nem felcserélhető, és a klienscsomag mindegyiknél más.
3. ellenőrzés: oldjon fel egy privát nevet belülről
A kliens megtartja saját feloldóját, hacsak a letöltött profil nem tartalmazza a VNet DNS-kiszolgálóit, és ez a lista a letöltés pillanatában beépül. Adjon hozzá egy forwardert a VNeten belül, állítsa be a VNet DNS-kiszolgálójaként, majd töltse le és importálja újra a klienscsomagot. A régi csomag újrafelhasználása csak a régi feloldólistát teszteli.
Először egy címet teszteljen, mert ez egy lépésben választja el az útválasztást a névfeloldástól: Test-NetConnection 10.20.1.4 -Port 3389.
Ha a cím válaszol és a név nem, kérdezze meg a feloldót közvetlenül ezzel: Resolve-DnsName files.corp.example -Server 10.20.0.4. Ha mindkettő meghiúsul, a hiba nem DNS, és abba kell hagynia a DNS-beállítások szerkesztését. Az Azure platform DNS a 168.63.129.16 címen csak a VNeten belülről válaszol, így azon kívüli kliens nem használhatja ezt a címet feloldóként.
4. ellenőrzés: tesztelje az alagút mögötti szolgáltatást
Egy egészséges alagút és egy zárt port a kliens oldaláról azonosnak látszik. Ellenőrizze a vendég tűzfalát, majd az alhálózat vagy a NIC hálózati biztonsági csoportját, majd hogy a szolgáltatás a privát címen figyel-e, nem csak loopbacken. Forrásként engedélyezze a kliens poolt ahelyett, hogy szabályt nyitna az internet felé, és ne feledje, hogy az Azure Files felé menő SMB-hez a privát végpont útvonalának az alagúton kell haladnia. Ha egy erőforrás IP szerint válaszol, de név szerint nem, térjen vissza a 3. ellenőrzéshez, nehogy hozzáérjen az átjáróhoz.
Egy táblázat tartja külön a rétegeket munka közben:
| Symptom | Layer to check |
|---|---|
| Name fails, private IP works | Resolver setting or forwarder |
| Private IP also fails | Address plan, NSG, guest firewall |
| Private works, internet fails | Expected; the gateway is not an egress |
| Connects, then drops | Tunnel type or certificate mismatch |
5. ellenőrzés: rögzítse a profilt az eszkalálás előtt
Írja a jegybe az átjáró típusát, az alagút típusát, a hitelesítési módot és a kliens operációs rendszerét. A tanúsítványos IKEv2-profil és a RADIUS-profil különböző okokból hiúsul meg, és a másik alagúttípusra épített kliens csak akkor csatlakozik, ha az átjáró kompatibilis protokollt kínál.
Egy kis csapat számára a tartós tervezés egy VNet, egy DNS-forwarder és egy dokumentált split-tunnel kliens. Ha a követelmény állandó nyilvános kijárat, fejezzen be egy hely-hely alagutat egy Ön által irányított tűzfalon, és oda irányítsa az internetes forgalmat, ahelyett hogy a pont-cél átjárótól kérne olyat, amire soha nem építették.