Меткі nftables і маршрутызацыя VPN: якое правіла сапраўды перамагае

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

Праверка 1: прачытайце правіла, якому адпавядае ядро

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

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

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

Праверка 2: метка пакета ці метка злучэння

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

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

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

Праверка 3: хто яшчэ запісвае гэтую метку

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

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

Пералічыце запісвальнікаў, перш чым дадаць яшчэ аднаго.

Праверка 4: маска вырашае, што вы пакідаеце

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

Задакументуйце размеркаванне бітаў побач з наборам правілаў.

Інакш наступны чалавек паўторна выкарыстае значэнне, у якога ўжо ёсць уладальнік, і канфлікт тут выглядае як памылка маршрутызацыі, хоць насамрэч гэта памылка адрасацыі. Дакументацыя nftables пра метаданыя пакетаў апісвае самі аперацыі з меткамі.

Праверка 5: правярайце рэальным патокам, а не пошукам

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

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

Запішыце метку, маску і табліцу ў адным месцы, і наступная праўка стане зразумелай для праверкі.