Bảng VPN trống tự nó không chặn được gì

Một quy tắc chính sách gửi các gói đã đánh dấu vào một bảng riêng, và kỳ vọng thông thường là việc mất tuyến VPN sẽ chặn chúng. Nhưng cơ chế lại làm điều khác. Khi bảng không có tuyến khớp, quá trình tra cứu tiếp tục sang quy tắc kế tiếp thay vì dừng lại, và bảng main vẫn giữ một tuyến mặc định thông thường cho uplink. Kết quả là một cấu hình trông như fail-closed nhưng lại hành xử như fail-open.

Không có gì hỏng; định tuyến dựa trên chính sách được quy định như vậy.

Quá trình tra cứu tiếp tục khi bảng không có gì

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 lookup default
32766: from all lookup main

Lấy bộ quy tắc đó: một tra cứu có đánh dấu đi vào bảng 42, và một quy tắc sau đó gửi cùng dấu đó vào một bảng tên là default. Chừng nào bảng 42 còn giữ một tuyến mặc định dùng được, tra cứu đầu tiên cung cấp đường đi. Khi tuyến đó biến mất và không còn gì khác trong bảng 42 khớp, tra cứu không trở thành việc bỏ gói; quá trình xử lý chuyển sang quy tắc kế tiếp, và khi quy tắc đó cũng không tìm thấy gì, nó chạm tới bảng main. Không có gì trong chuỗi đó báo cho biết quy tắc nào đã tạo ra câu trả lời cuối cùng, nên một kết nối đang hoạt động trông giống một chính sách đang hoạt động.

Bảng 253, thường được gọi là default, là một bảng định tuyến thông thường và thường trống. Tên của nó không phải là lệnh bỏ gói, và nó không phải là thứ giống với một tuyến đích mặc định bên trong một bảng.

Các hành động kết thúc chấm dứt việc tra cứu

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 prohibit
32766: from all lookup main

Một quy tắc kết thúc có thể theo sau tra cứu VPN thay cho việc tra cứu trong một bảng trống. Với cùng dấu đó, một hành động prohibit đặt sau quy tắc của bảng 42 chấm dứt việc tra cứu khi bảng đó không đưa ra gì, và trả về một từ chối hành chính thay vì cho bảng main thêm một cơ hội. Unreachable và blackhole cũng là kết thúc, với hành vi lỗi khác cho người gửi.

Tuyến kiểu throw thì khác: bên trong bảng đó nó hành xử như thể không có gì khớp, nên các quy tắc sau vẫn có lượt của chúng. Điều đó làm throw hữu ích cho việc lùi lại có chủ ý và sai khi dùng làm chốt chặn cuối.

Xác minh bằng dấu và giao diện thật

ip -4 rule show
ip -4 route show table 42
ip -4 route get 198.51.100.20 from 10.44.0.2 iif lan0 mark 0x36

Hãy xem xét các quy tắc và bảng thật thay vì sơ đồ, rồi truy vấn luồng với ngữ cảnh nguồn, dấu và đầu vào mà nó thực sự có. Một tra cứu chỉ đọc nhắm tới một đích, được cho địa chỉ nguồn, giao diện và dấu, sẽ báo cáo tuyến mà nhân sẽ chọn mà không có gói nào đi ra. Việc cung cấp một dấu trong truy vấn không chứng minh rằng tường lửa có đánh dấu lưu lượng thật; đó là một kiểm tra riêng về các quy tắc đánh dấu. Hãy xác nhận giá trị bằng bộ đếm hoặc nhật ký trước khi kết luận từ truy vấn.

Các yêu cầu được tạo cục bộ cần ngữ cảnh riêng, vì đường đánh dấu của chúng thường khác với lưu lượng được chuyển tiếp. Hãy kiểm tra chúng bằng giao diện đầu ra mà ứng dụng thực sự sẽ dùng.

Hai trạng thái hỏng, không phải một

Một trạng thái hỏng là tuyến VPN biến mất và lưu lượng rơi xuống uplink. Một đường hầm chết mà tuyến vẫn được cài đặt là trạng thái khác: các gói vẫn bị hướng vào một đường không dùng được thay vì rơi xuống, và triệu chứng là mất mát âm thầm chứ không phải một kết nối trực tiếp nhìn thấy được. Hãy kiểm tra cả hai, và cả hành vi khi khởi động, kết nối lại và dừng dịch vụ.

Một quy tắc như vậy chỉ giúp ích khi nó còn tồn tại và khi các gói vẫn mang dấu chọn nó. Một kịch bản tắt máy xóa quy tắc, hoặc một đường gỡ bỏ dấu, sẽ khôi phục hành vi mở. Những chuyển tiếp đó đáng để luyện tập.

Áp dụng chính sách cho IPv6 riêng, và giữ các ngoại lệ điểm cuối đã được phê duyệt một cách rõ ràng thay vì ngầm hiểu.