Azure punkto-al-ejo konektiĝas sed neniu privata rimedo respondas

Konektiteco estas stato de la tunelo, ne aserto pri atingeblo. Punkto-al-eja kliento povas fini IKE, ricevi adreson kaj tamen atingi nenion, ĉar la enirejo plusendas trafikon nur por retoj, kiujn la VNet jam konas. Trapasu ĉi tiujn kvin kontrolojn laŭvice kaj haltu ĉe la unua malsukceso. Antaŭensalti estas la maniero, per kiu DNS-problemo traktiĝas kiel fajromura problemo dum horo.

La ordo gravas pli ol la listo.

Kontrolo 1: decidi, kion la tunelo devas porti

Azure VPN Gateway finas la tunelon kaj plusendas trafikon, kiu apartenas al la VNet; ĝi ne estasĝenerala interreta elirejo. Se uzantoj atendas, ke ilia retumado eliru tra Azure, la dezajno estas malĝusta antaŭ ol ajna klienta agordo eniras la ludon. Ŝaltu split tunneling por ke la loka interreto daŭre uzu la lokan vojon, kaj uzu NAT-instancon aŭ ejo-al-ejan tunelon kiam firma elira adreso vere necesas.

Skribu, kion la kliento devas atingi antaŭ ol testi ion ajn. Sen tiu listo, ĉiu parta rezulto aspektas kiel progreso.

Kontrolo 2: komparu adresspacojn antaŭ atestiloj

Overlapeco estas juĝata laŭ la pli larĝaj intervaloj, do du retoj, kiuj aspektas malsamaj je subreta nivelo, tamen kolizias se iliaj patraj blokoj interkovriĝas. La enireja subreto devas esti dediĉita kaj sufiĉe granda por la SKU, kaj la klienta adresaro ne rajtas kolizii kun la VNet aŭ kun io atingebla trans peering. Ŝanĝu la planon kaj denove deploju, ĉar aldoni vojojn por kompensi produktas tunelon, kiu funkcias por iuj celoj kaj neklarigeble ne por aliaj. Provizado ja laŭte malsukcesas ĉi tie, kio estas la bona kazo.

Aŭtentigo estas la sekva pordo. Atestila, RADIUS kaj Entra ID-profiloj ne estas interŝanĝeblaj, kaj la klienta pakaĵo malsamas por ĉiu.

Kontrolo 3: solvu privatan nomon de interne

La kliento tenas sian propran solvilon krom se la elŝutita profilo portas la DNS-servilojn de la VNet, kaj tiu listo estas enkonstruita dum elŝuto. Aldonu plusendilon ene de la VNet, agordu ĝin kiel DNS-servilo de la VNet, poste elŝutu kaj importu la klientan pakaĵon denove. Reuzi la malnovan pakaĵon nur testas la malnovan solvilan liston.

Testu unue adreson, ĉar tio apartigas enkursigadon de nomado en unu paŝo: Test-NetConnection 10.20.1.4 -Port 3389.

Se la adreso respondas kaj la nomo ne, demandu la solvilon rekte per Resolve-DnsName files.corp.example -Server 10.20.0.4. Se ambaŭ malsukcesas, la fuŝo ne estas DNS kaj vi devus ĉesi redakti DNS-agordojn. La Azure-platforma DNS ĉe 168.63.129.16 respondas nur de interne de la VNet, do kliento ekstere ne povas uzi tiun adreson kiel solvilon.

Kontrolo 4: testu la servon malantaŭ la tunelo

Sana tunelo kaj fermita pordo aspektas idente de la kliento. Kontrolu la fajromuron de la gasto, poste la retan sekurecgrupon sur la subreto aŭ NIC, poste ĉu la servo aŭskultas ĉe la privata adreso anstataŭ nur ĉe loopback. Permesu la klientan aron kiel fonton anstataŭ malfermi regulon al la interreto, kaj memoru, ke SMB al Azure Files bezonas la vojon de la privata finpunkto enkursigitan tra la tunelo. Kiam rimedo respondas per IP sed ne per nomo, reiru al kontrolo 3 anstataŭ tuŝi la enirejon.

Unu tabelo tenas la tavolojn apartaj dum vi laboras:

Kontrolo 5: registru la profilon antaŭ ol eskali

Metu la enirejan tipon, tunelan tipon, aŭtentigan metodon kaj klientan operaciumon en la bileton. Atestila IKEv2-profilo kaj RADIUS-profilo malsukcesas pro malsamaj kialoj, kaj kliento konstruita por alia tunela tipo konektiĝas nur kiam la enirejo ofertas kongruan protokolon.

Por malgranda teamo la daŭra dezajno estas unu VNet, unu DNS-plusendilo kaj dokumentita split-tunnel-kliento. Se la postulo estas firma publika elirejo, finu ejo-al-ejan tunelon sur fajromuro, kiun vi kontrolas, kaj enkursigu la interretan trafikon tien anstataŭ peti de la punkto-al-eja enirejo ion, por kio ĝi neniam estis konstruita.