Зашто ваше 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-у га никада неће видети, коју год фамилију да изаберете. Три случаја, две фамилије, једна лекција: пут одређује куку, а кука одређује да ли ваше правило уопште постоји.