Vì sao quy tắc iptables của bạn không bao giờ thấy lưu lượng VPN qua cầu

Hai máy ảo trên cùng một host đến được LAN qua một cầu nối, và quy tắc đặt trong chuỗi ip forward hiển thị một bộ đếm không bao giờ nhúc nhích. Các khung là thật, lưu lượng đang đi qua, và quy tắc đơn giản là không nằm trên đường đi của nó. Việc so sánh hai cách Linux phơi bày lưu lượng qua cầu giải thích sự im lặng này, và cũng giải thích vì sao nạp một mô-đun cũ lại là câu trả lời tệ hơn vẻ ngoài của nó.

Hai đường đi qua một host

Một gói có thể rời host này theo hai cách rất khác nhau, và sự khác biệt quyết định những hook nào sẽ thấy nó. Nếu đích nằm bên kia một cổng vật lý và khung được chuyển mạch giữa hai cổng của cầu, host chuyển tiếp một khung Ethernet; mã định tuyến không được hỏi đến, và không có bước nhảy định tuyến nào xảy ra. Nếu đích là chính host, hoặc một mạng đến được qua giao diện tunnel, gói được định tuyến và các hook của tầng IP thực sự có hiệu lực. Hãy ghi nhớ ngã rẽ này, vì mọi câu hỏi về sau về chuỗi và họ đều bắt nguồn từ việc khung chọn đường nào trong hai đường.

Sự khác biệt đó chính là toàn bộ câu chuyện đằng sau một quy tắc không đếm gì cả. Một khung qua cầu từ veth9a1 đến enp3s0 đi qua cầu, không phải ngăn xếp IP, nên chuỗi ip forward không thấy gì để khớp. Tên giao diện trong một ví dụ cũ không quyết định bạn có đường nào, và đó là lý do bước đầu tiên là nhìn vào cấu trúc liên kết chứ không phải tập quy tắc.

Tunnel thêm một trường hợp thứ ba đáng được đặt tên. Thiết bị TUN giao gói IP cho host, nên chúng được định tuyến và thực sự đi qua các chuỗi IP, trong khi thiết bị TAP gắn với cầu giao khung và hành xử như trường hợp cầu. Loại thiết bị quyết định, không phải tên sản phẩm.

Hãy so sánh hai họ có thể thấy một khung qua cầu

Linux hỗ trợ lọc cầu gốc thông qua họ bridge của nftables, và nó không cần mô-đun cũ nào để kiểm tra và bỏ các khung đang bay. Tài liệu về cầu của chính hạt nhân đưa ra khuyến nghị đó một cách trực tiếp, điều đáng biết trước khi một kết quả tìm kiếm bảo bạn nạp một mô-đun.

Dùng lệnh nft thay cho iptables tự nó không đặt quy tắc vào đúng họ. Một chuỗi khai báo trong họ bridge thấy các khung; một chuỗi khai báo trong ip, ip6 hoặc inet thì không thấy, bất kể tệp nhị phân nào tạo ra nó. Họ là thuộc tính của chuỗi, không phải của công cụ đã gõ nó.

Đường cũ hoạt động khác đi, và đó là lý do nên so sánh thay vì chọn phe theo thói quen. Nạp br_netfilter và bật các thiết lập bridge-nf-call lại phơi bày lưu lượng IPv4 và IPv6 qua cầu thông qua các hook của tầng IP, để một quy tắc iptables thông thường cuối cùng có thể khớp với nó. Các khung không đổi; tập hook mà chúng đi qua thay đổi, nghĩa là mọi quy tắc host hiện có nay có một khán giả mới.

Đọc đường đi thực tế trước khi thêm quy tắc

Ba lệnh xác định bạn đang ở đâu: cầu nối với cái gì, mô-đun cũ có đang hoạt động không, và những chuỗi nào đã tồn tại trong họ bridge. Hãy chạy chúng trước khi viết bất cứ thứ gì, vì câu trả lời quyết định bạn đang mở rộng thiết kế nào trong hai thiết kế. Bỏ qua bước này chính là cách một quy tắc đúng lại rơi vào một chuỗi mà không gì đi qua.

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

Kết quả phân tách các trường hợp một cách rõ ràng. Các cổng được liệt kê dưới cầu cho bạn biết giao diện nào đang được chuyển mạch; một kết quả lsmod rỗng nghĩa là không có khả năng hiển thị nào ở tầng IP đối với các khung qua cầu; một chuỗi forward hiện có của họ bridge nghĩa là đã có chủ sở hữu chính sách và quy tắc của bạn thuộc về đó chứ không phải vào một chuỗi mới của riêng nó.

Sau đó thêm một quy tắc dễ đọc lại, có bộ đếm và không đổi phán quyết, rồi cho một luồng đại diện đi qua cầu. Bộ đếm nhúc nhích chứng minh khung đã đến được quy tắc. Đó là tất cả những gì nó chứng minh, nên hãy theo tiếp bằng đường bị từ chối nữa, vì một chính sách chấp nhận mọi thứ cũng tạo ra bộ đếm nhúc nhích.

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

Nơi mô-đun cũ thay đổi hành vi

Bật đường cũ trên một cầu đang chạy không phải là hành động trung tính nhằm thêm khả năng hiển thị. Những quy tắc trước đây không thể chạm tới đối với lưu lượng qua cầu trở nên chạm tới được, kể cả các quy tắc host viết cho giao diện khác, và chính sách drop mặc định trong chuỗi ip forward có thể đột nhiên áp dụng cho những khung từng đi qua mà không bị đụng tới. Trên một host được quản trị qua cầu đó, kết quả là bị khóa ngoài không có bảng điều khiển. Đây không phải là một chế độ hỏng giả định; đó là hệ quả thông thường của việc mở rộng một tập hook trên cỗ máy mà bạn đến được bằng đúng con đường vừa mở rộng.

Trình tự an toàn hơn là quyết định họ nào sở hữu chính sách, viết các quy tắc ở đó, và giữ một đường khôi phục độc lập trước khi thay đổi bất kỳ sysctl nào. Nếu hai họ cùng giữ quy tắc, hãy ghi lại họ nào là có thẩm quyền; hai chính sách chồng lấn là cách một gói được chấp nhận ở một nơi và bị bỏ ở nơi khác mà không có một tệp nào để đọc.

Bản thân việc cô lập vẫn cần một thiết kế đầy đủ. Cho phép một nguồn đến một đích chỉ chứng minh một luồng hoạt động, trong khi yêu cầu thường là một VM không thể chạm tới hàng xóm hoặc host. Bộ đếm trên các quy tắc từ chối quan trọng hơn bộ đếm trên quy tắc chấp nhận, vì bộ đếm chấp nhận là cái mà bạn vốn đã kỳ vọng sẽ nhúc nhích.

Cuối cùng, hãy giữ trường hợp đầu vào của host tách riêng. Lưu lượng gửi đến IP của chính cầu đi vào input chứ không phải forward, và một quy tắc trong forward sẽ không bao giờ thấy nó, dù bạn chọn họ nào. Ba trường hợp, hai họ, một bài học: con đường quyết định hook, và hook quyết định liệu quy tắc của bạn có tồn tại hay không.