VPN site-to-site: hướng nào thực sự cần một quy tắc?

Cả hai đầu đều báo đã thiết lập đường hầm, chi nhánh xa trả lời từ cổng, và ứng dụng vẫn hết thời gian chờ với người dùng ở một bên. Lời khuyên thông thường là thêm quy tắc tường lửa ở cả hai hướng. Đôi khi điều đó đúng, đôi khi nó trùng lặp một quy tắc đã có, và đôi khi chính quy tắc thứ hai phá vỡ trạng thái. Trường hợp nào áp dụng phụ thuộc vào nơi tường lửa nhìn thấy gói tin.

Lưu lượng quay về có trạng thái thay đổi số lượng

Tường lửa có trạng thái ghi nhận yêu cầu và cho phản hồi đi qua mà không cần quy tắc thứ hai, nên thiết kế chỉ cần một quy tắc là bình thường. Danh sách truy cập không trạng thái không có bộ nhớ như vậy, và phản hồi phải được cho phép rõ ràng. Cả hai đều đúng trên nền tảng của mình, vì thế các lời khuyên mâu thuẫn nhau.

Đọc tài liệu chuyển tiếp của nền tảng trước mặt bạn và kiểm tra xem chính sách bạn đang sửa có trạng thái tại nơi nó nhìn thấy gói tin hay không. Việc từ chối rõ ràng cho lưu lượng đã thiết lập, hoặc thứ tự quy tắc đánh giá phản hồi trước bảng trạng thái, biến một thiết kế đang hoạt động thành khó hiểu. Số lượng quy tắc là chi tiết triển khai, còn yêu cầu là cả hai hướng của một cuộc trò chuyện được phép đều có thể hoàn tất.

Nơi tường lửa nhìn thấy gói tin đã giải mã

Trong đường hầm dựa trên chính sách, tường lửa có thể đánh giá gói tin đã mã hóa trước khi giải mã và gói tin đã giải mã sau đó, trên các giao diện khác nhau. Một quy tắc viết cho giao diện sai vẫn tồn tại, đúng và không bao giờ khớp. Đó là cách một bộ quy tắc sao chép từ triển khai đang hoạt động có thể thất bại trên phần cứng giống hệt.

IPsec dựa trên định tuyến và hầu hết triển khai hiện đại cung cấp giao diện đường hầm, nên gói tin đã giải mã đến đó và các quy tắc giao diện thông thường được áp dụng. Xác nhận mô hình mà triển khai sử dụng trước khi sao chép bộ quy tắc từ hướng dẫn viết cho mô hình kia. Giao diện đường hầm cũng là nơi cần xem khi bạn cần biết gói tin có được giải mã hay không.

Định tuyến không đối xứng phá vỡ giả định

Tường lửa có trạng thái giả định rằng nó nhìn thấy cả hai nửa của cuộc trò chuyện. Nếu phản hồi quay về qua một cổng khác, thiết bị đó không giữ trạng thái cho yêu cầu và loại bỏ nó theo chính sách của mình. Triệu chứng là lỗi một chiều mà không quy tắc nào ở phía gửi có thể sửa được. Theo dõi đường đi của phản hồi trước khi sửa bất cứ điều gì.

Kiểm tra tuyến của phản hồi trước khi thêm một quy tắc cho phép rộng ở cả hai phía. Dung nạp mọi thứ trên mọi giao diện che giấu lỗi định tuyến và đồng thời mở rộng quyền truy cập, đó là sự kết hợp tồi tệ nhất hiện có.

Kiểm tra cả hai hướng với địa chỉ nguồn thực

Thử với địa chỉ mà phía xa thực sự quan sát, vì dịch địa chỉ có thể khiến một quy tắc nguồn không khớp với gì cả. Chạy bắt gói trên cả hai cổng cùng lúc.

tcpdump -ni any 'host 10.30.8.15 and tcp port 443'
nft list ruleset | grep -A 8 'chain forward'
ip route get 10.30.8.15
conntrack -L | grep 10.30.8.15

Một yêu cầu xuất hiện trên cổng xa với địa chỉ nguồn bất ngờ giải thích một quy tắc không bao giờ khớp, và một phản hồi đến giao diện sai giải thích sự không khớp trạng thái. Sau đó thử một đích trong phạm vi được duyệt và một đích ngoài phạm vi, để ranh giới được chứng minh thay vì giả định.

Ghi lại địa chỉ nguồn sau khi dịch, giao diện mà gói tin đã giải mã sử dụng, và quy tắc đã khớp. Ba dữ kiện đó trả lời phiếu tiếp theo mà không lặp lại toàn bộ điều tra.