NAT de Azure VPN ne solvas koincidajn VNet-adresojn
Du VNet-oj kun la sama privata gamo ne konektiĝos simple ĉar NAT ekzistas. Unue kontrolu la konektotipon, poste renumeru aŭ posedu tradukan alinomon.
Ambaŭ VNet-oj uzas 10.40.1.0/24, la tuneloj ekfunkcias, kaj nenio funkcias. Aldoni duan VPN-pordon ne ŝanĝas tion, kaj ankaŭ ne pli malalta voja metriko, ĉar la problemo ne estas voja elekto. Du laborŝarĝoj respondantaj al la sama privata adreso lasas ĉiun pakaĵon kun ambigua celo kaj nekonfirmebla revena vojo. Antaŭ ol plani ajnan tradukon, eltrovu kiun konektotipon vi efektive kreis, ĉar tiu sola elekto decidas ĉu la NAT-funkcio de Azure entute disponeblas.
Kion la simptomo vere diras al vi
Kiam gastiganto en VNet A sendas al 10.40.1.10, la enkursigilo nur povas montri ĝin ien. Se VNet B ankaŭ enhavas 10.40.1.10, tiu adreso ne estas celo kiun la vojo povas distingi; ĝi estas unu adreso kun du posedantoj.
La dua pordo, kiun homoj kutime deplojas, ne helpas. Ĝi donas al vi alian tunelon, ne alian adreson, kaj la duobla gamo vojaĝas senŝanĝe ene de la tunelo. Ĝi ankaŭ duobligas la agordon, kiun vi devas teni konsekvenca. Kion ĝi ne povas, estas igi unu adreson signifi du gastigantojn.
Ŝanĝi la publikajn adresojn de la VPN-kunuloj ankaŭ nenion faras. Tiuj adresoj identigas la finpunktojn de la tunelo, dum la kolizio estas en la privata gamo portata interne.
La konektotipo decidas ĉu NAT disponeblas
Azure VPN Gateway ja havas NAT-kapablon, kaj ĝi estas dokumentita por route-based IPsec-interlokaj konektoj sur specifaj pordaj SKU-oj. La sama dokumentaro ekskludas VNet-to-VNet kaj point-to-site konektojn, do la funkcio ne estas markobutono aperanta en ĉiu porda rilato.
| Connection type | NAT support | Overlap workaround |
|---|---|---|
| Site-to-Site (route-based IPsec, documented SKUs) | Supported with configured NAT rules | Translate the range in the rules |
VNet-to-VNet (Vnet2Vnet) | Not supported | Renumber, or redesign as a site-to-site connection |
| Point-to-site | Not supported | Choose client address pools that do not collide |
Denaska VNet-to-VNet ankaŭ postulas, ke la gamoj de VNet kaj loka reto ne koincidu dekomence, kio kongruas kun la ekskludo. VNet-peering ankaŭ ne estas solvo por koincido pro la sama kialo.
Ekzistas subtenata alternativo, kiun homoj konfuzas kun la denaska tipo: modeligu la alian VNet kiel lokan reton kaj konektu ĝin kiel interlokan ligon. Tio estas alia rimedo kaj alia dezajno, do traktu alinomitajn konekton kiel ŝanĝon por validigi, ne kiel alinomadon.
Renumeru, aŭ traduku per io, kio posedas la alinomon
Se ambaŭ VNet-oj estas viaj, komparu planitan renumeradon kun la daŭra kosto de tradukado. Renumerado tuŝas aplikaĵan agordon, DNS-rikordojn, sekurecajn regulojn kaj ĉiun ekzistantan konekton, sed ĝi lasas reton, kiu poste legeblas normale. Faru ĝin unu subreto samtempe, kun la DNS-ŝanĝo laste. Duone renumerita gamo estas pli malbona ol ambaŭ opcioj, ĉar tiam ambaŭ prefiksoj aspektas aŭtoritataj por kiu ajn legos la tabelon poste.
Kie renumerado ne praktikas, uzu tradukitan dezajnon kun reala posedanto de la alinomo. Vokantoj en VNet A povas atingi 10.40.1.10 de VNet B kiel 10.140.1.10, sed tiu alinomo bezonas aparaton, kiu tradukas, vojon al ĝi, kaj kongruan konduton por la respondo. Adreso aldonita nur al DNS ne estas traduko.
Registru ambaŭ gamojn en ambaŭ direktoj: kion la vokanto tajpas, kion la celo vidas kiel fonton, kaj kiun flankon rajtas iniciati. La propraj NAT-reguloj de Azure inkluzivas la inversan tradukon por siaj SNAT-mapoj, do vi ne skribas kongruan DNAT-regulon permane, sed tiu komforto haltas ĉe la konektotipoj, kiujn la funkcio subtenas.
Kio ne funkcios
Uzanto-difinita vojo aŭ voja metriko ne povas krei mankantan adresan distingon. Ambaŭ funkcias sur celo ankoraŭ ambigua, kaj la pakaĵo alvenas al kiu ajn sekva salto la tabelo preferas.
Aldoni la duoblan gamon al enkursiga tabelo kiel pli specifan prefikson nur movas la ambiguecon unu paŝon. Ĝi ankaŭ emas rompi la alian direkton, kie la respondo nun havas du verŝajnajn fontojn.
Akceptu la dezajnon kun trafiko en ambaŭ direktoj
Pruvu la dezajnon per freŝa permesita operacio de ĉiu flanko, ne per tunela stato. Konektita IPsec-tunelo diras, ke la kunuloj konsentas pri kriptografio; ĝi diras nenion pri tio, ĉu la celoj fariĝis distingeblaj.
Poste rulu la malpermesitajn vojojn: adreson, kiu devas resti neatingebla, kaj servon, kiun la politiko devas bloki. Se ambaŭ ankoraŭ sukcesas, la traduko estas pli larĝa ol la dezajno intencis.
Fermu per la faktoj, kiuj klarigos la agordon poste: la origina gamo, la prezentata gamo, la aparato, kiu tradukas, kaj la direkto, kiun ĉiu flanko rajtas iniciati. Se io el tio mankas, la sekva inĝeniero heredas reton, kie du gastigantoj kunhavas nomon kaj neniu memoras kial unu el ili respondas.