Маршрут VPN ці правіла файрвола: што скідвае пакет?

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

Два рашэнні, адзін пакет, два ўладальнікі

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

Фільтраванне асобнае. На хасту Linux хукi netfilter дзеляць трафік па тым, каму прызначаны пакет: выхад пакідае машыну, уваход завяршаецца на ёй, перадача праходзіць праз яе. Шлюзу, які прымае кліентаў VPN і накіроўвае іх у LAN, патрэбны шлях перадачы, і гэта менавіта той ланцужок, які большасць тыповых канфігурацый пакідае пустым.

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

Прачытайце, што насамрэч выбраў пошук

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

ip route get 10.8.0.5
ip route get 10.8.0.5 from 192.0.2.44
ip rule show
ip route show table all | sed -n '1,40p'

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

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

Фільтраванне дзейнічае на хуку, а не на маршруце

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

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

Даслаць пробу праз шлях, які выкарыстоўвае кліент

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

nc -vz -w 3 10.8.0.5 443
ping -c 3 -W 1 10.8.0.5
tcpdump -ni any host 10.8.0.5 and port 443
iptables -vnL FORWARD --line-numbers
nft list ruleset | sed -n '1,60p'

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

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

Лагаванне працуе як другое меркаванне, а не першы крок. Часовы запіс лага на ланцужку перадачы называе інтэрфейс і адрасы, якія ў яго трапілі, і яго лёгка выдаліць потым. Пакіньце яго назаўсёды — і вы пабудавалі праблему аб'ёму лагаў замест адказу.

Змяшчайце кожнае змяненне туды, дзе яно перажыве перападключэнне

Маршрут, дададзены праз ip route add, жыве, пакуль інтэрфейс не ўпадзе. Захавайце яго ў профілі злучэння: NetworkManager прымае дадатковыя маршруты на злучэнні, а netplan захоўвае іх паміж загрузкамі. То ж правіла датычыцца выключэння файрвола на баку кліента, якое знікае пасля наступнай перазагрузкі.

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

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