Cầu TAP cho một VLAN: gắn giao diện con

Một máy khách TAP từng tới được LAN trước khi có VLAN rồi sau đó dừng lại thường vẫn còn một cầu chứa giao diện sai. Việc chuyển tiếp khung không thêm thẻ VLAN, nên một khung máy khách không thẻ gửi tới uplink vật lý sẽ đến cổng trunk mà không có thẻ và hoặc bị loại bỏ hoặc rơi vào VLAN gốc. Việc giao diện con tồn tại ở đâu đó trên máy chủ không thay đổi gì trong danh sách thành viên của cầu. Đó là lầm tưởng cần diệt trừ trước tiên: thẻ do giao diện sở hữu nó gắn vào, không phải do máy chủ chỉ đơn giản là có một cái.

Một lần mở rộng VLAN nghĩa là một miền lớp 2, và cầu phải tham gia miền đó, không phải trunk chở tất cả chúng.

Thẻ không xuất hiện vì bạn đã bắc cầu trunk

Hãy lấy một uplink Linux eno1 mang VLAN 120 tới một switch được quản lý. Thiết kế hiệu quả cho một VLAN là tap_vpn được bắc cầu tới br_vpn, trong đó br_vpn chứa eno1.120 thay vì eno1. Giao diện con VLAN gắn thẻ khi ra và bóc thẻ khi vào, nên cầu chỉ bao giờ thấy các khung không thẻ cho đúng VLAN đó. Thay vào đó hãy đưa giao diện vật lý vào cầu, và chính những khung đó sẽ ra khỏi cổng trunk mà không có thẻ, điều bạn không hề dự tính.

Bắc cầu trunk với tính năng lọc VLAN bị tắt không phải là lối tắt tới cùng kết quả. Nó trao cho cầu mọi VLAN trên sợi dây đó, kể cả những VLAN mà máy khách không được thấy.

Hai thiết kế hợp lệ, một chủ sở hữu thẻ

Cầu nhận biết VLAN là cách bố trí hợp lệ còn lại: trunk đi vào một cổng cầu, và tư cách thành viên theo cổng, PVID cùng cài đặt lối ra có thẻ quyết định VLAN nào đi qua. Ở đó cầu sở hữu việc gắn thẻ, và thêm một giao diện con VLAN bên dưới sẽ lắp đặt chủ sở hữu thứ hai cho một công việc. Cả hai thiết kế đều chạy; các mảnh ghép của cả hai thì không. Hãy quyết định đối tượng nào gắn thẻ trước khi sửa bất kỳ danh sách thành viên nào.

Cổng switch phải khớp với bất kỳ thiết kế bạn chọn. Cổng access mang VLAN không thẻ khớp với giao diện vật lý làm điểm gắn, trong khi cổng trunk khớp với một giao diện con có thẻ. Thêm giao diện con vào một cổng access không khớp thì không sửa được gì.

Di chuyển địa chỉ cùng với tư cách thành viên

Trong thiết kế giao diện con, địa chỉ của máy chủ cho subnet được bắc cầu thuộc về br_vpn, không phải cổng VLAN bị làm nô lệ nơi nó có thể từng nằm. Để nó trên cổng có thể trông như đang chạy rồi sau đó hành xử kỳ lạ, vì cầu chuyển tiếp ở lớp 2 trong khi địa chỉ nằm trên một thành viên. Hãy di chuyển nó như một phần của thay đổi tư cách thành viên, không phải một thí nghiệm riêng.

Di chuyển một địa chỉ có thể cắt đứt đường quản trị. Hãy thiết lập một tuyến khôi phục độc lập, lưu cấu hình hiện có qua chính trình quản lý mạng của bản phân phối, và tránh một tập lệnh khởi động cạnh tranh sẽ chống lại nó sau lần nâng cấp tới.

Việc cấp địa chỉ cho máy khách cũng cần sự cẩn trọng tương tự. Một VPN được bắc cầu đặt máy khách vào subnet mở rộng, nên một pool không được chồng lấn với các hợp đồng thuê khác hoặc các gán tĩnh, và cách bố trí do DHCP phục vụ phải là cái mà LAN thực sự mong đợi. Một đường lớp 2 đang chạy không nói lên điều gì về địa chỉ trùng lặp.

Xác minh tư cách thành viên trước khi đổ lỗi cho tuyến

Hãy đọc trạng thái hiện tại thay vì trạng thái dự định: ip -d link show dev eno1.120 in id VLAN và cha của nó, ip link show master br_vpn liệt kê các thành viên cầu, và bridge vlan show báo cáo tư cách thành viên theo cổng và cách xử lý lối ra. Trong thiết kế giao diện con, hãy xác nhận rằng thiết bị TAP và thiết bị VLAN là các thành viên. Trong một cầu nhận biết VLAN, hãy kiểm tra chính chính sách cổng, vì một cầu tồn tại không chứng minh nó cho phép điều gì.

Sau đó hãy thử một máy khách được phép với một dịch vụ trong VLAN đó, nhớ rằng ARP, chính sách tường lửa và đường phản hồi là những vấn đề tách biệt với tư cách thành viên. Nếu bạn bắt gói, hãy lưu ý rằng offload phần cứng có thể thay đổi nơi thẻ VLAN xuất hiện trong một bản trace. Hãy giữ phạm vi trung thực nữa: một máy khách TUN được định tuyến không trở thành thành viên VLAN nhờ bất kỳ thay đổi cầu nào, và lưu lượng máy khách-với-máy khách không thay thế việc gắn máy chủ vào VLAN.