strongSwan ESP-in-UDP: когато няма NAT за откриване

Откриването на NAT намира транслация на адреси, не политика на защитна стена. Свързване на обект без NAT може все още да изисква изричен избор на ESP-in-UDP.

Откриването на NAT отговаря на един въпрос: променили ли са се адресите или портовете по пътя? То не отговаря дали защитна стена разрешава IP протокол 50. Обектните шлюзове без никаква транслация все още могат да стоят зад политика, която отхвърля native ESP, и това изискване трябва да се конфигурира, а не да се открива. Механизмът е ESP-in-UDP и това е решение, а не резервен вариант, който се появява сам.

Откриването е аритметика върху адреси, не проверка на защитна стена

IKEv2 носи полезни товари за откриване на NAT с хешове на адресите и портовете на източника и местоназначението. Всяка страна сравнява полученото с това, което вижда локално, и несъответствието ѝ казва, че нещо е транслирало пакета. Нищо в този обмен не проверява дали рутер по средата препредава протокол 50.

Практическата последица си струва да се каже направо. Тунел, който е работил с native ESP, няма сам да открие новоограничителна защитна стена и следващият му опит се проваля на етапа на данните, докато IKE продължава да успява. Ще видите установени IKE асоциации за сигурност и никакъв защитен трафик, което изглежда като проблем с маршрутизацията, докато не направите прихващане по кабела.

Следователно инкапсулацията е свойство на връзката, която конфигурирате, а не резултат, за който страните се договарят от поведението на мрежата.

Как encap променя обмена

В модерно внедряване на strongSwan, управлявано чрез swanctl.conf, настройката encap = yes на връзката влияе на обмена за откриване на NAT, така че двете страни използват UDP инкапсулация за ESP. Защитените пакети след това пътуват в UDP, обикновено на порт 4500, и двете крайни точки трябва да се съгласят за тази подредба.

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

Този фрагмент принадлежи вътре в истинска дефиниция на връзка и не е пълен профил на обект. Запазете адресите на партньора, удостоверяването и селекторите за трафик child, които вече използвате; единственият добавен ключ променя как се обвиват защитените данни, а не какво защитават.

Ръководството на strongSwan за NAT-traversal описва това поведение, включително взаимодействието с плаване на порта, когато се използва MOBIKE.

Използвайте настройката, която принадлежи на вашия бекенд

strongSwan има два бекенда за конфигурация и ключът се различава между тях. swanctl.conf връзка приема encap, докато остаряла ipsec.conf връзка приема forceencaps. Пускането на ключова дума от един бекенд в другия създава конфигурация, която се зарежда без оплакване и не променя нищо, което е по-лошо от грешка.

Проверете кой демон всъщност работи, преди да редактирате каквото и да е. В много дистрибуции и двата файла съществуват, защото единият е остатък от предишна миграция, а активният е този, който стартира сервизният модул. Четете този модул, вместо да гадаете по времевите маркери на файловете. Петсекундна проверка тук предотвратява часове тестване на настройка, която нищо не е заредило.

Приложете промяната чрез собственика на връзката и възстановете асоциацията в контролиран прозорец. Вече инсталирано дете запазва текущата си инкапсулация, докато не бъде заменено, така че само редактиране на файл не доказва, че новата подредба се използва.

Проверете обвитите данни, не само порта

Прихванете на шлюза, докато тече защитен трафик, след което сравнете това със собствения изглед на 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 изглежда като UDP дейтаграми на 4500, чийто полезен товар не е IKE. Трафикът на IKE на същия порт не е доказателство за инкапсулация, защото MOBIKE може да премести IKE там, докато пътят на данните остава native, така че четете полезния товар, а не номера на порта.

Имайте предвид и MTU на пътя. Обвивката добавя допълнителни разходи и път, който е носил native ESP, може да се нуждае от корекции, когато пакетите нараснат. Изискваната обработка на ICMP трябва вече да е част от дизайна; инкапсулацията не премахва тази зависимост.

Приемете промяната, когато свеж трафик на приложения вътре в тунела се вижда в прихващането като обвит ESP в двата края, и когато вътрешната услуга и нейният обратен маршрут все още работят. Всичко по-малко е конфигурация, която изглежда правилна във файл.

Подобни статии