Virtual pfSense TAP körpüsü: kadrın ölə biləcəyi üç yer

LAN interfeysində qaydayı söndürürsünüz, kadr yenə yox olur və nəticə belə olur ki, pfSense öz firewall-unu saymır. Adətən baş verən odur ki, qərarı başqa sahib verib: körpünün özü, üzv interfeysi və ya qonaqdan kənardakı virtual svitch. Hər birinin öz idarəetməsi və öz jurnalı var.

Aşağıdakı üç sərhədi parametri dəyişməzdən əvvəl ayırmağa dəyər, çünki birini söndürmək digərini kompensasiya edə bilməz.

Bir kadr, üç siyasət sahibi

TAP müştərisindən gələn kadr tunel qurğusundan daxil olur, pfSense körpüsünü keçir, LAN üzvündən çıxır və hər hansı yerə çatmazdan əvvəl virtual svitchdən keçir. Qonağın içində filtrləmə körpüdə və ya üzv interfeyslərində baş verə bilər və hansının aktiv olduğu sabit xassə deyil, konfiqurasiya seçimidir. Qonaqdan kənarda hipervayzer həmin virtual adapterin özünə aid olmayan mənbə MAC ilə kadr göndərə biləcəyinə qərar verir. Həmin nöqtələrin hər hansı birində itki müştəri tərəfindən eyni görünür.

Araşdırmadan əvvəl nəzərdə tutulan yolu yazın: tunel üzvü, körpü, LAN üzvü, virtual svitch, təyinat. Sonra soruşun ki, o yolda hansı sahib kadrı görərdi.

Hansı pfSense idarəetməsi filtrləyir

pfSense bunun üçün iki sysctl sənədləşdirir: biri körpü üzvlərində, biri körpünün özündə filtrləmə üçün, və onlardan ən azı biri aktiv qalmalıdır. Körpü səviyyəsində filtrləmə körpü üzvlərindən gələn trafikə aiddir, yəni istiqamətinə görə gələn xarakterlidir, simmetrik deyil. Qaydaları faktiki filtrləyən interfeysdə oxuyun, çünki filtr roluna malik olmayan üzvdə yazılmış qayda heç nə etmir. Körpü filtrləmə sənədləri sahibliyi izah edir.

IP ünvanı olmayan üzv interfeysin öz ünvan və ya subnet makrosu yoxdur, ona görə də həmin makroya yazılmış qayda nəzərdə tutduğunuz LAN-dan başqa bir şeyi təsvir edə bilər. Rahatlıq makroları əvəzinə qəsdən təyin edilmiş şəbəkə obyektlərindən istifadə edin.

Fraqment kadr deyil

Ethernet kadrları IP paketlərini daşıyır və IP paketi daha böyük veraqramın fraqmenti ola bilər, ona görə bu iki söz bir-birini əvəz etmir. Tunelin içində daxili paket, ondan kənarda isə xarici nəqliyyat paketi də var və nasazlıq hər ikisinə aid ola bilər. Kiçik bir ping bu yığımdan yalnız bir yolu yoxlayır və böyük ötürmə haqqında heç nə sübut etmir. Uğursuz mübadiləni iki qonşu sərhəddə müqayisə edin və qaydanı günahlandırmazdan əvvəl itki səbəbini oxuyun.

Fraqmentlər yox olursa, cavab məhdud düzəliş və ya paket ölçüsü araşdırmasıdır, filtrləməni tamamilə söndürmək qərarı deyil.

Hipervayzerin öz qəbul qərarı var

Digər maşınlar üçün trafiki körpüləyən qonaq mənbə MAC ünvanları öz adapterinə aid olmayan kadrlar göndərir və bir çox virtual svitch port qrupu buna icazə verməsə, bunu saxtalaşdırma sayır. Bu ötürməyə icazə vermək və adapterə hər kadrı qəbul etməyə icazə vermək ayrı idarəetmələrdir və hər ikisini hər yerdə aktivləşdirmək problemin tələb etdiyindən qat-qat böyük dəyişiklikdir. Körpünün hansı kadrları qəbul etməli və göndərməli olduğunu müəyyənləşdirin, sonra yalnız o davranışı ona sahib olan sərhəddə verin. Uzaqdan idarə olunan körpünü dəyişməzdən əvvəl konsol girişini saxlayın.

Bağlantını bərpa etmək testin yarısıdır; digər yarısı bloklanmış qalmalı olan axının hələ də bloklandığını təsdiqləməkdir.

Hansı sahibin filtrlədiyini, hansı idarəetmənin dəyişdiyini və hansı iki axını yoxladığınızı qeyd edin. Bu qeyd növbəti hadisənin pfSense-in özünü saymadığına dair eyni fərziyyə ilə başlamasının qarşısını alır.