Мост TAP для аднаго VLAN: далучыце субінтэрфейс

Кліент TAP, які дасягаў LAN да VLAN і спыніўся пасля, звычайна мае мост, які ўсё яшчэ змяшчае няправільны інтэрфейс. Перадача кадраў не дадае цэтлік VLAN, таму непазначаны кадр кліента, адпраўлены на фізічны uplink, прыходзіць непазначаным на trunk-порт і альбо адкідваецца, альбо трапляе ў native VLAN. Існаванне субінтэрфейса недзе на хасце нічога не мяняе ў спісе членаў моста. Менавіта гэты міф трэба забіць першым: цэтлік ужывае інтэрфейс, які ім валодае, а не хост, які проста мае такі інтэрфейс.

Адно пашырэнне VLAN азначае адзін дамен layer-2, і мост павінен далучыцца да гэтага дамена, а не да trunk, які нясе ўсе.

Цэтлік не з'яўляецца, бо вы злучылі trunk

Вазьміце Linux uplink eno1, што нясе VLAN 120 да кіраванага камутатара. Дызайн, які працуе для аднаго VLAN, — гэта tap_vpn, злучаны з br_vpn, прычым br_vpn змяшчае eno1.120, а не eno1. Субінтэрфейс VLAN ужывае цэтлік на выхадзе і здымае яго на ўваходзе, таму мост бачыць толькі непазначаныя кадры для гэтага аднаго VLAN. Пастаўце замест гэтага фізічны інтэрфейс у мост, і тыя ж кадры выйдуць непазначанымі на trunk-порце, што не тое, што вы планавалі.

Злучэнне trunk са адключанай фільтрацыяй VLAN — не кароткі шлях да таго ж выніку. Яно аддае мосту кожны VLAN на гэтым провадзе, уключаючы тыя, якія кліенты не павінны бачыць.

Два законныя дызайны, адзін уладальнік цэтліка

VLAN-aware мост — іншая слушная схема: trunk уваходзіць у порт моста, а членства па портах, PVID і налады пазначанага выхаду вырашаюць, якія VLAN пройдуць. Там цэтлікаваннем валодае мост, і даданне субінтэрфейса VLAN пад ім усталявала б другога ўладальніка для адной задачы. Абодва дызайны працуюць; фрагменты абодвух — не. Вырашыце, які аб'ект ужывае цэтлік, перш чым рэдагаваць любы спіс членства.

Порт камутатара павінен адпавядаць абранаму дызайну. Access-порт, што нясе VLAN непазначаным, спалучаецца з фізічным інтэрфейсам як далучэнне, а trunk-порт спалучаецца з пазначаным субінтэрфейсам. Даданне субінтэрфейса да неадпаведнага access-порта нічога не выпраўляе.

Перанясіце адрас разам з членствам

У дызайне з субінтэрфейсам адрас хоста для злучанай падсеткі належыць br_vpn, а не залежнаму VLAN-порту, дзе ён мог быць раней. Пакіданне яго на порце можа выглядаць працоўным, а потым паводзіць сябе дзіўна, бо мост перадае на layer 2, пакуль адрас сядзіць на члене. Перанясіце яго як частку змены членства, а не як асобны эксперымент.

Перанос адраса можа адрэзаць шлях адміністравання. Стварыце незалежны шлях аднаўлення, захавайце існуючую канфігурацыю праз уласны сеткавы менеджар дыстрыбутыва і пазбягайце канкуруючага стартавага скрыпта, які будзе змагацца з ім пасля наступнага абнаўлення.

Адрасацыя кліентаў патрабуе такой жа ўвагі. Злучаны VPN змяшчае кліентаў у пашыраную падсетку, таму пул не павінен перакрываць іншыя арэнды або статычныя прызначэнні, а схема з DHCP павінна быць той, якую LAN сапраўды чакае. Працоўны шлях layer-2 нічога не кажа пра дублікаваныя адрасы.

Праверце членства, перш чым вінаваціць маршруты

Чытайце бягучы стан, а не меркаваны: ip -d link show dev eno1.120 друкуе id VLAN і яго бацьку, ip link show master br_vpn пералічвае членаў моста, а bridge vlan show паказвае членства па портах і апрацоўку выхаду. У дызайне з субінтэрфейсам пераканайцеся, што прылада TAP і прылада VLAN з'яўляюцца членамі. У VLAN-aware мосце праверце самую палітыку порта, бо наяўнасць моста не даказвае, што ён дазваляе.

Затым праверце аднаго дазволенага кліента супраць сэрвісу ў гэтым VLAN, памятаючы, што ARP, палітыка файрвола і шлях адказу — асобныя пытанні ад членства. Калі вы здымаеце пакеты, улічыце, што апаратнае offload можа змяніць месца, дзе цэтлікі VLAN з'яўляюцца ў трасе. Трымайце рамкі сумленнымі: маршрутызаваны кліент TUN не робіцца членам VLAN ніякай зменай моста, і трафік кліент-да-кліента не замяняе далучэнне хоста да VLAN.