AWS-аас Azure руу сайт VPN: эхлээд буцах маршрутыг бич
Хоёр үүлний хоорондын холбогдсон туннель нь ажлын ачааллын дэд сүлжээ бүр алсын префикс рүү чиглэх хүртэл юу ч батлахгүй. Төлөвлөгөөг дарааллаар гүйцэтгээд дараа нь үйлчилгээг туршаарай.
Туннель өгсөх болно. Ихэвчлэн тийм болдог, учир нь IKE-д зөвхөн тохирох саналууд болон хүрэх боломжтой түншийн хаяг хэрэгтэй. Дараа нь бүтэлгүйтдэг зүйл бол буцах зам: AWS ачаалал пакетуудыг туннель руу илгээдэг ч Azure талд 10.10.0.0/16-д хэрхэн хариулахаа хэн ч мэдэхгүй, эсвэл Azure маршрут нь ажлын ачааллын дэд сүлжээ ашигладаггүй хүснэгтэд байна. Аль ч консолыг хүрэхээс өмнө маршрутын төлөвлөгөөг бич, тэгвэл туннель ажлын хамгийн сонирхолгүй хэсэг болно.
1-р алхам: хаягийн төлөвлөгөөг царцаа
Тодорхой утгуудтай ажиллаарай. AWS ачаалал 10.10.0.0/16 дотор 10.10.1.20 хаягт байгаа бөгөөд 10.20.0.0/16 дотор 10.20.1.30 хаягт байгаа Azure үйлчилгээ рүү TCP 443 хэрэгтэй. Хоёр муж давхцах ёсгүй, хүлээн авах шалгалт нь туннель биш, үйлчилгээний хос юм.
Тэр дөрвөн баримтыг бусад бүхнээс өмнө бичээрэй, учир нь дараагийн алхам бүр тэдгээртэй харьцуулагдана.
2-р алхам: хошуу тус бүрийг эзэмшдэг гарцыг нэрлэ
AWS Site-to-Site VPN виртуал хувийн гарц эсвэл дамжуулах гарц дээр дуусч болно, эдгээр нь өөр өөр чиглүүлэлтийн эзэд юм. Azure өөрийн удирдлагатай VPN Gateway болон тусдаа, хэрэглэгчид өөрсдөө ажиллуулдаг VM суурьтай төхөөрөмжүүдийг санал болгодог. Аль хос байгааг бичээрэй, учир нь дараагийн үсрэлт хослол бүрт өөр байна.
Удирдлагатай гарцын хувьд таамагласан хувийн төхөөрөмжийн хаяг руу заасан маршрутыг хуулах хэрэггүй. Төхөөрөмжийн хувьд үүлэн дэх маршрутын тархалт зочны үйлдлийн системийг тохируулдаг гэж бүү бод, учир нь тэгдэггүй.
Энд алдаа гаргавал бүрэн мэт харагдах төлөвлөгөө гарч, пакетуудыг хэзээ ч хариу өгдөггүй хаяг руу илгээнэ.
3-р алхам: ажлын ачаалал бүрийн бодитоор ашигладаг маршрутыг бич
Доорх хил бүр тусдаа хайлт бөгөөд тэдгээрийн нэг дэх маршрут нь пакетийн маршрут биш юм. Туннель ажиллахаас өмнө хүснэгтийг өөрийн утгуудаар бөглөөрэй.
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
AWS-д ажлын ачааллын дэд сүлжээний маршрутын хүснэгтийг BGP эсвэл туннель эрүүл болсны дараа ч өөрөө шинэчилнэ; чиглүүлэлтийн тойм үүнийг холболтын хэсэг гэж үздэг. Azure-д хэрэглэгчийн тодорхойлсон маршрутын хүснэгт нь виртуал сүлжээнд биш, дэд сүлжээнд холбогддог тул үр дүнтэй маршрутыг VNet хэсэгт биш, ажлын ачааллын NIC дээр шалгаарай.
Удирдлагатай Azure гарц нь гарцын тархалтаар алсын префиксийг сурч болох бөгөөд UDR тэр шийдвэрийг хүчингүй болгож чадна. UDR-ийг шалтгаан байгаа үед нэмээрэй, зуршилаар биш. Хэрэв нэмбэл, төхөөрөмжийн хаяг зохиохын оронд гарц VPN замд нийтэлдэг дараагийн үсрэлт рүү чиглүүлээрэй. Дараа нь NIC дээрх үр дүнтэй маршрутуудыг дахин уншаарай, учир нь шийдвэр үнэхээр тэнд гардаг.
4-р алхам: хамрах хүрээгээ тохируул
BGP-ийн хувьд тал бүрийн зарлаж буйг нөгөө тал бодитоор сурсантай префикс тус бүрээр харьцуул. Статик чиглүүлэлтийн хувьд тохируулсан алсын мужийг 3-р алхамд бичсэн ажлын ачааллын маршрутуудтай харьцуул.
Криптографын талаар санал нийлсэн IKE харилцаа нь аль нэг тал 10.10.0.0/16 эсвэл 10.20.0.0/16-г сурсан гэдгийн баталгаа биш. Төлөвлөсөн /16-ийн оронд ганц /24 зарлаж, хоёр туннель зогсож болно. Префиксийг туннелийн төлөвөөс биш, чиглүүлэлтийн хүснэгтээс шалгаарай. Зөрүү нь дараа нь ажилладаг нэг болон хэзээ ч хариу өгдөггүй нэг дэд сүлжээ хэлбэрээр илэрнэ.
5-р алхам: үйлчилгээг бодит эх сурвалжаас турш
Зорьсон урсгалыг AWS аюулгүй байдлын бүлэг болон сүлжээний ACL, Azure NSG, замд байгаа аливаа төхөөрөмжийн шүүлтүүрт зөвшөөрөөрэй. Дараа нь 10.10.1.20-оос зөвшөөрөгдсөн үйлчилгээний хаяг, порт руу нэг холболт нээж, хариу мөн тэр эх сурвалж руу буцаж байгааг батал.
Үүлний аюулгүй байдлын бүлэг болон NSG хоёулаа төлөвтэй, тиймээс татгалзсан буцах пакет нь чиглүүлэлтийн шинж тэмдэг бөгөөд эсрэг чиглэлд бичихээ мартсан дүрэм биш юм.
Аль ч гарцаас ping юу ч шийдэхгүй. Гарцын хаяг руу ICMP нь удирдлагын хавтгайн замыг дасгалжуулдаг, ажлын ачаалалд хэрэгтэй дамжуулагдсан TCP үйлчилгээг биш.
Буцаах болон бүртгэл
Маршрутын эздийг туннелийн танигчийн хажууд бичиж, өөрчлөлтөөс өмнөх маршрутын хүснэгтүүдийг хадгал. Хэрэв өөрчлөлтийг буцаах шаардлагатай бол туннелийг буулгахаас өмнө ажлын ачааллын маршрутуудыг устга, ингэснээр ямар ч дэд сүлжээ байхгүй болсон дараагийн үсрэлт рүү зааж үлдэхгүй.
Тэгвэл дараагийн дэд сүлжээний шилжилт эсвэл spoke холболтод шинэчлэх нэг тодорхой газар байна, хэзээ ч өөрийн байгаагүй маршрутын бурууг үүрсэн ажиллаж буй туннелийн оронд.