strongSwan ESP-in-UDP: анықтайтын NAT жоқ кезде

NAT анықтауы мекенжайлардың түрленуін табады, firewall саясатын емес. NAT жоқ сайт қосылысы бәрібір ESP-in-UDP-ті анық таңдауды қажет етуі мүмкін.

NAT анықтауы бір сұраққа жауап береді: жолда мекенжайлар немесе порттар өзгерді ме? Ол firewall-дың IP 50 протоколына рұқсат беретініне жауап бермейді. Ешбір түрленуі жоқ сайт шлюздері native ESP-ні тастайтын саясаттың артында қала беруі мүмкін, және бұл талап анықталудың орнына конфигурациялануы керек. Тетік — ESP-in-UDP, және бұл өздігінен пайда болатын қосалқы нұсқа емес, шешім.

Анықтау — мекенжайлар бойынша арифметика, firewall зонды емес

IKEv2 NAT анықтау жүктемелерін тасымалдайды, оларда дереккөз бен тағайындалу мекенжайларының және порттарының хэштері бар. Әр тарап алғанын жергілікті көргенімен салыстырады, және сәйкессіздік оған пакетті бірдеңе түрлендіргенін айтады. Бұл алмасуда ортадағы маршрутизатордың 50 протоколын беретінін тексеретін ештеңе жоқ.

Практикалық салдарды ашық айтқан жөн. native ESP-мен жұмыс істеген туннель жаңа шектеуші firewall-ды өзі таппайды, және IKE табысты бола бергенде оның келесі әрекеті деректер кезеңінде сәтсіз аяқталады. Сіз орнатылған IKE қауіпсіздік ассоциацияларын көресіз және қорғалған трафик жоқ, бұл сымда ұстап алғанша маршруттау ақауына ұқсайды.

Сондықтан инкапсуляция — сіз конфигурациялаған қосылыстың қасиеті, тараптар желі мінез-құлқынан келісетін нәтиже емес.

encap алмасуды қалай өзгертеді

Заманауи strongSwan орналастыруында, ол swanctl.conf арқылы басқарылады, қосылыстағы encap = yes параметрі NAT анықтау алмасуына әсер етеді, сондықтан екі тарап та ESP үшін UDP инкапсуляциясын қолданады. Қорғалған пакеттер содан кейін UDP ішінде, әдетте 4500 портында жүреді, және екі шет жақ бұл реттілікке келісуі керек.

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

Бұл үзінді нақты қосылыс анықтамасының ішіне жатады және толық сайт профилі емес. Сіз қазірдің өзінде қолданып жүрген серіктес мекенжайларын, аутентификацияны және child трафик селекторларын сақтаңыз; қосылған жалғыз кілт қорғалған деректердің қалай оралатынын өзгертеді, олардың неден қорғайтынын емес.

strongSwan-ның NAT-traversal нұсқаулығы бұл мінез-құлықты сипаттайды, оның ішінде MOBIKE қолданылғанда порттың қалқуымен өзара әрекеттесуі.

Өз backend-іңізге тиесілі параметрді қолданыңыз

strongSwan-ның екі конфигурация backend-і бар, және кілт олардың арасында ерекшеленеді. swanctl.conf қосылысы encap қабылдайды, ал ескі ipsec.conf қосылысы forceencaps қабылдайды. Бір backend-тің кілт сөзін екіншісіне салу шағымсыз жүктелетін және ештеңені өзгертпейтін конфигурация жасайды, бұл қатеден де нашар.

Бірдеңені өңдеуден бұрын қай демонның шын мәнінде жұмыс істеп тұрғанын тексеріңіз. Көптеген дистрибутивтерде екі файл да бар, өйткені біреуі бұрынғы көшірудің қалдығы, ал белсендісі — қызмет бірлігі іске қосатыны. Файлдардың уақыт белгілерінен болжам жасаудың орнына сол бірлікті оқыңыз. Осындағы бес секундтық тексеру ештеңе жүктемеген параметрді сағаттап сынаудың алдын алады.

Өзгерісті қосылыс иесі арқылы қолданып, ассоциацияны бақыланатын терезеде қайта орнатыңыз. Әлдеқашан орнатылған child ауыстырылғанша ағымдағы инкапсуляциясын сақтайды, сондықтан файлды өңдеу ғана жаңа реттіліктің қолданылып жатқанын дәлелдемейді.

Оралған деректерді тексеріңіз, тек портты емес

Қорғалған трафик ағып жатқанда шлюзде ұстап алыңыз, содан кейін оны strongSwan-ның өз көрінісімен салыстырыңыз:

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

native ESP IP 50 протоколы ретінде көрінеді және UDP-ге мүлде ұқсамайды. Оралған ESP 4500-де UDP датаграммалары ретінде көрінеді, олардың жүктемесі IKE емес. Сол порттағы IKE трафигі инкапсуляцияның дәлелі емес, өйткені MOBIKE IKE-ні сол жерге жылжытуы мүмкін, ал деректер жолы native күйінде қалады, сондықтан порт нөмірін емес, жүктемені оқыңыз.

Жолдың MTU-ын да есте сақтаңыз. Қаптама қосымша шығын қосады, және native ESP тасыған жол пакеттер өскенде түзетулерді қажет етуі мүмкін. Қажетті ICMP өңдеуі дизайнның бөлігі болуы тиіс; инкапсуляция бұл тәуелділікті жоймайды.

Өзгерісті туннель ішіндегі жаңа қолданба трафигі екі шетте де оралған ESP ретінде ұстап алуда көрінгенде және ішкі қызмет пен оның қайтару жолы әлі жұмыс істегенде қабылдаңыз. Одан кемі файлда дұрыс көрінетін конфигурация.

Қатысты мақалалар