Azure od točke do mesta se poveže, a noben zasebni vir se ne odzove

Povezano je stanje tunela, ne izjava o dosegljivosti. Odjemalec od točke do mesta lahko dokonča IKE, prejme naslov in vseeno ne doseže ničesar, ker prehod posreduje promet le za omrežja, ki jih VNet že pozna. Izvedite teh pet preverjanj po vrsti in ustavite se pri prvi napaki. Preskakovanje naprej je način, kako se težava DNS eno uro obravnava kot težava požarnega zidu.

Vrstni red je pomembnejši od seznama.

Preverjanje 1: odločite, kaj naj tunel prenaša

Azure VPN Gateway zaključi tunel in posreduje promet, ki pripada VNetu; nisplošen internetni izhod. Če uporabniki pričakujejo, da bo njihovo brskanje izšlo prek Azure, je zasnova napačna, še preden pride v igro kakršna koli nastavitev odjemalca. Vklopite split tunneling, da lokalni internet ostane na lokalni poti, in uporabite primerek NAT ali tunel od mesta do mesta, ko je resnično potreben fiksen izhodni naslov.

Preden karkoli preizkusite, zapišite, kam naj odjemalec pride. Brez tega seznama je vsak delni rezultat videti kot napredek.

Preverjanje 2: primerjajte naslovne prostore pred potrdili

Prekrivanje se presoja po širših obsegih, zato dve omrežji, ki sta na ravni podomrežja videti različni, vseeno trčita, če se njuna nadrejena bloka prekrivata. Podomrežje prehoda mora biti namensko in dovolj veliko za SKU, bazen naslovov odjemalca pa ne sme trčiti z VNetom ali s čimer koli dosegljivim prek peeringa. Spremenite načrt in znova namestite, ker dodajanje poti za kompenzacijo ustvari tunel, ki deluje za nekatere cilje in nerazložljivo ne za druge. Zagotavljanje tukaj glasno odpove, kar je dober primer.

Preverjanje pristnosti je naslednja vrata. Profili s potrdilom, RADIUS in Entra ID niso zamenljivi, paket odjemalca pa se za vsakega razlikuje.

Preverjanje 3: razrešite zasebno ime od znotraj

Odjemalec obdrži svoj resolver, razen če preneseni profil vsebuje strežnike DNS VNeta, in ta seznam je vdelan ob prenosu. Dodajte forwarder znotraj VNeta, nastavite ga kot strežnik DNS VNeta, nato znova prenesite in uvozite paket odjemalca. Ponovna uporaba starega paketa preizkusi le stari seznam resolverjev.

Najprej preizkusite naslov, ker to v enem koraku loči usmerjanje od poimenovanja: Test-NetConnection 10.20.1.4 -Port 3389.

Če se naslov odzove in ime ne, vprašajte resolver neposredno z Resolve-DnsName files.corp.example -Server 10.20.0.4. Če oboje spodleti, napaka ni v DNS in bi morali prenehati urejati nastavitve DNS. DNS platforme Azure na 168.63.129.16 se odzove le od znotraj VNeta, zato odjemalec zunaj njega tega naslova ne more uporabiti kot resolver.

Preverjanje 4: preizkusite storitev za tunelom

Zdrav tunel in zaprta vrata sta z vidika odjemalca videti enako. Preverite požarni zid gosta, nato varnostno skupino omrežja na podomrežju ali NIC, nato ali storitev posluša na zasebnem naslovu in ne le na loopbacku. Dovolite bazen odjemalcev kot vir, namesto da odprete pravilo v internet, in ne pozabite, da SMB do Azure Files potrebuje pot zasebne končne točke, usmerjeno skozi tunel. Ko se vir odzove po IP, ne pa po imenu, se vrnite k preverjanju 3, namesto da bi se dotaknili prehoda.

Ena tabela drži plasti ločene med delom:

Preverjanje 5: zabeležite profil pred eskalacijo

V zahtevek vpišite vrsto prehoda, vrsto tunela, način preverjanja pristnosti in operacijski sistem odjemalca. Profil IKEv2 s potrdilom in profil RADIUS spodletita iz različnih razlogov, odjemalec, zgrajen za drugo vrsto tunela, pa se poveže le, ko prehod ponudi združljiv protokol.

Za majhno ekipo je trajna zasnova en VNet, en DNS-forwarder in dokumentiran odjemalec s split tunnelingom. Če je zahteva fiksen javni izhod, zaključite tunel od mesta do mesta na požarnem zidu, ki ga nadzorujete, in tja usmerite internetni promet, namesto da bi od prehoda od točke do mesta zahtevali nekaj, za kar ni bil nikoli zgrajen.