Azure punkt-til-område koplar til, men ingen privat ressurs svarar

Tilkopla er ein tilstand av tunnelen, ikkje ei utsegn om nåbarheit. Ein punkt-til-område-klient kan fullføre IKE, ta imot ei adresse og framleis ikkje nå noko, fordi gatewayen berre sender vidare trafikk for nettverk som VNet allereie kjenner. Gå gjennom desse fem kontrollane i rekkjefølgje og stopp ved første feil. Å hoppe framover er måten eit DNS-problem blir handsama som eit brannmurproblem i ein time.

Rekkjefølgja betyr meir enn lista.

Kontroll 1: avgjer kva tunnelen skal bera

Azure VPN Gateway avsluttar tunnelen og sender vidare trafikk som høyrer til VNet; han erikkje ein generell internettutgang. Viss brukarane ventar at nettlesinga deira skal gå ut gjennom Azure, er designet feil før noka klientinnstilling kjem i spel. Slå på split tunneling slik at det lokale internettet blir på den lokale vegen, og bruk ein NAT-instans eller ein site-til-site-tunnel når ei fast utgangsadresse verkeleg er naudsynt.

Skriv ned kva klienten skal nå før du testar noko. Utan den lista ser kvart delresultat ut som framgang.

Kontroll 2: samanlikn adresserom før sertifikat

Overlapp blir vurdert på dei breiare områda, så to nettverk som ser ulike ut på subnettnivå kolliderer framleis viss overordna blokker overlappar. Gateway-subnettet må vere dedikert og stort nok for SKU-en, og klienten sin adressepool må ikkje kollidere med VNet eller med noko som er nåbart via ein peering. Endre planen og distribuer på nytt, fordi å leggje til ruter som kompensasjon gir ein tunnel som verkar for nokre mål og uforklarleg ikkje for andre. Provisioneringa feilar høgt her, og det er det gode tilfellet.

Autentisering er neste port. Sertifikat-, RADIUS- og Entra ID-profilar er ikkje utbyttbare, og klientpakken er ulik for kvar.

Kontroll 3: løys opp eit privat namn innanfrå

Klienten held på sin eigen oppløysar med mindre den nedlasta profilen inneheld DNS-tenarane til VNet, og den lista blir bygd inn ved nedlasting. Legg til ein forwarder inne i VNet, set han som DNS-tenar for VNet, og last ned og importer klientpakken på nytt. Å bruke den gamle pakken på nytt testar berre den gamle oppløysarlista.

Test ein adresse først, fordi det skil rutING frå namngjeving i eitt trinn: Test-NetConnection 10.20.1.4 -Port 3389.

Viss adressa svarar og namnet ikkje, spør oppløysaren direkte med Resolve-DnsName files.corp.example -Server 10.20.0.4. Viss begge feilar, er feilen ikkje DNS, og du bør slutte å redigere DNS-innstillingar. Azure-plattform-DNS på 168.63.129.16 svarar berre innanfrå VNet, så ein klient utanfor kan ikkje bruke den adressa som oppløysar.

Kontroll 4: test tenesta bak tunnelen

Ein sunn tunnel og ein lukka port ser identiske ut frå klienten. Sjekk brannmuren på gjesten, deretter nettverkssikkerheitsgruppa på subnettet eller NIC-en, og deretter om tenesta lyttar på den private adressa i staden for berre på loopback. Tillat klientpoolen som kjelde i staden for å opne ei regel mot internett, og hugs at SMB til Azure Files treng at stien til det private endepunktet blir ruta gjennom tunnelen. Når ein ressurs svarar på IP men ikkje på namn, gå tilbake til kontroll 3 i staden for å røre gatewayen.

Éin tabell held laga frå kvarandre medan du arbeider:

Kontroll 5: registrer profilen før du eskalerer

Set gatewaytypen, tunneltypen, autentiseringsmetoden og operativsystemet til klienten i saka. Ein sertifikat-IKEv2-profil og ein RADIUS-profil feilar av ulike grunnar, og ein klient bygd for ein annan tunneltype koplar berre til når gatewayen tilbyr ein kompatibel protokoll.

For eit lite team er det haldbare designet eitt VNet, éin DNS-forwarder og ein dokumentert split-tunnel-klient. Viss kravet er ein fast offentleg utgang, avslutt ein site-til-site-tunnel på ein brannmur du kontrollerer og rut internettrafikken dit, i staden for å be punkt-til-område-gatewayen om noko han aldri vart bygd for.