Како NAT пролазак умотава ESP унутар UDP-а

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