Cầu TAP ảo của pfSense: ba nơi một khung có thể chết

Bạn tắt một quy tắc trên giao diện LAN, khung vẫn biến mất, và kết luận là pfSense đang phớt lờ tường lửa của chính nó. Điều thường xảy ra là một chủ sở hữu khác đã ra quyết định: bản thân cầu, giao diện thành viên, hoặc switch ảo bên ngoài khách. Mỗi bên có kiểm soát riêng và nhật ký riêng.

Ba ranh giới dưới đây đáng được tách bạch trước khi bạn đổi một cài đặt, vì tắt cái này không thể bù cho cái kia.

Một khung, ba chủ sở hữu chính sách

Một khung từ máy khách TAP đi vào qua thiết bị đường hầm, băng qua cầu pfSense, đi ra qua một thành viên LAN, rồi đi qua một switch ảo trước khi chạm tới bất cứ thứ gì. Bên trong khách, việc lọc có thể diễn ra trên cầu hoặc trên các giao diện thành viên, và cái nào đang hoạt động là lựa chọn cấu hình chứ không phải thuộc tính cố định. Bên ngoài khách, hypervisor quyết định liệu adapter ảo đó có được gửi khung với MAC nguồn không thuộc về nó hay không. Việc bị bỏ ở bất kỳ điểm nào trong số đó trông giống hệt nhau từ phía máy khách.

Hãy ghi lại đường đi dự định trước khi điều tra: thành viên đường hầm, cầu, thành viên LAN, switch ảo, đích. Sau đó hỏi chủ sở hữu nào trên đường đi đó đã nhìn thấy khung.

Kiểm soát nào của pfSense đang lọc

pfSense ghi nhận hai sysctl cho việc này, một cho lọc trên các thành viên cầu và một cho lọc trên chính cầu, và ít nhất một trong hai phải được bật. Lọc ở cấp cầu áp dụng cho lưu lượng đến qua các thành viên cầu, nên nó là hướng vào chứ không đối xứng. Hãy đọc các quy tắc trên giao diện thực sự đang lọc, vì một quy tắc đặt trên thành viên không có vai trò lọc thì không làm gì cả. Tài liệu về lọc cầu giải thích quyền sở hữu.

Một giao diện thành viên không có địa chỉ IP không có macro địa chỉ hay mạng con riêng, nên một quy tắc viết theo macro đó có thể mô tả thứ khác với LAN bạn định nói. Hãy dùng các đối tượng mạng được gán có chủ đích thay vì macro tiện lợi.

Mảnh không phải khung

Khung Ethernet mang gói IP, và một gói IP có thể là mảnh của một datagram lớn hơn, nên hai từ đó không thể hoán đổi cho nhau. Cũng có một gói bên trong đường hầm và một gói vận chuyển bên ngoài nó, và sự cố có thể thuộc về bất kỳ gói nào. Một ping nhỏ chỉ thử một đường qua ngăn xếp đó và không chứng minh gì về một lần truyền lớn. So sánh lần trao đổi thất bại ở hai ranh giới liền kề và đọc lý do bị bỏ trước khi đổ lỗi cho một quy tắc.

Nếu các mảnh biến mất, câu trả lời là một chỉnh sửa có phạm vi hoặc điều tra kích thước gói, không phải quyết định tắt hoàn toàn việc lọc.

Hypervisor có quyết định chấp nhận của riêng nó

Một khách làm cầu lưu lượng cho máy khác phát ra những khung có địa chỉ MAC nguồn không phải của adapter của chính nó, và nhiều switch ảo coi đó là giả mạo trừ khi nhóm cổng cho phép. Cho phép lần truyền đó và cho phép adapter nhận mọi khung là hai kiểm soát riêng biệt, và bật cả hai ở mọi nơi là thay đổi lớn hơn nhiều so với yêu cầu của vấn đề. Xác định cầu phải nhận những khung nào và phải phát những khung nào, rồi chỉ cấp hành vi đó ở ranh giới sở hữu nó. Hãy giữ quyền truy cập console trước khi thay đổi một cầu được quản lý từ xa.

Khôi phục kết nối là một nửa của phép thử; nửa còn lại là xác nhận rằng một luồng lẽ ra phải bị chặn vẫn đang bị chặn.

Ghi lại chủ sở hữu nào đã lọc, kiểm soát nào đã thay đổi và hai luồng nào bạn đã xác minh. Bản ghi đó ngăn sự cố tiếp theo bắt đầu bằng cùng giả định rằng pfSense phớt lờ chính nó.