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.

Користете ја поставката што му припаѓа на вашиот 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 се појавува како UDP датаграми на 4500 чие корисно оптоварување не е IKE. IKE сообраќајот на истата порта не е доказ за инкапсулација, бидејќи MOBIKE може да го премести IKE таму додека патеката на податоци останува native, затоа читајте го оптоварувањето, а не бројот на портата.

Имајте го на ум и MTU на патеката. Обвивката додава дополнителен трошок, и патека што носела native ESP може да бара прилагодувања кога пакетите растат. Потребната обработка на ICMP веќе треба да биде дел од дизајнот; инкапсулацијата не ја отстранува таа зависност.

Прифатете ја промената кога свеж апликациски сообраќај во тунелот е видлив во снимката како завиткан ESP на двата краја, и кога внатрешната услуга и нејзината повратна патека се уште работат. Се помалку е конфигурација што изгледа исправно во датотека.

Поврзани статии