Локално приложение, 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

Адресът и маркировката са илюстративни и двете заявки за маршрут отговарят на различни въпроси. Втората пита какво би направило ядрото, ако пакетът носеше тази маркировка; тя не показва, че вашият набор от правила задава такава. Отнасяйте се към нея като тест на хипотеза, не като доказателство, че политиката работи.

След това стартирайте безвредна заявка и наблюдавайте две неща едновременно: брояча на куката, която сте избрали, и изхода, който пакетът действително е поел. Ако броячът се движи, а пакетът излиза другаде, маркировката или таблицата е грешна. Ако нито едното не се движи, пакетът изобщо не достига тази кука и следващият въпрос е пространството от имена или пътят.

Накрая ограничете теста до това, което механизмът може да изрази. Един маршрут за един адрес не става постоянна политика за услуга, чиито адреси се сменят. Решете обхвата на пакетите първо, после проверете дали дизайнът на маршрутизиране и маркиране може да задържи този обхват след повторно свързване.