IKEv2 UDP 500 мен 4500 порттарын пайдаланады: қайсысы деректерді тасымалдайды?

Бірінші алмасу мен деректерді тасымалдайтын жол бір ағын емес. Екі портты да тексеріп, байырғы ESP порт емес, протокол нөмірі екенін есте сақтаңыз.

Firewall-да UDP 500-ді ашу туннельге келіссөз жүргізуге мүмкіндік береді, содан кейін қосылым трафикті өткізуді тоқтатады. Порттар тізімі толық емес еді, қате емес. IKEv2 бір сокетте басталып, көптеген нақты орналастыруларда екіншісінде жалғасады, ал пайдалы жүктеме мүлдем порт болмауы мүмкін. Кезеңдерді ретімен оқу қай ереженің жетіспейтінін түсіндіреді.

Екі порт, екі міндет

IKEv2 UDP 500-де кілт алмасудан басталады, онда тараптар бір-бірін аутентификациялап, туннель үшін қауіпсіздік ассоциациясын орнатады. Кейінгі деректер жолы бөлек мәселе: ол порт емес, IP протокол нөмірі болып табылатын байырғы ESP болуы мүмкін, немесе 4500-де UDP ішіне қапталған трафик. Мұны firewall шолуында бөлек ұстау — келіссөз жүргізетін туннель мен жұмыс істейтін туннельдің айырмашылығы. Бір сокет басқаруды, екіншісі жүктемені тасымалдайды.

Сондықтан тек 500-ге рұқсат беретін ереже бүкіл протокол отбасындағы ең шатастыратын симптомды тудырады: келіссөз сәтті өтеді, бірақ пайдалы ештеңе болмайды. Күй тең серіктесті көрсетеді, журнал орнатылған IKE SA-ны көрсетеді, ал қолданба әлі де уақыт бітеді. Жетіспейтін рұқсат дәл қазір сәтті болған ағыннан басқа ағынға тиесілі.

4500 неге мүлдем бар

Көптеген NAT құрылғылары TCP немесе UDP-ден басқа протоколды өткізе алмайды, кейбіреулері мекенжайларды ESP-нің тұтастық тексеруін бұзатындай етіп қайта жазады. ESP-ні UDP ішіне қаптау екі мәселені де шешеді, бірақ қосымша тақырып пен рұқсат етілуі керек екінші портқа әкеледі. Дәл осы қаптау екінші порттың болу себебі.

NAT анықталғаннан кейін IKE-нің өзі де 4500-ге көшеді, сонда барлық трафик аудармашы арқылы бір жолды бөліседі. ESP емес төрт байттық белгі сол сокеттегі басқару хабарламаларын деректерден ажыратады. Бұл ауысу протокол шешімі, әкімші таңдауы емес.

Бастапқы порт қайда өзгереді

Аудармашы клиенттің бастапқы портын қайта жазуы мүмкін, сондықтан серверде көрінетін tuple клиенттегі tuple-мен сәйкес келмейді. Ереже еленбейді деген қорытындыға келмес бұрын әр NAT секірісінің екі жағына қараңыз. Тек клиентте ақау іздеу дұрыс көрінетін, бірақ бәрібір сәтсіз болатын ереже бере алады.

MOBIKE қолдайтын іске асырулар NAT анықталмаса да 4500-ге көше алады, ал кейбір орналастырулар бұл жолды әдейі мәжбүрлейді. Сондықтан 4500-ді көру шешімнің дәлелі, үй маршрутизаторының дәлелі емес.

Әр шекарада екі ағынды да тексеріңіз

Үш шекарадан өтіңіз: клиент желісі, кез келген аралық firewall және сервер. Әрқайсысына орналастыру құжаттайтын ағындар қажет, басқа жағдай туралы мақаладағы ағындар емес.

sudo swanctl --list-sas
sudo tcpdump -ni any 'udp port 500 or udp port 4500'
sudo iptables -S | grep -E '500|4500|esp'
ip xfrm state

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

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

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