Kumokonekta ang Azure point-to-site pero walang pribadong resource ang tumutugon
Ang konektado ay nangangahulugan lamang na umangat ang tunnel. Suriin kung ano ang kayang dalhin ng gateway, ihambing ang mga espasyo ng address, pagkatapos ay lutasin ang isang pangalan at subukan ang serbisyo mismo.
Ang konektado ay isang kalagayan ng tunnel, hindi pahayag tungkol sa maabot. Ang isang point-to-site client ay maaaring tapusin ang IKE, makatanggap ng address at wala pa ring maabot, dahil ang gateway ay nagpapasa lamang ng trapiko para sa mga network na alam na ng VNet. Gawin ang limang pagsusuring ito nang sunud-sunod at huminto sa unang pagkabigo. Ang paglukso pasulong ay ang paraan ng pagtrato sa problema ng DNS bilang problema ng firewall sa loob ng isang oras.
Mas mahalaga ang pagkakasunod-sunod kaysa sa listahan.
Pagsusuri 1: magpasya kung ano ang dapat dalhin ng tunnel
Ang Azure VPN Gateway ay nagtatapos ng tunnel at nagpapasa ng trapikong pag-aari ng VNet; hindi itopangkalahatang labasan sa internet. Kung inaasahan ng mga gumagamit na dadaan sa Azure ang kanilang pag-browse, mali na ang disenyo bago pa man pumasok ang anumang setting ng client. I-enable ang split tunneling upang manatili sa lokal na landas ang lokal na internet, at gumamit ng NAT instance o site-to-site tunnel kapag talagang kailangan ang fixed na address ng labasan.
Isulat kung saan dapat maabot ng client bago mo subukan ang kahit ano. Kung wala ang listahang iyon, bawat bahagyang resulta ay mukhang progreso.
Pagsusuri 2: ihambing ang mga espasyo ng address bago ang mga sertipiko
Ang overlap ay hinuhusgahan sa mas malalawak na saklaw, kaya ang dalawang network na mukhang magkaiba sa antas ng subnet ay nagbabanggaan pa rin kung nag-o-overlap ang kanilang mga parent block. Ang subnet ng gateway ay dapat nakalaan at sapat na malaki para sa SKU, at ang pool ng address ng client ay hindi dapat bumangga sa VNet o sa anumang maabot sa pamamagitan ng peering. Baguhin ang plano at i-deploy muli, dahil ang pagdaragdag ng mga ruta bilang kompensasyon ay gumagawa ng tunnel na gumagana para sa ilang destinasyon at hindi maipaliwanag na hindi para sa iba. Nabibigo nang malakas ang provisioning dito, at iyon ang magandang kaso.
Ang authentication ang susunod na pintuan. Ang mga profile ng sertipiko, RADIUS at Entra ID ay hindi mapagpapalit, at ang pakete ng client ay iba para sa bawat isa.
Pagsusuri 3: lutasin ang pribadong pangalan mula sa loob
Pinapanatili ng client ang sarili nitong resolver maliban kung dala ng na-download na profile ang mga DNS server ng VNet, at ang listahang iyon ay nakapaloob sa oras ng pag-download. Magdagdag ng forwarder sa loob ng VNet, itakda ito bilang DNS server ng VNet, pagkatapos ay i-download at i-import muli ang pakete ng client. Ang muling paggamit ng lumang pakete ay sumusubok lamang sa lumang listahan ng resolver.
Subukan muna ang isang address, dahil hinihiwalay nito ang routing sa pagpapangalan sa isang hakbang: Test-NetConnection 10.20.1.4 -Port 3389.
Kung tumutugon ang address at hindi ang pangalan, tanungin ang resolver nang direkta gamit ang Resolve-DnsName files.corp.example -Server 10.20.0.4. Kung parehong nabigo, ang sira ay wala sa DNS at dapat mong itigil ang pag-edit ng mga setting ng DNS. Ang DNS ng platform ng Azure sa 168.63.129.16 ay tumutugon lamang mula sa loob ng VNet, kaya ang client sa labas nito ay hindi magagamit ang address na iyon bilang resolver.
Pagsusuri 4: subukan ang serbisyo sa likod ng tunnel
Ang malusog na tunnel at saradong port ay magkapareho sa paningin ng client. Suriin ang firewall ng bisita, pagkatapos ang network security group sa subnet o NIC, pagkatapos kung nakikinig ang serbisyo sa pribadong address at hindi lamang sa loopback. Payagan ang pool ng client bilang pinagmulan sa halip na magbukas ng panuntunan sa internet, at tandaan na ang SMB patungo sa Azure Files ay nangangailangan ng landas ng pribadong endpoint na dinaraanan ng tunnel. Kapag tumugon ang isang resource sa IP ngunit hindi sa pangalan, bumalik sa pagsusuri 3 sa halip na hawakan ang gateway.
Isang talahanayan ang naghihiwalay sa mga layer habang nagtatrabaho ka:
| 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 |
Pagsusuri 5: itala ang profile bago ka mag-escalate
Ilagay sa ticket ang uri ng gateway, uri ng tunnel, paraan ng authentication at operating system ng client. Nabibigo ang certificate IKEv2 profile at RADIUS profile sa magkaibang dahilan, at ang client na ginawa para sa ibang uri ng tunnel ay kumokonekta lamang kapag nag-aalok ang gateway ng katugmang protocol.
Para sa maliit na koponan, ang matatag na disenyo ay isang VNet, isang DNS forwarder at isang dokumentadong split-tunnel client. Kung ang pangangailangan ay fixed na pampublikong labasan, tapusin ang site-to-site tunnel sa firewall na kontrolado mo at i-route doon ang trapiko ng internet, sa halip na hilingin sa point-to-site gateway ang isang bagay na hindi kailanman ginawa para doon.