Зошто 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 или локалниот филтер; ако никогаш не преговара, виновни се надворешните порти. Тоа единствено разделување го отстранува најголемиот дел од погодувањето за тоа кое правило да се додаде, а слоевитоста на протоколите го прави предвидливо наместо мистериозно.