iptables qaydanız körpüdən keçən VPN trafikini niyə heç vaxt görmür

Eyni hostda iki virtual maşın LAN-a körpü vasitəsilə çatır və ip forward zəncirinə qoyulan qayda heç vaxt tərpənməyən sayğac göstərir. Kadrlar realdır, trafik keçir, sadəcə qayda onun yolunda deyil. Linux-un körpü trafikini göstərməyin iki yolunu müqayisə etmək bu sükutu izah edir və bir köhnə modulu yükləməyin göründüyündən niyə daha pis cavab olduğunu da izah edir.

Bir hostdan keçən iki yol

Paket bu hostdan iki tamamilə fərqli yolla çıxa bilər və fərq hansı hookların onu görəcəyini müəyyən edir. Əgər təyinat fiziki portun arxasındadırsa və kadr iki körpü portu arasında kommutasiya olunursa, host Ethernet kadrı ötürür; marşrutlaşdırma kodu işə salınmır və heç bir marşrutlaşdırılmış hop baş vermir. Əgər təyinat hostun özüdürsə və ya tunel interfeysi ilə çatılan şəbəkədirsə, paket marşrutlaşdırılır və IP qatı hookları tətbiq olunur. Bu çəngəli yadda saxlayın, çünki zəncirlər və ailələr haqqında hər sonrakı sual kadrın bu iki yoldan hansına getməsindən irəli gəlir.

Bu fərq heç nə saymayan qaydanın arxasındakı bütün hekayədir. veth9a1-dən enp3s0-ə körpülənmiş kadr IP yığınını deyil, körpünü keçir, ona görə də ip forward zənciri uyğunlaşdıracaq heç nə görmür. Köhnə nümunədəki interfeys adları hansı yolda olduğunuzu həll etmir, buna görə də ilk addım qaydalar toplusuna deyil, topologiyaya baxmaqdır.

Tunel adlandırılmağa dəyər üçüncü halı əlavə edir. TUN cihazı IP paketlərini hosta verir, buna görə onlar marşrutlaşdırılır və IP zəncirlərindən keçir, körpüyə qoşulmuş TAP cihazı isə kadrlar verir və körpülənmiş hal kimi davranır. Cihazın növü, məhsulun adı deyil, həll edir.

Bir kadrı görə bilən iki ailəni müqayisə edin

Linux nftables-in bridge ailəsi vasitəsilə yerli körpü filtrləməsini dəstəkləyir və uçuşda olan kadrları yoxlamaq və atmaq üçün heç bir köhnə modula ehtiyac duymur. Nüvənin öz körpü sənədləri bu tövsiyəni birbaşa verir, bunu axtarış nəticəsi sizə modul yükləməyi deməzdən əvvəl bilməyə dəyər.

iptables əvəzinə nft əmrindən istifadə etmək özlüyündə qaydanı düzgün ailəyə qoymur. bridge ailəsində elan edilmiş zəncir kadrları görür; ip, ip6 və ya inet-də elan edilmiş zəncir görmür, onu hansı binar yaratmış olursa olsun. Ailə zəncirin xassəsidir, onu yazan alətin deyil.

Köhnə yol fərqli işləyir və buna görə vərdişə görə tərəf seçmək əvəzinə müqayisə etmək lazımdır. br_netfilter yükləmək və bridge-nf-call parametrlərini aktivləşdirmək körpülənmiş IPv4 və IPv6 trafikini IP qatı hookları vasitəsilə yenidən göstərir, beləliklə adi iptables qaydası nəhayət ona uyğunlaşa bilir. Kadrlar dəyişmir; onların keçdiyi hooklar toplusu dəyişir, bu da hər mövcud host qaydasının artıq yeni auditoriyası olduğunu bildirir.

Qayda əlavə etməzdən əvvəl effektiv yolu oxuyun

Üç əmr harada olduğunuzu müəyyən edir: körpünün nəyə qoşulduğu, köhnə modulun aktiv olub-olmadığı və bridge ailəsində hansı zəncirlərin artıq mövcud olduğu. Heç nə yazmazdan əvvəl onları işə salın, çünki cavab iki dizayndan hansını genişləndirdiyinizi müəyyən edir. Bu addımı atlamaq düzgün qaydanın heç nəyin keçmədiyi zəncirə düşməsinin yoludur.

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

Çıxış halları təmiz ayırır. Körpünün altında sadalanan portlar hansı interfeyslərin kommutasiya olunduğunu bildirir; boş lsmod nəticəsi körpülənmiş kadrların IP qatında heç bir görünüşü olmadığını bildirir; mövcud bridge ailəsi forward zənciri isə siyasət sahibinin artıq olduğunu və qaydanızın özünün yeni zəncirində deyil, orada yer aldığını bildirir.

Sonra geri oxunması asan bir qayda əlavə edin, sayğacla və hökm dəyişikliyi olmadan, və bircə təmsilçi axını körpüdən keçirin. Tərpənən sayğac kadrın qaydaya çatdığını sübut edir. Sübut etdiyi tək şey budur, ona görə də rədd edilən yolu da izləyin, çünki hər şeyi qəbul edən siyasət də tərpənən sayğac yaradır.

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

Köhnə modul harada davranışı dəyişir

Köhnə yolu işləyən körpüdə aktivləşdirmək görünürlük əlavə etməyin neytral hərəkəti deyil. Körpülənmiş trafik üçün əvvəl əlçatmaz olan qaydalar əlçatan olur, o cümlədən başqa interfeys üçün yazılmış host qaydaları, və ip forward zəncirindəki standart drop siyasəti birdən toxunulmadan keçən kadrlara tətbiq oluna bilər. O körpü üzərindən idarə olunan hostda nəticə konsolu olmayan kilidlənmədir. Bu hipotetik nasazlıq rejimi deyil; bu, yenicə genişləndirdiyiniz yol üzərindən çatdığınız maşında hooklar toplusunu genişləndirməyin adi nəticəsidir.

Daha təhlükəsiz ardıcıllıq siyasətin hansı ailəyə aid olduğunu qərar vermək, qaydaları orada yazmaq və hər hansı sysctl dəyişməzdən əvvəl müstəqil bərpa yolu saxlamaqdır. Əgər iki ailə də qayda saxlayırsa, hansının səlahiyyətli olduğunu sənədləşdirin; iki üst-üstə düşən siyasət paketin bir yerdə qəbul edilib başqa yerdə atılmasının, oxunacaq tək fayl olmadan baş verməsinin yoludur.

İzolyasiyanın özü hələ də tam dizayn tələb edir. Bir mənbəyə bir təyinat yerinə icazə vermək yalnız bir axının işlədiyini sübut edir, halbuki tələb adətən VM-in qonşularına və ya hosta çata bilməməsidir. Rədd qaydalarındakı sayğaclar qəbul qaydasındakı sayğacdan daha vacibdir, çünki qəbul sayğacı artıq tərpənəcəyini gözlədiyiniz sayğacdır.

Nəhayət, host-input halını ayrı saxlayın. Körpünün öz IP ünvanına ünvanlanmış trafik input-a gəlir, forward-a yox, və forward-dakı qayda hansı ailəni seçsəniz də onu heç vaxt görməyəcək. Üç hal, iki ailə, bir dərs: yolu hook müəyyən edir, hook isə qaydanızın ümumiyyətlə mövcud olub-olmadığını müəyyən edir.