Лакальны дадатак, правіла VPN: чаму ваш ланцуг FORWARD ніколі не спрацоўвае

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

Знайдзіце, дзе нарадзіўся пакет

Парадак хукаў Netfilter падзяляе тры выпадкі, і толькі адзін з іх тычыцца FORWARD:

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

Два пакеты, адна гісторыя

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

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

Прасторы імёнаў перамяшчаюць мяжу

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

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

Спытайце, ці патрэбна вам наогул метка

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

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

У iptables эквівалент жыве ў канструкцыі mangle OUTPUT, і дзейнічае тое ж патрабаванне: рашэнне аб маршрутызацыі трэба перагледзець пасля з’яўлення меткі. Затым правіла палітыкі павінна спажыць метку і паказаць на табліцу з прыдатным маршрутам. Усталяванне меткі conntrack — гэта трэцяя, асобная аперацыя; яна захоўвае значэнне на патоку і само па сабе не ставіць гэтае значэнне на бягучы пакет, каб яго прачытала маршрутызацыя.

Праверце пошук і лічыльнік разам

nft list ruleset
ip route get 198.51.100.25
ip route get 198.51.100.25 mark 0x1

Адрас і метка — прыклад, і два запыты маршруту адказваюць на розныя пытанні. Другі пытае, што зрабіла б ядро, калі б пакет нёс гэтую метку; ён не паказвае, што ваш набор правілаў прызначае якую-небудзь. Стаўцеся да яго як да праверкі гіпотэзы, а не як да доказу, што палітыка працуе.

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

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