Зашто је L2TP/IPsec-у потребан UDP 1701 поред IPsec-а
L2TP је други протокол који путује унутар првог, тако да крајња тачка ипак мора да достави UDP 1701 након декапсулације, чак и када га ниједан посредни уређај не види.
Заштитни зидови који дозвољавају IKE и ESP, али не и UDP 1701, прекидају L2TP везе на начин који изгледа као проблем са акредитивима. Разлог је то што је L2TP други протокол који путује унутар првог. IPsec преноси и проверава размену, а L2TP води сопствени тунел преко UDP 1701, који локални стек ипак мора да достави. Знање где се појављује свако заглавље објашњава којем уређају треба које правило.
Два протокола, два скупа портова
L2TP/IPsec веза користи IKE на UDP 500, пролаз кроз NAT на UDP 4500 тамо где постоји превод и ESP као IP протокол 50 тамо где не постоји. Сам L2TP је тунелски протокол на UDP 1701 и ради након што IPsec провери партнера. Две половине отказују на различите начине, а записи у дневнику који о њима извештавају долазе из различитих компоненти. Скуп правила који покрива само прву половину ствара везу која преговара и затим умире у фази тунела.
Бројеви портова описују транспортне крајње тачке, а ESP уопште није порт. Зато сучеље заштитног зида које нуди само правила за TCP и UDP не може да изрази потпуну IPsec политику. Протокол 50 мора бити дозвољен као протокол, а правило које помиње само UDP никада се неће подударити с њим.
Омот објашњава порт
На мрежи L2TP/IPsec веза обично показује IKE на 500 и упакован ESP на 4500. Заглавље UDP 1701 налази се унутар заштићеног терета, зато га снимање на спољном сучељу не приказује. Локални домаћин ипак мора да достави тај датаграм L2TP демону, а достава се догађа након декапсулације. Зато правило 1701 припада заштитном зиду саме крајње тачке, чак и када ниједан посредни уређај никада не види порт.
Редослед обраде објашњава већину забуне. Ако стек примени IPsec политику пре филтера домаћина, декапсулирани L2TP пакет се подудара као UDP 1701; ако је редослед обрнут, спољни портови су оно што скуп правила види. Оба понашања постоје у пракси, зато се чини да исти скуп правила ради на једној платформи, а пада на другој.
Проверите пут по реду
Прво снимите спољно сучеље и потврдите да се IKE и упакован ESP крећу у оба смера. Затим проверите локалне бројаче заштитног зида за декапсулирани саобраћај. Редослед је важан, јер снимање које не показује ништа значи да проблем лежи узводно од домаћина.
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'
sudo nft list ruleset | grep -i -A2 1701
sudo ss -lunp | grep 1701
Снимање потврђује прву половину размене и показује да ли партнер одговара. Списак правила показује постоји ли правило 1701 и где стоји у односу на било коју политику одбацивања. Списак сокета потврђује да је L2TP демон повезан и да слуша, што искључује услугу која никада није покренута. Прочитајте сва три пре промене правила, јер слушалац који недостаје и филтриран порт дају идентичне жалбе корисника.
Шта скенирање портова не може да покаже
Спољно скенирање UDP 1701 према исправно конфигурисаном серверу обично ништа не пријављује и то је очекивани резултат. Порт није изложен интернету; до њега се долази само након што IPsec провери партнера. Третирање затвореног резултата као квара води отварању порта који би требало да остане затворен. Скенирање не може да види унутар тунела једнако као што не може да види саобраћај апликације.
Уместо тога тестирајте правим клијентом и прочитајте до које фазе стиже. Ако веза преговара и затим се заглављује, осумњичени су L2TP демон или локални филтер; ако никада не преговара, криви су спољни портови. Та једна подела уклања већину нагађања о томе које правило додати, а слојевитост протокола чини то предвидљивим, а не тајанственим.