strongSwan’dan AWS Site-to-Site’gacha: Child SA nima uchun hech narsani tanlamaydi
IKE tunnel ko’tarilgan bo’lishi mumkin, ammo bola assotsiatsiyasi subnetlaringizni chetlab o’tadi. Avval AWS’ning mahalliy va uzoq CIDR’ini leftsubnet va rightsubnet bilan solishtiring.
Konsol up ko’rsatadi, strongSwan o’rnatilgan IKE assotsiatsiyasi haqida xabar beradi, paketlar esa hanuz yetib kelmaydi. Keyingi solishtiriladigan narsa oldindan bo’lishilgan kalit emas, balki har bir tomon tunnel himoya qiladi deb hisoblaydigan prefikslar juftidir. Quyidagi tekshiruvlarni tartib bilan o’tkazing, chunki birinchi ikkitasi tunnel sizning trafikingizni umuman tashiy olishini hal qiladi.
AWS nomlarini strongSwan atamalariga o’giring
AWS ulanishni mijoz tomonidan tavsiflaydi: mijoz shlyuzining manzili va mahalliy CIDR sizga tegishli, uzoq CIDR esa VPCga tegishli. strongSwan ikki chetni left va right deb ataydi, prefiksingiz leftsubnetda, VPC prefiksi rightsubnetda bo’ladi. Bir juftni teskari qilish noto’g’ri trafikni kelishib, tanlaydigan tunnel hosil qiladi.
AWS ulanish uchun yaratadigan konfiguratsiyani yuklab oling va uni aynan shu ulanishning etaloni deb biling, tunnel manzillari va prefikslari bilan birga. Yaratishda ikkala CIDR maydonini bo’sh qoldirsangiz, xizmat har tomonda 0.0.0.0/0 standart qiymatini ishlatadi. Tor prefiks bilan sozlangan router u bilan hech qachon mos kelmaydi, shuning uchun maydonlarni to’ldiring yoki tanlagichni ataylab kengaytiring.
Bu yerdagi nomuvofiqlik marshrutlash nosozligiga o’xshaydi, lekin unday emas.
AWS haqiqatan ko’radigan manzilni mahkamlang
NAT orqasidagi router IKE ni qarshi tomon hech qachon bilmagan interfeysdan yuborishi mumkin. AWSda qayd etilgan shlyuz manzili AWS tarmoqda ko’radigan manzil bo’lishi kerak, router esa standart marshrutiga ergashish o’rniga o’sha mahalliy manzilga mahkamlanishi kerak.
conn %default
local_addrs = 203.0.113.10
strongSwanda local_addrs IKE uchun manba manzilini tanlaydi, eski OpenSwan konfiguratsiyalari esa xuddi shu g’oyani left deb yozadi. Uni ommaviy manzilli interfeysga yo’naltiring, so’ngra NAT qurilmasining o’zida UDP 500 va 4500 o’sha xostga yetib borishini tekshiring, chunki oldingi routerdan qolgan qoida ularni jimgina tashlab yuboradi. To’g’ri tanlagich jufti noto’g’ri manba manzili bilan ham muvaffaqiyatsiz bo’ladi, jurnal esa aybni taklifga qo’yadi. Aynan shu chalg’itish manba manzili alohida tekshiruvga loyiqligining sababidir.
Yo’naltirish qoidasini taxmin qilish o’rniga tasdiqlang, chunki oldingi router uchun to’g’ri bo’lgan qoida ko’pincha qolib ketadi.
1-bosqich va 2-bosqichni alohida ko’rib chiqing
AWS IKE va ESP parametrlarini alohida ro’yxatlar sifatida ko’rsatadi. Ikki tomon qabul qiladigan IKE to’plami ESP taklifi haqida hech narsa demaydi, chunki ikkala ro’yxat mustaqil. Ikkalasini ham yaratilgan konfiguratsiyadan o’qing va birma-bir solishtiring.
conn aws
ike = aes256-sha1-modp1024
esp = aes256gcm16
Sintaksis amalga oshirishlar orasida ko’chmaydi. OpenSwanda ishlaydigan juft, masalan phase2alg=aes_gcm ike=aes256-sha1;modp1024 bilan, strongSwanning esp= va ike= shakliga o’girilishi kerak, algoritm nomlari esa farq qiladi. GCM shifrlash paytida autentifikatsiya qilgani uchun SHA bilan juftlangan CBC to’plamidan farqli ravishda alohida yaxlitlik o’zgarishiga muhtoj emas. Bir demonndan boshqasiga tarjimasiz yopishtirilgan 2-bosqich satri tanlagich nomuvofiqligidek o’qiladigan rad javobini keltirib chiqaradi.
Tunnel ko’rsatkichini emas, bola assotsiatsiyasini tekshiring
Agar ulanish yuklansa-yu, lekin bola assotsiatsiyasi paydo bo’lmasa, taklif yoki tanlagichlar rad etilgan. Agar bola paydo bo’lib, uning tanlagichlari prefikslaringizni chetlab o’tsa, paketlar tunnelga yetib borishdan oldin filtrlanadi. Konsol ko’rsatkichi faqat IKE darajasini qamrab oladi, shuning uchun ikkisidan qaysi biri sodir bo’lganini ayta olmaydi.
ipsec statusall
Bola xavfsizlik assotsiatsiyasini toping va uning yonida chop etilgan trafik tanlagichlarini o’qing, so’ngra ularni yaratilgan konfiguratsiya prefikslari bilan solishtiring.
Mahalliy prefiks ichidagi xostdan VPC prefiksi ichidagi xostga sinab ko’ring va qaytish yo’lini hamda AWS tomonidagi har qanday xavfsizlik guruhi yoki tarmoq ACLni tekshiring. To’g’ri tanlagichlar paketni keyinroq tashlab yuborishdan himoya qilmaydi.
Tanlagichlar mos kelgandan keyin ham ishlamasa
Ikki tomondagi marshrut tunnelga qaratilganini tasdiqlang, so’ngra NAT qurilmasi trafikni siyosat kutmaydigan tarzda qayta yozmayotganini tasdiqlang. Siyosatga asoslangan tunnel paket manzillarini moslashtiradi, shuning uchun siyosat qaroridan keyin qo’llanilgan tarjima natijani o’zgartiradi.
Boshqa taklifni o’zgartirishdan oldin har tomonda bittadan kiruvchi va chiquvchi paketni jurnalga yozing.
Tiketga tanlagichlarni, 1- va 2-bosqich takliflarini hamda manba manzilini yozing. Ushbu to’rt qiymat site-to-site nosozliklarining ko’pini qo’ng’iroqsiz tushuntiradi.