Vì sao tcpdump chỉ hiển thị văn bản rõ của IPsec theo một hướng

Bạn chạy tcpdump trên giao diện ngoài của một cổng IPsec Linux và thấy hai thứ cùng lúc: các khung ESP đi vào và, ngay sau đó, các gói bên trong đã được giải mã. Chiều ra chỉ thấy ESP. Kết luận tự nhiên là các phản hồi không được gửi hoặc IPsec mã hóa một chiều và quên chiều kia. Cả hai đều không đúng.

Điều bạn đang xem là một điểm bắt gói. Nhân hệ điều hành biến đổi các gói đi ra trước khi đường truyền của thiết bị giao chúng cho ổ cắm gói, nên ổ cắm không bao giờ thấy hình dạng bên trong khi đi ra. Ở chiều vào, gói được bắt trước tiên dưới dạng ESP và bản sao đã giải gói trở nên hiển thị khi nó vào lại ngăn xếp. Cùng lưu lượng, hai cửa sổ quan sát khác nhau.

Điểm bắt gói quyết định bạn thấy gì

Trên một giao diện bình thường, ổ cắm AF_PACKET nằm gần tầng thiết bị. Các gói rời máy chủ trước tiên đi qua xử lý đầu ra của IPsec, biến một đoạn TCP bên trong thành datagram ESP hoặc UDP-4500, và chỉ sau đó mới tới tầng ấy. Các gói đến được sao chép vào ổ cắm khi ra khỏi dây cáp, vẫn còn mã hóa, và kết quả đã giải mã trở nên hiển thị sau đó khi ngăn xếp chuyển giao cục bộ hoặc chuyển tiếp.

Thứ tự đó giải thích hoàn toàn sự bất đối xứng. Đây không phải bằng chứng về hướng, chính sách hay hành vi của ứng dụng, và coi nó như vậy khiến người ta đuổi theo một phản hồi vốn đã được gửi đúng suốt thời gian. Đây là một trong số ít câu đố mạng mà công cụ, chứ không phải mạng, tạo ra bất thường.

Khớp bộ lọc với tầng bạn muốn nói tới

Một biểu thức như tcp port 443 chọn một kết nối TCP bên trong. Ở chiều ra, kết nối đó đã trở thành ESP vào lúc ổ cắm được hỏi, nên bộ lọc không khớp với gì. Nếu muốn đếm lưu lượng được bảo vệ, hãy lọc theo hình dạng bên ngoài: giao thức 50 cho ESP thô, hoặc cổng UDP 4500 khi dùng xuyên NAT. Cả hai bộ lọc đều cho một số gói có thể so sánh giữa hai bên, thường là lý do của việc đếm. Không bộ lọc nào cho biết yêu cầu bên trong có được trả lời hay không.

Đừng coi số lượng UDP 4500 là số gói ESP. IKE cũng dùng cổng đó cho các thông báo duy trì NAT-T và cho trao đổi được đóng gói, nên con số bao gồm lưu lượng không phải dữ liệu bạn muốn đo. Trao đổi IKE ban đầu trên UDP 500 cần bộ lọc riêng nếu đó là câu hỏi. Một con số trộn lưu lượng điều khiển với dữ liệu cũng làm mọi ước lượng băng thông sai một mức không xác định. Các phép đếm riêng trả lời các câu hỏi riêng.

Viết bộ lọc bên cạnh câu hỏi mà nó trả lời. «Bao nhiêu ESP đã rời khỏi hộp» và «yêu cầu web có rời khỏi hộp không» là những phép đo khác nhau với bộ lọc khác nhau, và một lần bắt gói không thể giải quyết cả hai. Không có ghi chú đó, hai người sẽ so sánh những con số chưa bao giờ đếm cùng một thứ.

Quan sát trước khi biến đổi, không phải sau

Nếu cần thấy văn bản rõ đi ra, hãy dời điểm quan sát lên sớm hơn, trước xử lý đầu ra của IPsec. NFLOG cho bạn một móc Netfilter nơi một quy tắc có thể sao chép các gói được chọn vào ổ cắm trong không gian người dùng, mà tcpdump đọc được. Hướng dẫn đổ lưu lượng của strongSwan ghi lại cách tiếp cận này đúng vì lý do đó.

Sự khớp chính sách giới hạn quy tắc ở lưu lượng sắp vào đường hầm. -m policy --pol ipsec --dir out là thứ làm quy tắc trở nên cụ thể thay vì ghi nhật ký mọi gói mà hộp gửi. Sau đó đọc nhóm nhật ký với một lần bắt gói có giới hạn: số ảnh chụp nhỏ và giới hạn kích thước ngăn chẩn đoán trở thành kho lưu trữ lưu lượng. Bắt gói có giới hạn cũng dễ trao cho người đánh giá hơn mà không kéo theo tải không liên quan. Quyết định con số trước khi bắt đầu, không phải sau khi thấy bao nhiêu đã đến.

iptables -I OUTPUT 1 -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5
tcpdump -ni nflog:5 -s 128 -c 20 'host 10.83.0.44 and tcp port 8443'

Chọn móc phù hợp với luồng. OUTPUT bao trùm lưu lượng do chính cổng tạo ra; lưu lượng đi qua từ một máy khách LAN đi theo chuỗi FORWARD, và một quy tắc trên OUTPUT sẽ không bao giờ thấy nó. Địa chỉ và cổng ở trên là chỗ giữ chỗ cho một đích thử nghiệm đã được phê duyệt.

Quan sát chứng minh điều gì

NFLOG là đích ghi nhật ký, không phải quyết định chấp nhận. Một gói xuất hiện ở đó cho thấy nó đã tới móc và khớp với quy tắc. Nó không cho thấy bộ lọc sau đó đã cho phép, thiết bị đã truyền nó hay bên kia đã nhận được gì.

Một nhật ký trống cũng mơ hồ như vậy. Kiểm tra bộ đếm gói của quy tắc, xác nhận hướng, xác nhận luồng thực sự khớp với một chính sách IPsec, và xác nhận đích. Chỉ một bộ đếm khớp ở cả hai bên mới biến quan sát thành kết luận. Sau đó so sánh bộ đếm của hiệp hội bảo mật ở cả hai bên cho cùng một lần thử có kiểm soát, vì bộ đếm SA là bản ghi có thẩm quyền về những gì đã được bảo vệ và gửi đi.

Một cái bẫy nữa: «văn bản rõ» ở đây nghĩa là nằm ngoài tầng mã hóa IPsec. Một phiên HTTPS bên trong vẫn có TLS riêng. Bắt gói đã giải gói không giải mã TLS của ứng dụng, và thấy HTTP đọc được ở đó nghĩa là ứng dụng chưa bao giờ dùng HTTPS.

Dọn dẹp và so sánh hai đầu

Xóa đúng quy tắc bạn đã chèn, theo chủ sở hữu của nó, ngay khi việc quan sát xong. Để lại một quy tắc ghi nhật ký tốn CPU trên mỗi gói khớp và âm thầm tạo ra vấn đề lưu giữ dữ liệu. Xóa bằng cách lặp lại quy tắc với -D thay vì xả một chuỗi không thuộc về bạn.

iptables -D OUTPUT -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5

Nếu việc triển khai dùng IPsec trong không gian người dùng, giao diện XFRM hay giảm tải phần cứng, các điểm quan sát sẽ dịch chuyển và công thức này có thể không áp dụng được chút nào. Với libipsec, nơi được ghi nhận để quan sát lưu lượng bên trong là thiết bị TUN. Xác định đường đi trước, rồi chọn điểm trả lời câu hỏi, và hãy chờ rằng hai chiều chỉ trông khác nhau khi bạn nhìn nhầm phía của phép biến đổi.