Защо L2TP/IPsec се нуждае от UDP 1701 наред с IPsec

Защитните стени, които разрешават 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 или локалният филтър; ако никога не договаря, външните портове са виновни. Това единствено разделяне премахва повечето от догадките кое правило да добавите, а протоколното наслояване прави нещата предвидими, а не мистериозни.