Tilkoblet er en tilstand av tunnelen, ikke en påstand om nåbarhet. En punkt-til-område-klient kan fullføre IKE, motta en adresse og fortsatt ikke nå noe, fordi gatewayen bare videresender trafikk for nettverk som VNet allerede kjenner. Gå gjennom disse fem kontrollene i rekkefølge og stopp ved første feil. Å hoppe fremover er måten et DNS-problem blir behandlet som et brannmurproblem i en time.

Rekkefølgen betyr mer enn listen.

Kontroll 1: avgjør hva tunnelen skal bære

Azure VPN Gateway avslutter tunnelen og videresender trafikk som hører til VNet; den erikke en generell internettutgang. Hvis brukerne forventer at nettlesingen deres skal gå ut gjennom Azure, er designet feil før noen klientinnstilling kommer i spill. Slå på split tunneling slik at det lokale internettet blir på den lokale veien, og bruk en NAT-instans eller en site-til-site-tunnel når en fast utgangsadresse virkelig er nødvendig.

Skriv ned hva klienten skal nå før du tester noe. Uten den listen ser hvert delresultat ut som fremgang.

Kontroll 2: sammenlign adresserom før sertifikater

Overlapp vurderes på de bredere områdene, så to nettverk som ser ulike ut på subnettnivå kolliderer fortsatt hvis overordnede blokker overlapper. Gateway-subnettet må være dedikert og stort nok for SKU-en, og klientens adressepool må ikke kollidere med VNet eller med noe som er nåbart via en peering. Endre planen og distribuer på nytt, fordi å legge til ruter som kompensasjon gir en tunnel som virker for noen mål og uforklarlig ikke for andre. Provisjoneringen feiler høyt her, og det er det gode tilfellet.

Autentisering er neste port. Sertifikat-, RADIUS- og Entra ID-profiler er ikke utbyttbare, og klientpakken er forskjellig for hver.

Kontroll 3: løs opp et privat navn innenfra

Klienten beholder sin egen oppløser med mindre den nedlastede profilen inneholder VNet-ens DNS-servere, og den listen bygges inn ved nedlasting. Legg til en forwarder inne i VNet, sett den som VNet-ens DNS-server, og last ned og importer klientpakken på nytt. Å gjenbruke den gamle pakken tester bare den gamle oppløserlisten.

Test en adresse først, fordi det skiller ruting fra navngiving i ett trinn: Test-NetConnection 10.20.1.4 -Port 3389.

Hvis adressen svarer og navnet ikke, spør oppløseren direkte med Resolve-DnsName files.corp.example -Server 10.20.0.4. Hvis begge feiler, er feilen ikke DNS, og du bør slutte å redigere DNS-innstillinger. Azure-plattform-DNS på 168.63.129.16 svarer bare innenfra VNet, så en klient utenfor kan ikke bruke den adressen som oppløser.

Kontroll 4: test tjenesten bak tunnelen

En sunn tunnel og en lukket port ser identiske ut fra klienten. Sjekk brannmuren på gjesten, deretter nettverkssikkerhetsgruppen på subnettet eller NIC-en, og deretter om tjenesten lytter på den private adressen i stedet for bare på loopback. Tillat klientpoolen som kilde i stedet for å åpne en regel mot internett, og husk at SMB til Azure Files trenger at den private endepunktstien rutes gjennom tunnelen. Når en ressurs svarer på IP men ikke på navn, gå tilbake til kontroll 3 i stedet for å røre gatewayen.

Én tabell holder lagene fra hverandre mens du arbeider:

SymptomLayer to check
Name fails, private IP worksResolver setting or forwarder
Private IP also failsAddress plan, NSG, guest firewall
Private works, internet failsExpected; the gateway is not an egress
Connects, then dropsTunnel type or certificate mismatch

Kontroll 5: registrer profilen før du eskalerer

Sett gatewaytype, tunneltype, autentiseringsmetode og klientens operativsystem i saken. En sertifikat-IKEv2-profil og en RADIUS-profil feiler av ulike grunner, og en klient bygget for en annen tunneltype kobler bare til når gatewayen tilbyr en kompatibel protokoll.

For et lite team er det holdbare designet ett VNet, én DNS-forwarder og en dokumentert split-tunnel-klient. Hvis kravet er en fast offentlig utgang, avslutt en site-til-site-tunnel på en brannmur du kontrollerer og rut internettrafikken dit, i stedet for å be punkt-til-område-gatewayen om noe den aldri ble bygget for.

Relaterte artikler