Azure пункт-да-сайта падключаецца, але ні адзін прыватны рэсурс не адказвае
Падключэнне азначае толькі тое, што тунель узняўся. Праверце, што можа прапускаць шлюз, параўнайце адрасныя прасторы, затым развязайце імя і праверце саму службу.
Падключэнне — гэта стан тунеля, а не сцвярджэнне пра дасяжнасць. Кліент пункт-да-сайта можа завяршыць IKE, атрымаць адрас і ўсё роўна нічога не дасягнуць, бо шлюз перапраўляе трафік толькі для сетак, якія VNet ужо ведае. Прайдзіце гэтыя пяць праверак па чарзе і спыніцеся на першай няўдачы. Пераскокванне наперад — гэта як праблема DNS на гадзіну робіцца праблемай міжсеткавага экрана.
Парадак важнейшы за спіс.
Праверка 1: вызначце, што тунель павінен перапраўляць
Azure VPN Gateway завяршае тунель і перапраўляе трафік, які належыць VNet; ённе з'яўляецца агульным выхадам у інтэрнэт. Калі карыстальнікі чакаюць, што іх прагляд пойдзе праз Azure, дызайн памылковы яшчэ да таго, як задзейнічаны любы кліенцкі настрой. Уключыце split tunneling, каб лакальны інтэрнэт заставаўся на лакальным шляху, і выкарыстоўвайце асобнік NAT або тунель сайт-да-сайта, калі фіксаваны адрас выхаду сапраўды патрэбны.
Запішыце, да чаго кліент павінен дасягнуць, перш чым нешта правяраць. Без гэтага спісу любы частковы вынік выглядае як прагрэс.
Праверка 2: параўнайце адрасныя прасторы да сертыфікатаў
Перасячэнне ацэньваецца па шырэйшых дыяпазонах, таму дзве сеткі, якія на ўзроўні падсетак выглядаюць рознымі, усё роўна сутыкаюцца, калі іх бацькоўскія блокі перасякаюцца. Падсетка шлюза павінна быць выдзеленай і дастаткова вялікай для SKU, а пул адрасоў кліента не павінен сутыкацца з VNet ці з чым-небудзь дасяжным праз peering. Змяніце план і разгарніце нанова, бо даданне маршрутаў для кампенсацыі стварае тунель, які працуе для адных пунктаў прызначэння і невытлумачальна не працуе для іншых. Падрыхтоўка тут гучна правальваецца, і гэта добры выпадак.
Аўтэнтыфікацыя — наступная брама. Профілі сертыфіката, RADIUS і Entra ID не ўзаемазамяняльныя, і кліенцкі пакет для кожнага розны.
Праверка 3: развязайце прыватнае імя знутры
Кліент захоўвае ўласны рэзалвер, пакуль спампаваны профіль не ўтрымлівае DNS-серверы VNet, і гэты спіс убудаваны ў момант спампоўкі. Дадайце forwarder унутры VNet, задайце яго як DNS-сервер VNet, затым спампуйце і імпартуйце кліенцкі пакет зноў. Паўторнае выкарыстанне старога пакета правярае толькі стары спіс рэзалвераў.
Спачатку праверце адрас, бо гэта аддзяляе маршрутызацыю ад імёнаў за адзін крок: Test-NetConnection 10.20.1.4 -Port 3389.
Калі адрас адказвае, а імя не, запытайце рэзалвер напрамкі: Resolve-DnsName files.corp.example -Server 10.20.0.4. Калі не ўдаецца і тое, і тое, няспраўнасць не ў DNS, і вам варта спыніць змяняць налады DNS. DNS платформы Azure на 168.63.129.16 адказвае толькі знутры VNet, таму кліент па-за ёй не можа выкарыстоўваць гэты адрас як рэзалвер.
Праверка 4: праверце службу за тунелем
Здаровы тунель і закрыты порт з боку кліента выглядаюць аднолькава. Праверце міжсеткавы экран гасцявой сістэмы, затым групу бяспекі сеткі на падсетцы або NIC, затым тое, ці служба слухае прыватны адрас, а не толькі loopback. Дазвольце пул кліента як крыніцу замест таго, каб адкрываць правіла ў інтэрнэт, і памятайце, што SMB да Azure Files патрабуе шляху прыватнай канчатковай кропкі праз тунель. Калі рэсурс адказвае па IP, але не па імені, вярніцеся да праверкі 3, а не чапайце шлюз.
Адна табліца трымае пласты асобна, пакуль вы працуеце:
| 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: запішыце профіль перад эскалацыяй
Унясіце ў заяўку тып шлюза, тып тунеля, метад аўтэнтыфікацыі і аперацыйную сістэму кліента. Профіль IKEv2 з сертыфікатам і профіль RADIUS правальваюцца з розных прычын, а кліент, пабудаваны для іншага тыпу тунеля, падключаецца толькі тады, калі шлюз прапануе сумяшчальны пратакол.
Для невялікай каманды трывалы дызайн — гэта адзін VNet, адзін DNS-forwarder і дакументаваны кліент split tunneling. Калі патрабаваннем з'яўляецца фіксаваны публічны выхад, завяршыце тунель сайт-да-сайта на міжсеткавым экране, які вы кантралюеце, і накіруйце інтэрнэт-трафік туды, замест таго каб прасіць шлюз пункт-да-сайта рабіць тое, для чаго ён ніколі не будаваўся.