Зошто вашето правило во iptables никогаш не го гледа VPN сообраќајот преку мост

Две виртуелни машини на истиот хост стигнуваат до LAN преку мост, а правило поставено во синџирот ip forward покажува бројач што никогаш не се движи. Кадрите се вистински, сообраќајот поминува, и правилото едноставно не е на неговата патека. Споредбата на двата начина на кои Linux го изложува сообраќајот преку мост ја објаснува оваа тишина и објаснува зошто вчитувањето на еден стар модул е полош одговор отколку што изгледа.

Две патеки низ еден хост

Пакетот може да го напушти овој хост на два многу различни начина, а разликата одлучува кои куки ќе го видат. Ако одредиштето е зад физички порт и кадарот се префрла помеѓу два порта на мостот, хостот проследува Ethernet кадар; кодот за рутирање не се прашува и не се случува рутиран скок. Ако одредиштето е самиот хост или мрежа достапна преку тунелски интерфејс, пакетот се рутира и куките на IP слојот навистина важат. Имајте го ова разгранување на ум, бидејќи секое подоцнежно прашање за синџири и семејства произлегува од тоа која од двете патеки ја избира кадарот.

Таа разлика е целата приказна зад правило што ништо не брои. Кадар преку мост од veth9a1 до enp3s0 го преминува мостот, а не IP стекот, па синџирот ip forward не гледа ништо за совпаѓање. Имињата на интерфејсите во постар пример не одлучуваат која патека ја имате, и затоа првиот чекор е да се погледне топологијата, а не множеството правила.

Тунелот додава трет случај што заслужува име. TUN уред доставува IP пакети до хостот, па тие се рутираат и навистина поминуваат низ IP синџири, додека TAP уред поврзан на мост доставува кадри и се однесува како случајот со мост. Типот на уредот, а не името на производот, одлучува.

Споредете ги двете семејства што можат да видат кадар преку мост

Linux поддржува матично филтрирање на мост преку семејството bridge на nftables и не му треба стар модул за да ги прегледува и отфрла кадрите во лет. Самата документација за мост на јадрото ја дава таа препорака директно, што вреди да се знае пред резултат од пребарување да ви каже да вчитате модул.

Користењето на командата nft наместо iptables само по себе не става правило во вистинското семејство. Синџир деклариран во семејството bridge гледа кадри; синџир деклариран во ip, ip6 или inet не ги гледа, без оглед на тоа која бинарна датотека го создала. Семејството е својство на синџирот, а не на алатката што го напишала.

Старата патека работи поинаку и токму затоа вреди да се споредува наместо да се избере страна по навика. Вчитувањето на br_netfilter и вклучувањето на поставките bridge-nf-call повторно го изложува сообраќајот IPv4 и IPv6 преку мост низ куките на IP слојот, така што обично правило во iptables конечно може да се совпадне со него. Кадрите не се менуваат; се менува множеството куки низ кои поминуваат, што значи дека секое постоечко правило на хостот сега има нова публика.

Прочитајте ја ефективната патека пред да додадете правило

Три команди утврдуваат каде сте: на што е поврзан мостот, дали стариот модул е активен и кои синџири веќе постојат во семејството bridge. Извршете ги пред да напишете нешто, бидејќи одговорот одлучува кој од двата дизајна го проширувате. Прескокнувањето на овој чекор е начинот на кој точно правило завршува во синџир низ кој ништо не поминува.

bridge link show
lsmod | grep br_netfilter
nft list ruleset | grep -A4 "chain forward"

Излезот случаите ги дели чисто. Портите наведени под мостот ви кажуваат кои интерфејси се префрлаат; празен резултат од lsmod значи никаква видливост на IP слојот за кадрите преку мост; постоечки forward синџир на семејството bridge значи дека сопственик на политиката веќе постои и вашето правило припаѓа таму, а не во нов сопствен синџир.

Потоа додадете едно правило што лесно се чита назад, со бројач и без промена на пресудата, и пуштете еден претставнички тек низ мостот. Бројач што се движи докажува дека кадарот стигнал до правилото. Тоа е сѐ што докажува, затоа продолжете и со одбиената патека, бидејќи политика што прифаќа сѐ исто така создава бројач што се движи.

nft add rule bridge filter forward iifname "veth9a1" oifname "enp3s0" counter accept

Каде стариот модул го менува однесувањето

Вклучувањето на старата патека на мост што работи не е неутрален чин на додавање видливост. Правилата што претходно беа недостапни за сообраќај преку мост стануваат достапни, вклучително правила на хостот напишани за друг интерфејс, и стандардната drop политика во синџирот ip forward може одеднаш да се примени на кадри што порано поминуваа недопрени. На хост што се управува преку тој мост, резултатот е заклучување без конзола. Ова не е хипотетички режим на дефект; ова е вообичаената последица од проширување на множество куки на машина до која стигнувате преку патеката што штотуку ја проширивте.

Побезбедната низа е да одлучите кое семејство ја поседува политиката, таму да ги напишете правилата и да задржите независна патека за враќање пред да смените кој и да е sysctl. Ако две семејства држат правила, документирајте кое е авторитативно; две политики што се преклопуваат се начинот на кој пакетот се прифаќа на едно место и се отфрла на друго без ниту една датотека за читање.

Изолацијата сама по себе сѐ уште бара целосен дизајн. Дозволувањето на еден извор до едно одредиште докажува само дека еден тек работи, додека барањето обично е VM да не може да стигне до своите соседи или до хостот. Бројачите на правилата за одбивање се поважни од бројачот на правилото за прифаќање, бидејќи бројачот за прифаќање е тој што веќе очекувавте да се движи.

На крајот, држете го случајот со влезот на хостот одделно. Сообраќајот упатен до сопствената IP на мостот пристигнува на input, а не на forward, и правило во forward никогаш нема да го види, кое и семејство да изберете. Три случаи, две семејства, една лекција: патеката одлучува за куката, а куката одлучува дали вашето правило воопшто постои.