AWS dan Azure ga sayt-sayt VPN: avval qaytish marshrutini yozing
Ikki bulut orasidagi ulangan tunnel har bir ish yuklamasi quyi tarmog‘i uzoq prefiksga yo‘naltirmaguncha hech narsani isbotlamaydi. Rejani tartib bilan bajaring, so‘ng xizmatni sinang.
Tunnel ko‘tariladi. Odatda shunday bo‘ladi, chunki IKE ga faqat mos takliflar va erishish mumkin bo‘lgan hamkor manzili kerak. Keyin muvaffaqiyatsiz bo‘ladigan narsa — qaytish yo‘li: AWS ish yuklamasi paketlarni tunnelga yuboradi, lekin Azure tomonida 10.10.0.0/16 ga qanday javob berishni hech kim bilmaydi yoki Azure marshruti ish yuklamasi quyi tarmog‘i ishlatmaydigan jadvalda turadi. Har qanday konsolga tegishdan oldin marshrut rejasini yozing, tunnel ishning eng kam qiziqarli qismiga aylanadi.
1-qadam: manzil rejasini muzlatib qo‘ying
Aniq qiymatlar bilan ishlang. AWS ish yuklamasi 10.10.0.0/16 ichida 10.10.1.20 da joylashgan va 10.20.0.0/16 ichidagi 10.20.1.30 dagi Azure xizmatiga TCP 443 kerak. Ikki oraliq ustma-ust tushmasligi kerak, qabul sinovi esa tunnel emas, xizmat juftligi.
Bu to‘rt faktni hamma narsadan oldin yozing, chunki har bir keyingi qadam ularga qarshi tekshiriladi.
2-qadam: har bir uchga egalik qiluvchi shlyuzni nomlang
AWS Site-to-Site VPN virtual xususiy shlyuzda yoki tranzit shlyuzda tugashi mumkin, va ular turli marshrutlash egalari. Azure o‘zining boshqariladigan VPN Gateway ini va alohida, mijozlar o‘zlari yuritadigan VM asosidagi qurilmalarni taklif qiladi. Qaysi juftlik borligini yozib qo‘ying, chunki keyingi sakrash har bir kombinatsiyada farq qiladi.
Boshqariladigan shlyuz uchun taxmin qilingan xususiy qurilma manziliga ishora qiluvchi marshrutni ko‘chirmang. Qurilma uchun bulutdagi marshrut tarqalishi mehmon operatsion tizimini sozlaydi deb o‘ylamang, chunki u buni qilmaydi.
Bu yerda xato qilish to‘liq ko‘rinadigan reja yaratadi va paketlarni hech qachon javob bermaydigan manzilga yuboradi.
3-qadam: har bir ish yuklamasi haqiqatan ishlatadigan marshrutni yozing
Quyidagi har bir chegara alohida qidiruvdir va ulardan biridagi marshrut paket uchun marshrut emas. Tunnel ishga tushishidan oldin jadvalni o‘z qiymatlaringiz bilan to‘ldiring.
| 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 da ish yuklamasi quyi tarmog‘ining marshrut jadvalini BGP yoki tunnel sog‘lom bo‘lgandan keyin ham siz yangilaysiz; marshrutlash sharhi buni ulanishning qismi deb hisoblaydi. Azure da foydalanuvchi belgilagan marshrut jadvali virtual tarmoqqa emas, quyi tarmoqqa bog‘lanadi, shuning uchun samarali marshrutni VNet panelida emas, ish yuklamasi NIC ida tekshiring.
Boshqariladigan Azure shlyuzi uzoq prefiksni shlyuz tarqalishi orqali o‘rganishi mumkin, UDR esa bu qarorni bekor qilishi mumkin. UDR ni sabab bo‘lganda qo‘shing, odat bo‘yicha emas. Qo‘shsangiz, qurilma manzilini o‘ylab topish o‘rniga shlyuz VPN yo‘li uchun e’lon qiladigan keyingi sakrashga yo‘naltiring. So‘ng NIC dagi samarali marshrutlarni qayta o‘qing, chunki qaror haqiqatda o‘sha yerda qabul qilinadi.
4-qadam: qamrovni moslashtiring
BGP uchun har bir tomon e’lon qilgan narsani boshqa tomon haqiqatan o‘rgangan narsa bilan prefiks bo‘yicha solishtiring. Statik marshrutlash uchun sozlangan uzoq oraliqlarni 3-qadamda yozgan ish yuklamasi marshrutlari bilan solishtiring.
Kriptografiya bo‘yicha kelishgan IKE munosabati biron tomon 10.10.0.0/16 yoki 10.20.0.0/16 ni o‘rganganiga dalil emas. Rejalashtirgan /16 o‘rniga bitta /24 e’lon qilinayotganda ikkita tunnel turishi mumkin. Prefiksni tunnel holatida emas, marshrutlash jadvalida tekshiring. Nomuvofiqlik keyin ishlaydigan bir quyi tarmoq va hech qachon javob bermaydigan boshqasi sifatida ko‘rinadi.
5-qadam: xizmatni haqiqiy manbadan sinang
Ko‘zda tutilgan oqimga AWS xavfsizlik guruhlarida va tarmoq ACL larida, Azure NSG larida va yo‘ldagi har qanday qurilma filtrzida ruxsat bering. So‘ng 10.10.1.20 dan tasdiqlangan xizmat manzili va portiga bitta ulanish oching va javob o‘sha manbaga qaytishini tasdiqlang.
Bulut xavfsizlik guruhlari ham, NSG lar ham holat saqlaydi, shuning uchun rad etilgan qaytish paketi marshrutlash alomatidir, teskari yo‘nalishda yozishni unutgan qoida emas.
Har qanday shlyuzdan ping hech narsani hal qilmaydi. Shlyuz manziliga ICMP boshqaruv tekisligi yo‘lini mashq qildiradi, ish yuklamasiga kerak bo‘lgan uzatilgan TCP xizmatini emas.
Orqaga qaytarish va yozuvlar
Marshrut egalarini tunnel identifikatorlari yoniga yozib qo‘ying va o‘zgarishdan oldingi marshrut jadvallarini saqlang. Agar o‘zgarishni olib tashlash kerak bo‘lsa, tunnelni buzishdan oldin ish yuklamasi marshrutlarini olib tashlang, shunda hech bir quyi tarmoq endi mavjud bo‘lmagan keyingi sakrashga ishora qilmaydi.
Shunda keyingi quyi tarmoq ko‘chirilishi yoki spoke ulanishi yangilash uchun bitta belgilangan joyga ega bo‘ladi, hech qachon o‘ziniki bo‘lmagan marshrut uchun aybni ko‘tarib yuruvchi ishlab turgan tunnel o‘rniga.