Mahalliy tarmoq Cloud VPN orqali VPC ga yetganda, Compute Engine xizmati uchun manzil odatda VM ning ichki manzili bo'ladi. Tashqi IPv4 manzil o'sha xususiy yo'lga qo'yish mumkin bo'lgan ikkinchi manzil emas. Bu sohadagi chalkashlikning ko'p qismi uch vazifali uch manzilni bir-birining o'rnida ishlatish mumkin deb qarashdan kelib chiqadi, shuning uchun avval ma'lum bir paket qaysinisini ishlatishini nomlashdan boshlang.

Uch manzil, uch vazifa

Ularning har qaysisini tuzatishdan oldin uchtasini ham nomlang, chunki javob keyingi tekshiradigan ob'ektingizni o'zgartiradi.

AddressJob
Cloud VPN endpointwhere the IPsec peers meet
Internal IPthe address your route and firewall must name
External IPv4the platform's inbound mapping, not a guest address

Birinchisi tunnelga tegishli. Ikkinchisi yo'l va xavfsizlik devori dizayningizga tegishli. Uchinchisi kiruvchi internet kirishiga tegishli va u xaritaga olinadi, ulanmaydi. Ulardan biriga ishlaydigan dizayn qolgan ikkitasi haqida hech narsa demaydi.

Nima uchun tashqi manzil ikkinchi interfeys emas

Manzillash qo'llanmasi Compute Engine da ichki va tashqi yetib borish qanday farq qilishi bo'yicha vakolatli manbadir. Compute Engine ning tashqi IPv4 manzili instansiyaning yagona ichki NIC iga birga-bir xaritalashdir, shuning uchun mehmon o'sha NIC da hech qachon ikkinchi interfeys yoki ikkinchi manzilni ko'rmaydi. VM ichkaridan xabar qiladigan narsa hanuz bitta asosiy ichki manzildir.

Shu sababli xususiy mijoz tunnel orqali 10.24.1.7 manziliga yo'naltirsa, va VM ning tashqi manzilini nishonga olgan mijoz turli yo'llarda bo'ladi. Ommaviy manzil uchun xavfsizlik devori qoidasini ochish tunnel trafigini ko'tarishi kerak bo'lgan VPC yo'lida hech narsani o'zgartirmaydi, va mehmondagi yo'lni tahrirlash platforma xaritasini siljitmaydi. Yo'lingiz nomlagan manzilni tanlang, so'ngra faqat uni boshqaradigan ob'ektlarni tekshiring. Bu intizom ushbu nosozliklarni bartaraf etish yo'lidan ko'p taxminlarni olib tashlaydi.

Yo'lni gcloud bilan bosib o'ting

Instansiyadan boshlang va ikkala manzilni bir ob'ektdan o'qing, shunda hujjatingiz qaysi biri haqida gapirayotganini bilib olasiz:

gcloud compute instances describe app-1 --zone=europe-west1-b \
  --format="value(networkInterfaces[0].networkIP,networkInterfaces[0].accessConfigs[0].natIP)"

So'ngra yo'l haqiqatan bog'liq bo'lgan marshrutlash va ruxsatni tasdiqlang:

gcloud compute routes list --filter="destRange:10.24.1.0/24"
gcloud compute firewall-rules list --filter="sourceRanges:10.99.0.0/24"
gcloud compute vpn-tunnels describe TUNNEL_NAME --region=europe-west1

Tunnel e'lon qilgan va o'rgangan diapazonlarni o'qing, ish yukining quyi tarmog'i uchun VPC yo'lini, va mahalliy manbaga ruxsat beruvchi xavfsizlik devori qoidasini. Mehmon ustidagi tinglovchi ahamiyatli bo'lishidan oldin bu uchtasi mos kelishi kerak.

So'ngra mehmonni tekshiring: xizmat ichki manzilda tinglayaptimi, va uning qaytish yo'li yana VPC orqali o'tadimi? Faqat ommaviy manzilga bog'langan tinglovchi bulut tomonidagi har bir ob'ekt to'g'ri bo'lsa ham bu sinovdan o'tmaydi.

Ommaviy prefiks boshqa savol

Yuqoridagilarning hech biri VPN ichida olib o'tiladigan har bir manzil RFC1918 bo'lishi kerak degani emas. Uzoq tarmoqni ommaviy fazodan qonuniy ravishda raqamlash mumkin, agar platforma marshrutlashni qo'llab-quvvatlasa va operator manzil vakolatiga ega bo'lsa. Bu oddiy dizayn tanlovi.

Bu oddiy tashqi NAT manzilini boshqa ichki quyi tarmoq manzili kabi ko'rib chiqish bilan bir xil emas. Biri siz marshrutlaydigan prefiks; ikkinchisi platforma kiruvchi kirishga qo'llaydigan xaritalash.

Tashqi IPv6 va maxsus ishlab chiqilgan manzil tartiblarining o'z semantikasi bor. Rejangiz ulardan biriga bog'liq bo'lsa, IPv4 holatidan umumlashtirmasdan o'sha funksiya uchun platforma hujjatlarini o'qing. IPv4 xaritalashi oddiy holat, yagona emas, va har bir istisnoning o'z qoidalari bor.

Ustma-ust tushadigan diapazonlar boshqa muammo

Ustma-ust tushadigan xususiy diapazonlar odamlarning ommaviy manzilga murojaat qilishining haqiqiy sababi, va bu noto'g'ri vosita. Manzilni VM ning NAT manziliga o'zgartirish qoplamani hal qilmaydi; paket qaysi manzil uchun ekanini da'vo qilishini o'zgartiradi, qaytish yo'li qanday ishlashini belgilamaydi.

Qoplamani ataylab hal qiling: qayta raqamlang, qo'llab-quvvatlanadigan tarjima dizaynidan foydalaning yoki prefikslar to'qnashmaydigan tarmoq orqali marshrutlang. Ularning har biri egasi bor dizayn. NAT manzil dizayn emas.

Ikki maydonni alohida hujjatlashtiring

Tunnel sherigi va ish yuki manzilini ikki alohida runbook maydoni sifatida yozib qo'ying, har biri uni qo'llab-quvvatlaydigan yo'l va xavfsizlik devori qoidasi bilan. Ko'tarilgan IPsec tunnel faqat tomonlar kelishganini aytadi; ish yuki qaysi manzilda yetib borishini va uning xususiy yo'li to'liqmi yoki yo'qmi haqida hech narsa demaydi.

Boshqa tomondagi haqiqiy mijoz bilan tekshiring: nomni hal qiling, ichki manzilni qaytarishini tasdiqlang, ulanib, qaytish trafigini tekshiring. Compute Engine IP manzillari hujjati yuqorida ishlatilgan ichki va tashqi farqining manbasidir.

O'xshash maqolalar