strongSwan ESP-in-UDP: aniqlash uchun NAT bo'lmaganda

NAT aniqlash manzil tarjimasini topadi, firewall siyosatini emas. NAT bo'lmagan sayt ulanishi baribir aniq ESP-in-UDP tanlovini talab qilishi mumkin.

NAT aniqlash bitta savolga javob beradi: manzillar yoki portlar yo'lda o'zgardimi? U firewall IP 50 protokoliga ruxsat beradimi-yo'qmi, degan savolga javob bermaydi. Hech qanday tarjima bo'lmagan sayt shlyuzlari hamon native ESP ni tashlab yuboradigan siyosat ortida turishi mumkin va bu talab aniqlash emas, sozlash orqali hal qilinadi. Mexanizm ESP-in-UDP bo'lib, bu qaror, o'z-o'zidan paydo bo'ladigan zaxira emas.

Aniqlash manzillar ustidagi arifmetika, firewall tekshiruvi emas

IKEv2 NAT aniqlash yuklamalarini tashiydi, ularda manba va manzil manzillari hamda portlarining xeshlari bor. Har bir tomon olganini mahalliy ko'rgani bilan solishtiradi va nomuvofiqlik unga paketni nimadir tarjima qilganini aytadi. Bu almashinuvda o'rtadagi marshrutizator 50 protokolini uzatishini tekshiradigan hech narsa yo'q.

Amaliy natijani ochiq aytishga arziydi. native ESP bilan ishlagan tunnel yangi cheklovchi firewallni o'zi topmaydi va IKE muvaffaqiyatli bo'lib turganda uning keyingi urinishi ma'lumot bosqichida muvaffaqiyatsiz bo'ladi. Siz o'rnatilgan IKE xavfsizlik assotsiatsiyalarini ko'rasiz va hech qanday himoyalangan trafik yo'q, bu simda ushlamaguningizcha marshrutlash xatosi kabi ko'rinadi.

Shuning uchun inkapsulyatsiya siz sozlayotgan ulanishning xususiyati, tomonlar tarmoq xatti-harakatidan kelishadigan natija emas.

encap almashinuvni qanday o'zgartiradi

Zamonaviy strongSwan o'rnatmasida, u swanctl.conf orqali boshqariladi, ulanishdagi encap = yes sozlamasi NAT aniqlash almashinuviga ta'sir qiladi, shunda ikki tomon ham ESP uchun UDP inkapsulyatsiyasidan foydalanadi. Himoyalangan paketlar keyin UDP ichida, odatda 4500 portida harakatlanadi va ikki uchi ham bu tartibga rozi bo'lishi kerak.

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

Bu parcha haqiqiy ulanish ta'rifining ichiga tegishli va to'liq sayt profili emas. Siz allaqachon ishlatayotgan hamkor manzillarini, autentifikatsiyani va child trafik tanlagichlarini saqlang; qo'shilgan yagona kalit himoyalangan ma'lumotlar qanday o'ralishini o'zgartiradi, ular nimadan himoya qilishini emas.

strongSwan'ning NAT-traversal qo'llanmasi bu xatti-harakatni, MOBIKE ishlatilganda port suzishi bilan o'zaro ta'sirni ham qamrab olib tasvirlaydi.

O'z backend'ingizga tegishli sozlamadan foydalaning

strongSwan'da ikki konfiguratsiya backend'i bor va kalit ular o'rtasida farq qiladi. swanctl.conf ulanish encap oladi, eski ipsec.conf ulanish esa forceencaps oladi. Bir backend'ning kalit so'zini boshqasiga qo'yish shikoyatsiz yuklanadigan va hech narsani o'zgartirmaydigan konfiguratsiya hosil qiladi, bu xatodan ham yomon.

Biror narsani tahrirlashdan oldin qaysi demon haqiqatda ishlayotganini tekshiring. Ko'p distributivlarda ikkala fayl ham bor, chunki biri oldingi migratsiya qoldig'i, faol esa xizmat birligi ishga tushiradigani. Fayl vaqt belgilaridan taxmin qilish o'rniga o'sha birlikni o'qing. Bu yerdagi besh soniyalik tekshiruv hech narsa yuklamagan sozlamani soatlab sinashdan saqlaydi.

O'zgartirishni ulanish egasi orqali qo'llang va assotsiatsiyani nazorat qilinadigan oynada qayta o'rnating. Allaqachon o'rnatilgan child almashtirilgunga qadar joriy inkapsulyatsiyasini saqlaydi, shuning uchun faqat faylni tahrirlash yangi tartib ishlatilayotganini isbotlamaydi.

O'ralgan ma'lumotlarni tekshiring, faqat portni emas

Himoyalangan trafik oqib turganda shlyuzda ushlang, so'ng uni strongSwan'ning o'z ko'rinishi bilan solishtiring:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

native ESP IP 50 protokoli sifatida ko'rinadi va UDP ga umuman o'xshamaydi. O'ralgan ESP 4500 da UDP datagrammalari sifatida ko'rinadi, ularning yuklamasi IKE emas. Xuddi shu portdagi IKE trafigi inkapsulyatsiya isboti emas, chunki MOBIKE IKE ni u yerga ko'chirishi mumkin, ma'lumot yo'li esa native bo'lib qoladi, shuning uchun port raqamini emas, yuklamani o'qing.

Yo'lning MTU sini ham yodda tuting. O'ram qo'shimcha xarajat qo'shadi va native ESP tashigan yo'l paketlar kattalashganda tuzatishlarni talab qilishi mumkin. Kerakli ICMP ishlovi dizaynning bir qismi bo'lishi kerak; inkapsulyatsiya bu bog'liqlikni yo'qotmaydi.

Tunnel ichidagi yangi ilova trafigi ikki uchida ham o'ralgan ESP sifatida ushlashda ko'ringanda va ichki xizmat hamda uning qaytish yo'li hali ishlaganda o'zgartirishni qabul qiling. Bundan kami faylda to'g'ri ko'rinadigan konfiguratsiya.

O'xshash maqolalar