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 катары кармоодо көрүнгөндө жана ички кызмат менен анын кайтуу жолу дагы деле иштегенде өзгөртүүнү кабыл алыңыз. Андан азы файлда туура көрүнгөн конфигурация.

Тектеш макалалар