Azure punkt-í-svæði tengist en engin einkaaðföng svara

Tengt er ástand ganganna, ekki fullyrðing um aðgengi. Punkt-í-svæði biðlari getur lokið IKE, fengið vistfang og samt náð engu, því gáttin sendir aðeins umferð fyrir net sem VNet þekkir þegar. Farðu í gegnum þessar fimm athuganir í röð og stoppaðu við fyrstu bilun. Að stökkva framhjá er leiðin sem DNS-vandamál er meðhöndlað sem eldveggsvandamál í klukkustund.

Röðin skiptir meira máli en listinn.

Athugun 1: ákveðu hvað göngin eiga að bera

Azure VPN Gateway endar göngin og sendir áfram umferð sem tilheyrir VNet; það erekki almenn internetútgangur. Ef notendur búast við að vafrið fari út um Azure er hönnunin röng áður en nokkur biðlalastilling kemur við sögu. Kveiktu á split tunneling svo staðbundið internet haldi staðbundinni leið, og notaðu NAT-tilvik eða svæði-í-svæði göng þegar föst útgangsvistfang er raunverulega nauðsynleg.

Skrifaðu niður hvað biðlarinn á að ná til áður en þú prófar nokkuð. Án þess lista lítur hvert hlutaútkoma út eins og framför.

Athugun 2: berðu saman vistfangsbil áður en vottorðin koma

Skörun er metin á breiðari bilsins, svo tvö net sem líta ólík út á undirnetsstigi rekast samt á ef yfirblokkir þeirra skarast. Gáttarundirnetið verður að vera sérstakt og nógu stórt fyrir SKU, og vistfangasafn biðlarans má ekki rekast á VNet eða neitt sem næst í gegnum peering. Breyttu áætluninni og settu upp aftur, því að bæta við leiðum til að vega upp á móti býr til göng sem virka fyrir sum markmið og óútskýranlega ekki fyrir önnur. Uppsetning mistekst hér hátt, sem er góða tilfellið.

Auðkenning er næsta hlið. Vottorðs-, RADIUS- og Entra ID-snið eru ekki skiptanleg, og biðlapakkinn er ólíkur fyrir hvert þeirra.

Athugun 3: leystu einkaaðila nafn að innan

Biðlarinn heldur sínum eigin leysi nema sótt snið beri DNS-þjóna VNet, og sá listi er innfelldur við niðurhal. Bættu forwarder við innan VNet, stilltu hann sem DNS-þjón VNet, sóttu síðan og fluttu biðlapakkann inn aftur. Endurnotkun gamla pakkans prófar aðeins gamla leysalistann.

Prófaðu fyrst vistfang, því það aðskilur leiðslu frá nafngjöf í einu skrefi: Test-NetConnection 10.20.1.4 -Port 3389.

Ef vistfangið svarar og nafnið ekki, spurðu leysinn beint með Resolve-DnsName files.corp.example -Server 10.20.0.4. Ef bæði mistekst er bilunin ekki í DNS og þú ættir að hætta að breyta DNS-stillingum. DNS Azure-vettvangsins á 168.63.129.16 svarar aðeins að innan VNet, svo biðlari utan þess getur ekki notað það vistfang sem leysi.

Athugun 4: prófaðu þjónustuna bak við göngin

Heil göng og lokuð gátt líta eins út frá biðlaranum. Athugaðu eldvegg gestsins, síðan netöryggishópinn á undirnetinu eða NIC, síðan hvort þjónustan hlustar á einkavistfanginu frekar en aðeins á loopback. Leyfðu biðlasafninu sem uppruna í stað þess að opna reglu út á internetið, og mundu að SMB til Azure Files þarf leið einkatengipunktsins í gegnum göngin. Þegar auðlind svarar með IP en ekki með nafni, farðu aftur í athugun 3 í stað þess að snerta gáttina.

Ein tafla heldur lögunum aðskildum meðan þú vinnur:

Athugun 5: skráðu sniðið áður en þú eskalerar

Settu gáttartegund, gangategund, auðkenningaraðferð og stýrikerfi biðlarans í miðann. Vottorðs-IKEv2-snið og RADIUS-snið mistakast af ólíkum ástæðum, og biðlari sem byggður er fyrir aðra gangategund tengist aðeins þegar gáttin býður samhæft samskiptareglur.

Fyrir lítinn hóp er varanlega hönnunin eitt VNet, einn DNS-forwarder og skjalfestur split-tunnel biðlari. Ef krafan er föst opinber útleið, endaðu svæði-í-svæði göng á eldvegg sem þú stjórnar og beindu internetumferðinni þangað í stað þess að biðja punkt-í-svæði gáttina um eitthvað sem hún var aldrei byggð fyrir.