Azure punkt-til-site forbinder, men ingen privat ressource svarer
Forbundet betyder kun, at tunnelen er oppe. Undersøg, hvad gatewayen kan bære, sammenlign adresserum, og slå derefter et navn op og test tjenesten selv.
Forbundet er en tilstand af tunnelen, ikke en udtalelse om rækkevidde. En punkt-til-site-klient kan afslutte IKE, modtage en adresse og stadig ikke nå noget, fordi gatewayen kun videresender trafik for netværk, som VNet allerede kender. Gå disse fem kontroller igennem i rækkefølge, og stop ved den første fejl. At springe fremad er måden, hvorpå et DNS-problem bliver behandlet som et firewall-problem i en time.
Rækkefølgen betyder mere end listen.
Kontrol 1: afgør, hvad tunnelen skal bære
Azure VPN Gateway afslutter tunnelen og videresender trafik, der hører til VNet; den erikke en generel internetudgang. Hvis brugerne forventer, at deres browsing skal forlade netværket via Azure, er designet forkert, før nogen klientindstilling kommer i spil. Slå split tunneling til, så det lokale internet bliver på den lokale vej, og brug en NAT-instans eller en site-til-site-tunnel, når en fast udgangsadresse virkelig er påkrævet.
Skriv ned, hvad klienten skal nå, før du tester noget. Uden den liste ser ethvert delresultat ud som fremgang.
Kontrol 2: sammenlign adresserum før certifikater
Overlap vurderes på de bredere områder, så to netværk, der ser forskellige ud på subnetsniveau, støder stadig sammen, hvis deres overordnede blokke overlapper. Gateway-subnettet skal være dedikeret og stort nok til SKU'en, og klientens adressepulje må ikke støde sammen med VNet eller med noget, der kan nås via en peering. Ændr planen og udrul igen, fordi tilføjede ruter som kompensation giver en tunnel, der virker for nogle destinationer og uforklarligt ikke for andre. Provisionering fejler højlydt her, hvilket er det gode tilfælde.
Godkendelse er den næste port. Certifikat-, RADIUS- og Entra ID-profiler kan ikke udskiftes, og klientpakken er forskellig for hver.
Kontrol 3: slå et privat navn op indefra
Klienten beholder sin egen resolver, medmindre den downloadede profil indeholder VNet'ets DNS-servere, og den liste indlejres på downloadtidspunktet. Tilføj en forwarder inde i VNet, sæt den som VNet'ets DNS-server, og download og importér derefter klientpakken igen. Genbrug af den gamle pakke tester kun den gamle resolverliste.
Test først en adresse, fordi det adskiller routing fra navngivning i ét trin: Test-NetConnection 10.20.1.4 -Port 3389.
Hvis adressen svarer, og navnet ikke gør, så spørg resolveren direkte med Resolve-DnsName files.corp.example -Server 10.20.0.4. Hvis begge fejler, er fejlen ikke DNS, og du bør stoppe med at redigere DNS-indstillinger. Azure-platforms-DNS på 168.63.129.16 svarer kun indefra VNet, så en klient udenfor kan ikke bruge den adresse som resolver.
Kontrol 4: test tjenesten bag tunnelen
En sund tunnel og en lukket port ser identiske ud fra klienten. Undersøg gæstens firewall, derefter netværkssikkerhedsgruppen på subnettet eller NIC'en, og derefter om tjenesten lytter på den private adresse i stedet for kun på loopback. Tillad klientpuljen som kilde i stedet for at åbne en regel mod internettet, og husk at SMB til Azure Files kræver, at den private endpoint-sti rutes gennem tunnelen. Når en ressource svarer på IP men ikke på navn, gå tilbage til kontrol 3 i stedet for at røre gatewayen.
Én tabel holder lagene adskilt, mens du arbejder:
| 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 |
Kontrol 5: registrér profilen, før du eskalerer
Skriv gatewaytype, tunneltype, godkendelsesmetode og klientens operativsystem i sagen. En certifikat-IKEv2-profil og en RADIUS-profil fejler af forskellige grunde, og en klient bygget til en anden tunneltype forbinder kun, når gatewayen tilbyder en kompatibel protokol.
For et lille team er det holdbare design ét VNet, én DNS-forwarder og en dokumenteret split-tunnel-klient. Hvis kravet er en fast offentlig udgang, så afslut en site-til-site-tunnel på en firewall, du kontrollerer, og rut internettrafikken derhen i stedet for at bede punkt-til-site-gatewayen om noget, den aldrig blev bygget til.