Azure VPN-ийн NAT давхцсан VNet хаягийг шийдэхгүй
Ижил хувийн мужид байгаа хоёр VNet нь зөвхөн NAT байгаа учраас холбогдохгүй. Эхлээд холболтын төрлийг шалгаад дараа нь дахин дугаарлана уу эсвэл орчуулгын өөр нэрийг эзэмшээрэй.
Хоёр VNet хоёулаа 10.40.1.0/24-г ашигладаг, туннелиуд босдог ч юу ч ажиллахгүй. Хоёр дахь VPN гарцыг нэмэх нь үүнийг өөрчлөхгүй, доогуур маршрутын хэмжүүр ч өөрчлөхгүй, учир нь асуудал зам сонголтод биш. Нэг хувийн хаягт хариулж буй хоёр ажлын ачаалал пакет бүрийг хоёрдмол утгатай очих газар болон баталгаажуулах боломжгүй буцах замаар үлдээдэг. Аливаа орчуулгыг төлөвлөхөөс өмнө та яг ямар холболтын төрөл үүсгэснээ олж мэдээрэй, учир нь энэ ганц сонголт нь Azure-ийн NAT боломж огт байгаа эсэхийг шийднэ.
Энэ шинж тэмдэг танд юу гэж хэлж байна
VNet A дахь хост 10.40.1.10 руу илгээхэд маршрутын хүснэгт зөвхөн хаа нэг рүү чиглүүлж чадна. VNet B мөн 10.40.1.10 агуулж байвал тэр хаяг нь зам ялгаж чадах очих газар биш; энэ нь хоёр эзэмшигчтэй нэг хаяг юм.
Хүмүүсийн ихэвчлэн байрлуулдаг хоёр дахь гарц тус болохгүй. Энэ нь өөр туннель өгдөг, өөр хаяг биш, давхардсан муж нь туннелийн дотор өөрчлөгдөлгүй явдаг. Энэ нь бас тууштай барих ёстой тохиргоог хоёр дахин нэмэгдүүлдэг. Үүний хийж чадахгүй зүйл бол нэг хаяг хоёр хостыг илэрхийлэх явдал юм.
VPN үе тэнгийнхний нийтийн хаягийг өөрчлөх нь ч юу ч хийдэггүй. Тэдгээр хаягууд туннелийн төгсгөлийн цэгүүдийг тодорхойлдог, харин мөргөлдөөн нь дотор нь тээвэрлэгдэж буй хувийн мужид байна.
NAT боломжтой эсэхийг холболтын төрөл шийднэ
Azure VPN Gateway үнэхээр NAT боломжтой бөгөөд энэ нь тодорхой гарцын SKU дээр маршрутад суурилсан IPsec сайт хоорондын холболтод зориулагдсан баримт бичигтэй. Мөн баримт бичиг нь VNet-to-VNet болон point-to-site холболтыг оруулахгүй, тиймээс энэ боломж нь гарцын харилцаа бүрт гарч ирдэг чагт биш юм.
| 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 |
Уугуул VNet-to-VNet нь VNet болон локал сүлжээний мужууд эхнээсээ давхцахгүй байхыг шаарддаг бөгөөд энэ нь хасалттай нийцдэг. Мөн VNet-ийн хослол нь ижил шалтгаанаар давхцлын шийдэл биш юм.
Хүмүүсийн уугуул төрөлтэй андуурдаг дэмжигдсэн хувилбар байдаг: нөгөө VNet-ийг локал сүлжээ гэж загварчилж, сайт хоорондын холболт болгон холбох. Энэ нь өөр нөөц, өөр дизайн тул нэр сольсон холболтыг зүгээр л нэр солих биш, баталгаажуулах ёстой өөрчлөлт гэж үзээрэй.
Дахин дугаарлана уу, эсвэл өөр нэрийг эзэмшдэг зүйлээр орчуулаарай
Хоёр VNet чинь бол төлөвлөсөн дахин дугаарлалтыг орчуулгын тогтмол зардалтай харьцуул. Дахин дугаарлалт нь програмын тохиргоо, DNS бичлэг, аюулгүй байдлын дүрэм, одоо байгаа холболт бүрт хүрдэг боловч дараа нь хэвийн уншигдах сүлжээг үлдээдэг. Үүнийг нэг удаад нэг дэд сүлжээгээр хий, DNS өөрчлөлт хамгийн сүүлд байг. Хагас дахин дугаарласан муж нь аль ч сонголтоос муу, учир нь тэр үед хоёр угтвар нь хүснэгтийг дараа унших хүнд эрх мэдэлтэй мэт харагддаг.
Дахин дугаарлалт практик биш газарт өөр нэрийн бодит эзэмшигчтэй орчуулсан дизайн ашигла. VNet A дахь дуудагчид VNet B-ийн 10.40.1.10-д 10.140.1.10 болж хүрч болох боловч тэр өөр нэрэнд орчуулдаг төхөөрөмж, түүн рүү очих маршрут, хариултад тохирох зан үйл хэрэгтэй. Зөвхөн DNS-д нэмсэн хаяг нь орчуулга биш.
Хоёр мужийг хоёр чиглэлд бичиж тэмдэглэ: дуудагч юу залгадаг, очих газар эх сурвалж гэж юу хардаг, аль тал эхлүүлж болох. Azure-ийн өөрийн NAT дүрэм нь SNAT зураглалынхаа урвуу орчуулгыг агуулдаг тул та тохирох DNAT дүрмийг гараар бичихгүй, гэхдээ энэ тав тух нь боломжийн дэмждэг холболтын төрлүүдэд дуусдаг.
Юу ажиллахгүй вэ
Хэрэглэгчийн тодорхойлсон маршрут эсвэл маршрутын хэмжүүр нь дутуу хаягийн ялгааг үүсгэж чадахгүй. Хоёулаа одоо ч хоёрдмол утгатай очих газар дээр ажилладаг бөгөөд пакет нь хүснэгтийн илүүд үздэг дараагийн алхамд хүрдэг.
Давхардсан мужийг илүү тодорхой угтвар болгон маршрутын хүснэгтэд нэмэх нь хоёрдмол утгыг ердөө нэг алхам зөөдөг. Энэ нь мөн эсрэг чиглэлийг эвдэх хандлагатай, учир нь хариулт одоо хоёр магадлалтай эх сурвалжтай.
Дизайныг хоёр чиглэлийн трафикаар хүлээн зөвшөөр
Дизайныг туннелийн төлөвөөр бус, тал бүрээс шинэ зөвшөөрөгдсөн үйлдлээр нотол. Холбогдсон IPsec туннель нь үе тэнгийнхэн криптографид санал нийлсэн гэж хэлдэг; очих газрууд ялгаатай болсон эсэхийг энэ нь юу ч хэлэхгүй.
Дараа нь хориглосон замуудыг ажиллуул: хүрэх боломжгүй хэвээр байх ёстой хаяг, бодлого блоклох ёстой үйлчилгээ. Хоёулаа одоо ч амжилттай бол орчуулга нь дизайны зорьсноос өргөн байна.
Дараа нь энэ тохиргоог тайлбарлах баримтуудаар дуусга: анхны муж, танилцуулсан муж, орчуулдаг төхөөрөмж, тал бүр эхлүүлж болох чиглэл. Эдгээрийн аль нэг нь дутуу бол дараагийн инженер хоёр хост нэг нэрийг хуваалцдаг, яагаад нэг нь хариулдагийг хэн ч санахгүй сүлжээг өвлөн авна.