Bir VLAN üçün TAP körpüsü: subinterfeysi birləşdirin

VLAN-lardan əvvəl LAN-a çatan və sonra dayanan TAP klienti adətən hələ də yanlış interfeysi saxlayan körpüyə malik olur. Kadr ötürməsi VLAN etiketi əlavə etmir, ona görə fiziki uplink-ə göndərilən etiketlənməmiş klient kadrı trunked porta etiketlənməmiş şəkildə çatır və ya atılır, ya da native VLAN-a düşür. Subinterfeysin hostda hansısa yerdə mövcud olması körpünün üzv siyahısında heç nəyi dəyişmir. Əvvəlcə məhv edilməli mif elə budur: etiketi onu sahiblənən interfeys tətbiq edir, hostun sadəcə belə birinə malik olması yox.

Bir VLAN genişlənməsi bir layer-2 domeni deməkdir və körpü hamısını daşıyan trunk-a deyil, həmin domenə qoşulmalıdır.

Etiket görünmür, çünki trunk-ı körpülədiniz

VLAN 120-ni idarə olunan kommutatora daşıyan bir Linux uplink-i eno1 götürün. Tək VLAN üçün işləyən dizayn tap_vpn-in br_vpn-ə körpülənməsidir, br_vpn isə eno1 yerinə eno1.120-i saxlayır. VLAN subinterfeysi etiketi çıxışda tətbiq edir və girişdə çıxarır, ona görə körpü yalnız həmin tək VLAN üçün etiketlənməmiş kadrlar görür. Əvəzində fiziki interfeysi körpüyə qoyun və eyni kadrlar trunk portundan etiketlənməmiş çıxır, bu isə planladığınız şey deyil.

VLAN filtrləməsi söndürülmüş halda trunk-ı körpüləmək eyni nəticəyə qısa yol deyil. Bu, körpüyə o kabeldəki hər VLAN-ı verir, o cümlədən klientlərin görməli olmadığı VLAN-ları.

İki qanuni dizayn, bir etiket sahibi

VLAN-dan xəbərdar körpü digər etibarlı quruluşdur: trunk bir körpü portuna daxil olur və port üzrə üzvlük, PVID və etiketli çıxış parametrləri hansı VLAN-ların keçəcəyini müəyyən edir. Orada etiketləmə körpüyə aiddir və onun altına VLAN subinterfeysi əlavə etmək bir iş üçün ikinci sahib quraşdırar. Hər iki dizayn işləyir; ikisinin qarışığı işləmir. Hər hansı üzvlük siyahısını redaktə etməzdən əvvəl etiketi hansı obyektin tətbiq etdiyini qərar verin.

Kommutator portu seçdiyiniz dizaynla uyğun olmalıdır. VLAN-ı etiketlənməmiş daşıyan access port fiziki interfeyslə birləşmə kimi uyğunlaşır, trunk portu isə etiketli subinterfeyslə uyğunlaşır. Uyğunsuz access porta subinterfeys əlavə etmək heç nəyi düzəltmir.

Ünvanı üzvlüklə birlikdə köçürün

Subinterfeys dizaynında hostun körpülənmiş subnet üçün ünvanı əvvəllər ola biləcəyi kölə VLAN portunda deyil, br_vpn üzərində olmalıdır. Onu portda qoymaq işləyən kimi görünüb sonra qəribə davrana bilər, çünki körpü layer 2-də ötürür, ünvan isə üzv üzərində oturur. Onu ayrı bir təcrübə kimi deyil, üzvlük dəyişikliyinin hissəsi kimi köçürün.

Ünvanın köçürülməsi idarəetmə yolunu kəsə bilər. Müstəqil bərpa marşrutu qurun, mövcud konfiqurasiyanı distributivin öz şəbəkə meneceri vasitəsilə saxlayın və növbəti yeniləmədən sonra onunla rəqabət aparacaq başlanğıc skriptindən çəkinin.

Klient ünvanlaması da eyni qayğıya ehtiyac duyur. Körpülənmiş VPN klientləri uzadılmış subnetə yerləşdirir, ona görə hovuz digər icarə və statik təyinatla üst-üstə düşməməlidir və DHCP ilə xidmət olunan quruluş LAN-ın həqiqətən gözlədiyi quruluş olmalıdır. İşləyən layer-2 yolu təkrar ünvanlar barədə heç nə demir.

Marşrutları günahlandırmadan əvvəl üzvlüyü yoxlayın

Nəzərdə tutulanı deyil, cari vəziyyəti oxuyun: ip -d link show dev eno1.120 VLAN id-sini və valideynini çap edir, ip link show master br_vpn körpü üzvlərini sadalayır, bridge vlan show isə port üzrə üzvlüyü və çıxış davranışını göstərir. Subinterfeys dizaynında TAP cihazının və VLAN cihazının üzv olduğunu təsdiqləyin. VLAN-dan xəbərdar körpüdə port siyasətinin özünü yoxlayın, çünki körpünün mövcud olması nəyə icazə verdiyini sübut etmir.

Sonra icazəli bir klienti həmin VLAN-dakı xidmətə qarşı sınayın və yadda saxlayın ki, ARP, firewall siyasəti və cavab yolu üzvlükdən ayrı məsələlərdir. Paket tutursunuzsa, nəzərə alın ki, hardware offload izdə VLAN etiketlərinin harada görünəcəyini dəyişə bilər. Əhatəni də dürüst saxlayın: marşrutlanmış TUN klienti heç bir körpü dəyişikliyi ilə VLAN üzvü olmur və klient-klient trafiki host-VLAN birləşməsini əvəz etmir.