Тунэль VPN ніколі не злучаецца: дзе насамрэч спыняюцца пакеты

Кліент безупынна паўтарае спробы, журнал спыняецца да завяршэння рукапаціску, а сервер не фіксуе наогул нічога. Гэтая карціна адводзіць ад уліковых даных і паказвае на шлях: нешта паміж двума бакамі адмаўляецца несці пратакол, патрэбны тунэлю. Вызначце, дзе спыняюцца пакеты, перш чым чапаць любую з дзвюх канфігурацый, бо адфільтраваны пратакол і няправільны пароль даюць у большасці кліентаў аднолькавую ласкавую памылку. Тэсты ўпарадкаваны па кошце, самы танны першым.

Дакажыце, дзе спыняецца трафік

Рабіце захоп адначасова на зыходным інтэрфейсе кліента і на серверы. Параўнайце тое, што пайшло, з тым, што прыйшло, і адзначце, у якім кірунку ўзнікае розніца.

Нічога на серверы азначае, што шлях або першы NAT скідвае трафік, а прыходы без адказаў паказваюць на фаервол на серверы або на адсутны зваротны маршрут. Маршрутызатар, які часта завяршае тунэлі, часта не вядзе карыснага журнала, таму захоп становіцца запісам. Запішыце порт прызначэння і нумар пратакола, бо абодва збоі выглядаюць у дыялогу кліента аднолькава.

PPTP памірае без пратакола 47

PPTP перадае кіраванне праз TCP 1723, а даныя ўнутры GRE, які з'яўляецца IP-пратаколам 47, а не нумарам порта. Перанакіраванне толькі 1723 дае класічны вынік: злучэнне праходзіць аўтэнтыфікацыю, а затым заціхае, бо для пратакола, які нясе карысную нагрузку, няма правіла. Кліент не можа адрозніць гэта ад адхіленага пароля, таму захоп павінен быць зроблены да правак канфігурацыі.

Празрыстасць працуе ў процілеглым кірунку ад уваходнага перанакіравання, і прашыўка часта выкарыстоўвае адну назву для абодвух, дастаткова, каб усіх заблытаць. На кліенце Linux лакальны фаервол можа скідваць GRE задоўга да ўдзелу маршрутызатара, таму пратаколу 47 патрэбна ўласнае правіла, а памочнік conntrack павінен быць загружаны. ufw у Ubuntu трымае гэтыя правілы ў файле before, бо звычайныя правілы дазволу не могуць выказаць нумар пратакола. Пасля гэтага перазагрузіце фаервол, а не перазапускайце машыну.

# /etc/ufw/before.rules, inside *filter
-A ufw-before-input -p gre -j ACCEPT
sudo ufw allow 1723/tcp
sudo modprobe nf_conntrack_pptp
sudo conntrack -L | grep gre

L2TP і IPsec за двума NAT

L2TP унутры IPsec патрабуе UDP 500 для абмену ключамі, UDP 4500, калі выяўлены NAT, і ESP як пратакол 50. Кожны з іх фільтруецца асобна, таму правіла, якое дазваляе адзін, нічога не даказвае пра два іншыя. Два маршрутызатары паслядоўна пераўтвараюць кожны пакет двойчы, і канцавыя пункты больш не згаджаюцца наконт таго, што было ўзгоднена.

Перавядзіце знешні мадэм у рэжым моста або выключыце NAT на ўнутраным маршрутызатары, каб публічны адрас дасягаў прылады, якая завяршае тунэль. Калі ні тое, ні іншае немагчыма, тунэль трэба ініцыяваць знутры мяжы двайнога NAT, а не завяршаць там.

Сеткі аператараў і супольнае выкарыстанне адрасоў

WAN-адрас у межах 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 або 100.64.0.0/10 значыць, што ў маршрутызатара няма публічнага адраса і ніякае ўваходнае перанакіраванне з інтэрнэту не дасягне яго. NAT аператарскага ўзроўню дадаткова фільтруе пратаколы, якіх не чакае, і GRE часта церпіць на мабільных каналах. Параўнайце WAN-адрас на самім маршрутызатары, а не адрас, які сайт пошуку паведамляе для кліента за ім.

Запуск таго ж маршрутызатара на драцяной лініі аддзяляе выснову аб аператары ад памылкі канфігурацыі за адзін тэст. Калі аператар адмаўляе пратакол, застаюцца варыянты: іншы транспарт на 443 або тунэль, ініцыяваны знутры.

Прачытайце спіс слухачоў перад закрыццём партоў

Трывожнае сканаванне партоў часта ёсць проста набор функцый, што пастаўляецца ўключаным. Пералічыце слухачоў, суаднясіце кожны сокет з функцыяй, а затым адключыце функцыю замест блакіроўкі порта, каб два прадстаўленні не разыходзіліся.

ss -lntup
systemctl list-units --type=service --state=running | grep -i vpn
nc -vz 203.0.113.10 1723
nc -vzu 203.0.113.10 4500

Стандартныя налады SoftEther добры прыклад: TCP 443, 992 і 5555, а функцыі L2TP/IPsec і DNS-тунэля дадаюць уласныя сокеты. Адключэнне гэтых функцый выдаляе слухачоў замест таго, каб хаваць іх, а праверка з вонкавага хоста паказвае, ці прапускае аператар порт наогул. Слухач, які адказвае лакальна, усё яшчэ можа быць закрыты вышэй па плыні, таму параўнайце ўласны WAN-адрас маршрутызатара з тым, што паведамляе вонкавая служба.