Google HA VPN'dan Cisco routergacha: avval peer resursini rejalashtiring
Cisco routerni sozlashdan oldin Google'ning ikkala interfeysi, peer resursi, IKEv2 shartnomasi va har bir BGP sessiyasini nomlang, so'ng bitta peer yoki ikkitasini tanlang.
Cisco'dan Google'ga HA VPN'da birinchi qaror qaysi kripto profilidan foydalanish emas, balki tunnellarni bitta joyidagi qurilma yoki ikkitasi tugatishi. Google'ning HA VPN shlyuzi ikkita interfeysga ega va har biri mos keluvchi peer tunnelini kutadi. Bu sizga ikkita routeringiz bo'lishidan qat'i nazar ikkita tunnel beradi, farq esa bitta quvvat manbai yoki dasturiy yangilanish butun dizaynni yiqita oladimi-yo'qmi.
Qaror bitta peer qurilma yoki ikkita
Joylashuvni uchta shart asosida tanlang: mahalliy nosozlik nuqtasini qabul qila olasizmi, ikkala bulut interfeysi ishlatilishi kerakmi va ish yuklaringiz qancha qayta yaqinlashuvga chidaydi. Agar uchtadan biri qat'iy talab bo'lsa, ikkita peer qurilma halol javob.
Konsolni ochishdan oldin buni hal qiling, chunki javob ish varag'i qancha tunnel va BGP sessiyasini tasvirlashi kerakligini o'zgartiradi.
Har qanday buyruqdan oldin ish varag'ini yozing
Ish varag'ida beshta qator bor va har biriga egasi kerak:
| Row | What it records |
|---|---|
| Google side | Project, VPC, region, HA VPN gateway, and the external address of each interface |
| Peer side | The Cisco external addresses, plus the external peer VPN gateway resource that represents them |
| Tunnel pairs | Which peer interface maps to each Google interface, with IKE version, secret and crypto parameters |
| Routing | Cloud Router, local and remote AS numbers, and one inside BGP pair per tunnel |
| Workloads | Approved on-premises and VPC prefixes, and what firewall policy should permit between them |
Tashqi peer resursi Google Cloud ichidagi interfeyslaringizni tavsiflaydi va uni yaratish Cisco routerni sozlamaydi. Bu nosimmetriklik bulut konsoli ikkala uchi uchun haqiqat manbai bo'ladi deb kutganlarni ajablantiradi. Bu Google nima kutishi kerakligi haqidagi bayonot va router hali ham unga mos kelishi kerak. Google'ning peer shlyuzi qo'llanmasi bu bayonotni siz hali qilishingiz kerak bo'lgan tunnel, BGP, firewall va IKE ishiga bog'laydi.
Agar qatorda egasi bo'lmasa, uni o'tish paytida smenada bo'lgan kishi to'ldiradi.
Uchta manzil rolini alohida saqlang
Ommaviy peer manzillari tashqi IPsec almashinuvini olib boradi. Ichki BGP juftligi uning ustida ishlaydigan himoyalangan mantiqiy ulanishga tegishli. E'lon qilingan LAN va VPC prefikslari shu ulanish orqasidagi ish yuklarini tavsiflaydi. VM'ning ichki manzilini tashqi peer maydoniga ko'chirish birinchi ikkita rolni aralashtiradi va nosozlik ma'lumot kiritish xatosi emas, muzokara muammosi kabi ko'rinadi.
Har bir HA VPN interfeysi uchun bittadan ikkita mos peer tunnelini rejalashtiring. Ikkala bulut interfeysidan foydalanish mahalliy nosozlik nuqtasini o'z-o'zidan yo'q qilmaydi, chunki ikkala tunnel ham bitta shassisga tushishi mumkin.
Ish varag'idagi har bir qiymat yoniga manzil rolini yozing. Shu bitta odat aralashishning ko'p qismini oldini oladi.
Ish varag'ini Cisco reliziga o'tkazing
Platformangiz uchun qo'llab-quvvatlanadigan peer hujjatlaridan yoki mos Google konfiguratsiya shablonidan boshlang, so'ng har bir to'ldiruvchini ish varag'i bilan moslang. IKEv2 autentifikatsiyasi, ESP takliflari, PFS va tunnel hamda marshrutlash modelini birgalikda tekshiring, chunki ulardan biridagi nomuvofiqlik odatda boshqasidagi nomuvofiqlik sifatida ko'rinadi. Nima qo'llab-quvvatlanishini tanlash uchun haqiqiy platforma va dasturiy ta'minot relizidan foydalaning, chunki Classic VPN retsepti boshqa boshlang'ich nuqta.
Umumiy sirni ekran suratlari, chipta ilovalari va qo'llab-quvvatlash eslatmalaridan uzoq tuting. Case izohiga yopishtirilgan oldindan umumiy kalit — bu hisob ma'lumotlarining oshkor bo'lishi, muammolarni bartaraf etish artefakti emas.
Agar shablon va ish varag'i kelishmasa, to'xtang va uni qog'ozda hal qiling. Qurilma sizning nomingizdan hukm chiqarmaydi.
Har bir tunnelni o'z daliliga ko'ra qabul qiling
HA VPN BGP sessiyalarini talab qiladi va muvaffaqiyatli IKE muzokarasi faqat birinchi bosqichni o'rnatadi. Ichki sessiya ko'tarilishi, mo'ljallangan prefikslar e'lon qilinishi va qabul qilinishi, ish yuki trafigi harakatlanishidan oldin foydali marshrutlar va firewall ruxsatlari mavjud bo'lishi kerak. Bularning barchasini bitta yashil chiroq sifatida qayd etish qaysi bosqich haqiqatan muvaffaqiyatsiz bo'lganini yashiradi.
Har bir tunnel uchun qabul dalillarini yozib boring: muzokara qilingan xavfsizlik assotsiatsiyalari, BGP qo'shnisi holati, kutilgan o'rganilgan prefikslar va mo'ljallangan ish yuki yo'li. So'ng boshqariladigan nosozlik va tiklash tekshiruvini o'tkazing, chunki hech qachon nosozlik bo'lmagan tunnel — tiklash yo'li sinovdan o'tmagan tunnel.
Bu yozuv keyingi safar dizayn o'zgarganda qayta ishlatilishi mumkin va bu hamkorlik bilan taxminlari yo'qolgan buyruq parchasi o'rtasidagi farq.