Чаму 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 або лакальны фільтр; калі яно наогул не дамаўляецца, справа ў знешніх партах. Гэтае адзінае раздзяленне здымае большасць здагадак пра тое, якое правіла дадаць, а шараванне пратаколаў робіць гэта прадказальным, а не таямнічым.