Как преминаването през NAT обвива ESP в UDP
ESP няма портове, затова преминаването през NAT го обвива в UDP на 4500. Проверете контролния обмен и инкапсулирания път на данните като два отделни етапа.
Два клиента зад един и същ рутер говорят с един IPsec шлюз и единият постоянно отпада, докато другият остава свързан. Родният ESP е IP протокол 50 без портове, така че транслаторът няма за какво да захване съпоставяне, когато няколко клиента споделят един адрес. Преминаването през NAT затваря тази дупка, като обвива ESP в UDP на 4500, и този заглавен блок обяснява повечето от следващите симптоми. Той също сочи към устройството, което трябва да се промени.
Защо равнината на данните се мести на порт 4500
По време на настройката IKEv2 сравнява адресите и портовете, които всяка страна смята, че използва, като разменя хешове в своите известия за откриване на NAT. Когато хешовете се разминават, някъде по пътя има транслатор и двете страни превключват защитения трафик към UDP инкапсулация. Затова сесия, срещнала транслатор, изглежда различно от такава, която не е срещнала.
Обвивката е плик, а не промяна на протокола: ESP запазва своя заглавен блок, проверката за цялост и шифроването, а UDP доставя само портовете, от които транслаторът се нуждае. Порт 500 носи IKE обмена; 4500 носи инкапсулираните данни след откриването и често също по-късните IKE съобщения. Нито един от портовете не прави потока TCP връзка — предположение, което подвежда повечето хора, четящи прихващане.
Проверете двата етапа по ред
Първо докажете контролния обмен, после пътя на данните и дръжте двете отделно в бележките си. Прихващане, което показва трафик на 500 и никога на 4500, обикновено означава, че пътят на данните е филтриран, така че поправката е в правилото на защитната стена, а не в клиента.
Наблюдавайте двата порта с tcpdump -ni any 'udp port 500 or udp port 4500' и четете таблицата за транслация на рутера, докато сесията е активна. Тази таблица показва изходния порт, който шлюзът действително ще види, а прихващането на лаптопа се разминава по замисъл: лаптопът вярва, че е 500, докато шлюзът вижда 4500 с транслатиран изходен порт, и двете са верни. Същият поток, преди и след транслацията:
client 192.0.2.10:500 -> router 203.0.113.7:62000 -> gateway 198.51.100.9:4500
Симптоми, които обвивката обяснява, и два, които не обяснява
Рутер, който разрешава контролния обмен и блокира инкапсулираните данни дава доклада „тунелът е вдигнат, но нищо не минава“. Таблиците за съпоставяне изтичат, затова неактивната сесия се нуждае от трафик за поддържане на живота, който страните изпращат нарочно, и тези пакети не са проверки за здраве. Когато няколко клиента зад един шлюз се провалят заедно, изследвайте транслацията на този шлюз и всяка наследена функция за препредаване. Обвивката не обяснява приложение, което се проваля при всеки клиент след вдигането на тунела, нито предупреждение за сертификат на страница за блокиране; и двете са над този слой.
Четете таблицата за съпоставяне за два клиента наведнъж: ако и двата показват един и същ транслатиран порт, устройството не ги разделя по начина, който шлюзът изисква. Режим на препредаване, който дава родния ESP само на един хост, не е равностойно на обслужването на няколко транслатирани клиента, макар доставчиците да описват и двете като приятелски настроени към IPsec. Двойният NAT добавя слой за съпоставяне и още една точка на изтичане, но не прекъсва автоматично изходящите връзки.
Трафикът за поддържане на живота заслужава свой ред в оперативния наръчник, защото именно той държи пътя за отговор отворен през периоди на бездействие. Включете го там, където доставчикът го документира, и го проверявайте първо, когато сесията умира след минути тишина, а не при първа употреба.
Сменете собственика на съпоставянето, после тествайте отново
Следвайте поддържаните настройки за преминаване през NAT на двете страни, вместо да гадаете порт. Редактирането на локалния изходен порт на един клиент не може да промени услугата, която слуша отсреща, и обикновено чупи вече изграденото съпоставяне. Ако клиентът е зад устройство, което не контролирате, промяната принадлежи на неговия собственик.
След всяка промяна повторете проверките на двата етапа и потвърдете, че пакет с данни преминава, а не само че екранът за състояние е станал зелен. Дръжте кортежите, изхода от таблицата за съпоставяне и промяната на правилото в една бележка, за да не започва следващият човек отново от контролния обмен. Бележките на strongSwan за преминаването през NAT покриват настройките за инкапсулация и поддържане на живота зад двата етапа.