AWS Site-to-Site VPN'dan NAT Gateway'gacha: VGW yoki Transit Gateway

Birinchi marta hamma bir xil diagramma chizadi: VPN VPC'ga, so'ng NAT gateway orqali internetga, tamom. Ammo VPN virtual private gateway'da tugaganda AWS bu yo'lni qo'llab-quvvatlamaydi va xato shunchalik jim bo'ladiki, jamoalar uni bir necha marta qaytadan quradi. Ishlaydigan loyiha transit gateway talab qiladi, bu esa ikki tomondagi gateway va route jadvallarini o'zgartiradi. Biror narsa chizishdan oldin ikki shaklni solishtiring.

Ko'rinishda ravshan, ammo qo'llab-quvvatlanmaydigan topologiya

AWS'ning NAT gateway hujjatlari faqat bitta VPC loyihasini qurgan har kimni hayratga soladigan chiziq tortadi: Site-to-Site VPN ulanishidan kelayotgan trafikni virtual private gateway orqali NAT gateway'ga yo'naltirib bo'lmaydi. VPN qaysi gateway turida tugashi tarjima yo'li bor-yo'qligini belgilaydi. Xato saqlanib qoladi, chunki tunnel holati UP va o'sha subnetdagi EC2 instansiya internetga muammosiz yetadi. Bu ikki kuzatuvning hech biri buzilgan yo'nalishni tekshirmaydi.

Amalda paket mahalliy tarmoqning manba manzili bilan keladi va uni tarjima qiladigan qo'llab-quvvatlanadigan keyingi hop topilmaydi. Jadvallarga qarab u chiqish chegarasida tashlanadi, tunnel UP bo'lib qoladi va o'sha subnetdagi instansiya internetga yetadi, shuning uchun xato mahalliy firewall muammosi deb xabar qilinadi.

Virtual private gateway va transit gateway

Virtual private gateway bitta VPC'ga tegishli. U VPN'ni tugatadi, o'sha VPC'ning route jadvallariga route'larni o'rnatadi va shu yerda to'xtaydi. Unda attachment modeli yo'q, shuning uchun trafikni boshqa VPC'ga yoki umumiy chiqish segmentiga bera olmaydi. Butun cheklov shu bitta VPC doirasidir va VPC ichida qo'shilgan hech qanday route buni o'zgartirmaydi.

Transit gateway mintaqaviy markaz bo'lib, unda VPN, har bir spoke VPC va umumiy xizmatlar VPC'si attachment sifatida ko'rinadi. Uning o'z route jadvallari bor va ular berilgan prefix'ni qaysi attachment olishini tanlaydi.

Aynan shu markaz markazlashgan chiqishni mumkin qiladi: VPN bitta attachment bo'lib tushadi, chiqish VPC boshqasi bo'lib, transit gateway route jadvali internetga qaratilgan prefix'larni birinchisidan ikkinchisiga yuboradi. virtual private gateway bilan yuborish uchun ikkinchi attachment yo'q, shuning uchun loyihani keyinchalik yamab bo'lmaydi.

Qo'llab-quvvatlanadigan chiqish yo'li, hopma-hop

Namunaviy loyihada besh hop bor va har bir o'q siz sozlashingiz kerak bo'lgan route qaroridir. Trafik mahalliy tarmoqdan Site-to-Site VPN attachment'iga chiqadi, transit gateway jadvali uni chiqish VPC attachment'iga uzatadi, u yerda subnet jadvali uni ommaviy NAT gateway'ga yuboradi. NAT gateway manbani tarjima qiladi, internet gateway paketni tashqariga olib chiqadi.

On-premises network
  -> Site-to-Site VPN attachment on the transit gateway
  -> transit gateway route table
  -> egress VPC attachment
  -> public NAT gateway in that VPC
  -> internet gateway

Oxirgi hop'lar ishlashini ikki tafsilot hal qiladi. NAT gateway ommaviy bo'lishi, elastic IP va internet gateway'ga route bo'lishi kerak, chunki xususiy NAT gateway tarmoqlar orasida tarjima qiladi va hech qachon internet chiqishi bo'lmaydi.

Xizmat ko'rsatmoqchi bo'lgan har bir Availability Zone uchun bitta NAT gateway rejalashtiring va har bir subnet jadvali mahalliyga ishora qilsin. Eslatmalaringizda transit gateway jadvali va VPC jadvallarini alohida obyektlar sifatida saqlang, chunki biri attachment, ikkinchisi VPC ichidagi resursni tanlaydi. Faqat bittasida default route bo'lsa, yo'lning yarmi aniqlanmagan qoladi va sababini bog'lash eng qiyin bo'lgan qismiy nosozliklar paydo bo'ladi.

Bu loyihalar aynan qaytish yo'lida barbod bo'ladi

NAT gateway ko'rgan oqimlar uchun holatni saqlaydi, shuning uchun chiqish ulanishiga javoblar yangi kirish qoidasisiz qaytadi. Bu xususiyat mahalliy xizmatni internetda e'lon qilmaydi va uni shunday deb hisoblash jamoaga hech qachon o'rnatilmaydigan ulanishni debug qilishda bir kun sarflaydi. Mijoz boshlagan trafik uchun to'rt route kelishishi kerak: mahalliy siyosat, transit gateway jadvali, chiqish subnet jadvali va NAT subnet jadvali. Oxirgisi tushib qolsa, so'rov binodan chiqadi, javob esa AWS ichida o'ladi.

VPN orqasidagi haqiqiy mijoz bilan tekshiring va u qaysi ommaviy manba manzilini ko'rsatishini ko'ring. Agar u NAT gateway'ning elastic IP'si bo'lsa, tarjima ketmoqda; boshqa narsa bo'lsa, boshqa chiqishni o'lchayapsiz.

Bu nosozlikning asimmetrik ko'rinishini erta tanigan ma'qul. Bir Availability Zone'ning NAT subnet jadvalida mijoz prefix'iga qaytish route'i bo'lib, boshqasida bo'lmasa, yangi ulanishlar oqim tushadigan zonaga qarab muvaffaqiyatli yoki muvaffaqiyatsiz bo'ladi va bu naqsh noturg'un internet deb noto'g'ri o'qiladi. Chipta ochilgan zonani tuzatish o'rniga xizmat ko'rsatadigan har bir zonaning subnet jadvallarini solishtiring, chunki yetishmayotgan route butun nuqson va narigi tomonda hech narsa o'zgartirish shart emas.

Qachon ochiq proxy yaxshiroq loyiha bo'ladi

Chiqish VPC'sidagi instansiyada HTTP proxy qonuniy alternativa va ko'pincha arzonroq. Mijozlar undan foydalanishga sozlanadi, proxy o'z ulanishini tashqariga ochadi va qaytish yo'li simmetrik route jumbog'i emas, uning muammosi bo'ladi. Bir nechta dastur uchun bu transit gateway ishining katta qismini olib tashlaydi. Shuningdek NAT gateway ishlab chiqara olmaydigan foydalanuvchi bo'yicha jurnal beradi.

Biroq u shaffof emas. Proxy sozlamalarini e'tiborsiz qoldiradigan har qanday narsa va HTTP bo'lmagan har bir protokol bu yo'ldan ketmaydi.

Tanlov dasturlaringiz aslida nima bilan gaplashishiga va jurnallarda qancha identifikatsiya kerakligiga bog'liq. Ular HTTP bilan gaplashadigan joyda proxy o'z o'rnini oladi; ixtiyoriy protokollar uchun umumiy chiqish kerak bo'lsa, AWS qo'llab-quvvatlaydigan loyiha transit gateway. Buni oldindan hal qilish route jadvallari qurilgandan keyin aniqlashdan arzon.