Ping qua VPN: vì sao các quy tắc trả lời echo lại bỏ lỡ đường về
Trả lời echo đổi loại ICMP, không đổi cổng dịch vụ. Theo dõi gói tin bên trong qua chuyển tiếp, NAT và bộ lọc có trạng thái trước khi mở cổng.
Gửi ping tới một máy chủ qua VPN và gói yêu cầu đi ra với một loại ICMP rồi quay về với loại khác, chỉ thế thôi đã đủ làm rối mọi quy tắc viết theo kiểu cổng. Trong trao đổi echo không có cổng dịch vụ đích nào để sao chép vào quy tắc chiều về, và một bộ lọc mong đợi sự đối xứng sẽ bỏ gói trả lời trong khi yêu cầu đi qua êm ru. Việc sửa bắt đầu bằng cách đọc gói tin đúng như nó vốn có, rồi quyết định ranh giới nào trên đường đi đang đưa ra quyết định. Thông thường hai lớp đang hoạt động trong khi lớp thứ ba lặng lẽ bỏ gói trả lời. Các phần dưới đây tách chúng theo thứ tự mà gói tin gặp chúng.
Gói tin đổi loại, không đổi cổng
Yêu cầu echo là ICMP loại 8, mã 0, mang theo một định danh và một số thứ tự. Trả lời là loại 0, mã 0, với cùng định danh và thứ tự, và hai đầu IP hoán đổi. RFC 792 định nghĩa các trường đó, và chính định danh cho phép bên gửi ghép các trả lời với yêu cầu của mình.
Cái không có cũng quan trọng không kém: không có tiêu đề TCP hay UDP, nên không có cổng nào để cho phép. Một quy tắc nêu cổng cho trả lời echo đang mô tả một gói tin sẽ không bao giờ tồn tại. Đây là lỗi phổ biến nhất trong phiếu ping qua VPN. Quy tắc trông cụ thể, không áp dụng cho gì cả, và để nguyên sự cố đúng chỗ cũ.
Ba ngữ cảnh quyết định gói tin
Nếu ping nhắm tới một máy chủ trong LAN ở xa, yêu cầu phải được cổng chuyển tiếp. Nếu nhắm tới một địa chỉ thuộc về chính cổng, nó kết thúc ở đường vào cục bộ. Nếu chính cổng khởi tạo ping, gói tin bắt đầu ở đường ra của nó và hoàn toàn không đi qua quyết định chuyển tiếp.
Ba ngữ cảnh này có chuỗi quy tắc và bộ đếm khác nhau, và việc coi chúng là một chính là lý do «tường lửa cho phép ICMP» vẫn có thể cho ra ping thất bại. Đường hầm bên ngoài là ngữ cảnh thứ tư: cho phép bộ lắng nghe VPN không tự động cho phép yêu cầu bên trong đã giải bọc, và một sự cho phép bên trong không nói gì về việc đường hầm bên ngoài có hoạt động hay không.
Bộ lọc có trạng thái và không trạng thái xử lý trả lời khác nhau
Một tường lửa có trạng thái đã thấy yêu cầu đi ra có thể gắn trả lời với luồng đó và cho qua mà không cần quy tắc thứ hai. Bộ lọc không trạng thái không có bộ nhớ như vậy, nên chiều về cần sự cho phép rõ ràng của riêng nó, với nguồn và đích đảo lại.
Hãy kiểm tra sản phẩm thực sự triển khai mô hình nào trước khi viết bất cứ điều gì. Quy tắc cho yêu cầu echo không nhất thiết bao trùm trả lời echo, và một sản phẩm theo dõi truy vấn ICMP vẫn có thể áp dụng chính sách khác cho các trả lời đến trên giao diện khác.
Hãy giới hạn điều bạn cho phép. Cho phép mọi trả lời echo từ bất kỳ đâu không giống với việc hoàn tất một liên kết có trạng thái, và số loại không xác thực bên gửi.
Bản dịch cũng đổi định danh
Nếu việc dịch nguồn là có chủ ý, bộ tuple ở đầu xa không khớp với bộ mà máy khách đã gửi. NAT có thể dịch định danh truy vấn ICMP cùng với các địa chỉ, nên việc khăng khăng phải thấy cùng một con số ở cả hai phía tạo ra sự không khớp giả.
Thay vào đó hãy tương quan với ánh xạ mà bộ dịch báo cáo. Một bộ dịch viết lại định danh sẽ không giữ con số mà máy khách của bạn đã ghi, nên hãy coi ánh xạ là danh tính chứ không phải con số. Sau đó theo dõi một yêu cầu nhận diện được suốt đường đi: xác nhận nó tới đích với nguồn mong đợi, xác nhận đích đã phát ra trả lời, theo dõi tuyến về của trả lời đó, và xác nhận máy khách đã nhận được nó thay vì chỉ nhìn bộ đếm của cổng tăng lên.
Đừng gộp lỗi ICMP vào chính sách echo
Thông điệp «cần phân mảnh» mà cơ chế dò MTU đường đi dùng không phải trả lời echo, và phần tải của nó trích dẫn gói tin đã kích hoạt nó. Một sự cho phép chỉ cho echo mà lặng lẽ bỏ các lỗi đó biến vấn đề kích thước thành một kết nối treo, tức là ngược lại với hữu ích.
Sự thận trọng tương tự áp dụng cho các họ địa chỉ. ICMPv6 dùng các loại thông điệp khác và mang những chức năng thiết yếu mà IPv4 không có, nên sao chép các con số này vào quy tắc IPv6 đơn giản là sai.
Khi trao đổi echo hoạt động, hãy thử ứng dụng thật một cách riêng rẽ. Một ping thành công chứng minh đường đi và về của một giao thức, ở một kích thước, tới một đích, và đó không phải giấy phép để cho rằng HTTPS, SMB hay bất kỳ luồng nào khác được phép.