Откривање 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 на оба краја и када унутрашња услуга и њена повратна путања још раде. Све мање од тога је конфигурација која у фајлу изгледа исправно.

Повезани чланци