Hindi inaayos ng NAT ng Azure VPN ang magkasapat na address ng VNet
Dalawang VNet na may parehong pribadong saklaw ay hindi kokonekta dahil lang may NAT. Tingnan muna ang uri ng koneksyon, pagkatapos ay muling bilangin o magmay-ari ng alyas ng pagsasalin.
Parehong gumagamit ang dalawang VNet ng 10.40.1.0/24, umaangat ang mga tunnel, at walang gumagana. Ang pagdaragdag ng pangalawang VPN gateway ay hindi iyon binabago, at ganoon din ang mas mababang sukatan ng ruta, dahil ang problema ay hindi pagpili ng landas. Dalawang workload na tumutugon sa parehong pribadong address ay nag-iiwan sa bawat packet ng malabong destinasyon at hindi maipapatunay na daan pabalik. Bago magplano ng anumang pagsasalin, alamin kung anong uri ng koneksyon ang aktwal na ginawa mo, dahil ang nag-iisang pagpipilian na iyon ang nagpapasya kung ang feature na NAT ng Azure ay magagamit man.
Ano ba talaga ang sinasabi sa iyo ng sintomas
Kapag may host sa VNet A na nagpapadala sa 10.40.1.10, ang talaan ng ruta ay maaari lamang itong ituro sa isang lugar. Kung may 10.40.1.10 din ang VNet B, ang address na iyon ay hindi destinasyong kayang makilala ng landas; isa itong address na may dalawang may-ari.
Ang pangalawang gateway na karaniwang inilalagay ng mga tao ay hindi tumutulong. Nagbibigay ito ng ibang tunnel, hindi ibang address, at ang nadobleng saklaw ay naglalakbay nang walang pagbabago sa loob ng tunnel. Dinodoble rin nito ang configuration na kailangan mong panatilihing pare-pareho. Ang hindi nito magagawa ay gawing isang address na nangangahulugang dalawang host.
Ang pagbabago ng pampublikong address ng mga peer ng VPN ay wala ring ginagawa. Ang mga address na iyon ang nagtutukoy sa mga dulo ng tunnel, samantalang ang banggaan ay nasa pribadong saklaw na dinadala sa loob nito.
Ang uri ng koneksyon ang nagpapasya kung available ang NAT
May kakayahan talagang NAT ang Azure VPN Gateway, at ito ay dokumentado para sa mga koneksyong IPsec sa pagitan ng mga site na nakabatay sa ruta sa mga partikular na SKU ng gateway. Ibinubukod ng parehong dokumento ang mga koneksyong VNet-to-VNet at point-to-site, kaya ang feature ay hindi isang kahon na lumilitaw sa bawat relasyon ng gateway.
| 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 |
Ang native na VNet-to-VNet ay nangangailangan din na ang mga saklaw ng VNet at lokal na network ay hindi magkasapat mula sa simula, na naaayon sa pagbubukod. Ang peering ng VNet ay hindi rin solusyon sa pagkasapat dahil sa parehong dahilan.
May sinusuportahang alternatibo na ipinagkakamali ng mga tao sa native na uri: imodelo ang kabilang VNet bilang lokal na network at ikonekta ito bilang koneksyong site-to-site. Iba itong resource at ibang disenyo, kaya ituring ang pinangalanang muli na koneksyon bilang pagbabagong kailangang patunayan, hindi bilang simpleng pagpapalit ng pangalan.
Muling bilangin, o isalin gamit ang isang bagay na nagmamay-ari ng alyas
Kung pareho sa iyo ang dalawang VNet, ihambing ang planadong muling pagbilang sa patuloy na gastos ng pagsasalin. Ang muling pagbilang ay humahawak sa configuration ng application, mga talaan ng DNS, mga patakaran sa seguridad at bawat umiiral na koneksyon, ngunit nag-iiwan ng network na normal na mababasa pagkatapos. Gawin ito nang isang subnet sa isang pagkakataon, na huli ang pagbabago sa DNS. Ang kalahating muling binilang na saklaw ay mas masama kaysa sa alinmang opsyon, dahil ang dalawang prefix ay mukhang may awtoridad sa sinumang susunod na magbasa ng talaan.
Kung saan hindi praktikal ang muling pagbilang, gumamit ng isinaling disenyo na may tunay na may-ari ng alyas. Maaaring maabot ng mga tumatawag sa VNet A ang 10.40.1.10 ng VNet B bilang 10.140.1.10, ngunit ang alyas na iyon ay nangangailangan ng aparatong nagsasalin, ruta patungo roon, at tugmang pag-uugali para sa tugon. Ang address na idinagdag lamang sa DNS ay hindi pagsasalin.
Itala ang dalawang saklaw sa dalawang direksyon: ano ang ini-dial ng tumatawag, ano ang nakikita ng destinasyon bilang pinagmulan, at aling panig ang maaaring magsimula. Kasama sa sariling mga patakaran ng NAT ng Azure ang baliktad na pagsasalin para sa kanilang mga mapping ng SNAT, kaya hindi ka nagsusulat ng tugmang patakaran ng DNAT sa kamay, ngunit ang kaginhawahang iyon ay nagtatapos sa mga uri ng koneksyong sinusuportahan ng feature.
Ano ang hindi gagana
Ang rutang tinukoy ng user o sukatan ng ruta ay hindi makakalikha ng kulang na pagkakaiba ng address. Pareho silang gumagana sa destinasyong malabo pa rin, at ang packet ay dumarating sa susunod na hop na pinipili ng talaan.
Ang pagdaragdag ng nadobleng saklaw sa talaan ng ruta bilang mas tiyak na prefix ay naglilipat lamang ng kalabuan nang isang hakbang. Madalas din nitong sirain ang kabilang direksyon, kung saan may dalawang malamang pinagmulan na ang tugon.
Tanggapin ang disenyo na may trapiko sa dalawang direksyon
Patunayan ang disenyo sa sariwang pinapayagang operasyon mula sa bawat panig, hindi sa kalagayan ng tunnel. Ang konektadong tunnel ng IPsec ay nagsasabing nagkasundo ang mga peer sa kriptograpiya; wala itong sinasabi kung naging makikilala ang mga destinasyon.
Pagkatapos ay patakbuhin ang mga tinanggihang landas: isang address na dapat manatiling hindi maabot, at isang serbisyong dapat harangan ng patakaran. Kung pareho pa ring nagtagumpay, ang pagsasalin ay mas malawak kaysa sa nilayon ng disenyo.
Tapusin sa mga fact na magpapaliwanag sa setup mamaya: ang orihinal na saklaw, ang inihandang saklaw, ang aparatong nagsasalin, at ang direksyong maaaring simulan ng bawat panig. Kung may kulang sa mga iyon, mamanahin ng susunod na inhinyero ang network kung saan dalawang host ang nagbabahagi ng isang pangalan at walang nakakaalala kung bakit tumutugon ang isa sa kanila.