ESP đi ra không có phản hồi không có nghĩa là VPN đã chết
ESP bảo vệ một chiều trên mỗi liên kết và không xác nhận gì cả. Đối chiếu cuộc trò chuyện bên trong và SA vào trước khi nói máy chủ không phản hồi.
Bạn đã bắt gói tin trên máy chủ IPsec, thấy các gói ESP đi ra, không thấy gì quay lại và kết luận phía xa bị hỏng. Bản bắt gói không ủng hộ kết luận đó. ESP bảo vệ một chiều của cuộc trò chuyện và không xác nhận gì ở lớp IP, nên việc thiếu ESP quay về có thể chỉ có nghĩa là ứng dụng không có gì để nói, cũng như có thể có nghĩa là đường hầm đã chết. Hãy đọc trao đổi bên trong và trạng thái phía nhận trước khi đổ lỗi cho bất kỳ đầu nào.
Lầm tưởng: mỗi gói được bảo vệ đều nhận được phản hồi
ESP không phải giao thức yêu cầu-phản hồi. Nó mã hóa và xác thực bất cứ thứ gì chính sách chọn, và bên nhận kiểm tra, giải mã rồi chuyển giao gói bên trong đó mà không tự tạo ra gói nào. Một truy vấn UDP mà đích bỏ qua, hoặc một tiếng dội ICMP mà chính sách vào loại bỏ, tạo ra sự im lặng ở cả hai chiều như kết quả đúng. Coi sự im lặng đó là lỗi truyền tải sẽ khiến bạn đi tìm một lỗi mạng chưa từng tồn tại.
Điều mà bản bắt gói một chiều thực sự chứng minh là ngăn xếp của bên gửi đã mã hóa một thứ gì đó tại điểm quan sát đó. Không nói gì về việc đến, và không nói gì về ý định trả lời. Câu hỏi hữu ích không phải „tại sao không có phản hồi“ mà là „cuộc trò chuyện bên trong lẽ ra phải tạo ra gì“.
Hai SA, hai SPI, một cuộc trò chuyện
Các liên kết bảo mật IPsec là một chiều, nên một trao đổi được bảo vệ thông thường chạy một liên kết vào và một liên kết ra với các định danh riêng và trạng thái độc lập. Việc tìm lưu lượng quay về theo SPI của gói đi ra do đó là một lỗi phân loại, vì mọi phản hồi đều đi dưới SA đi ra của chính đối tác với SPI của nó. Thay vào đó, hãy ghép cặp theo bộ chọn lưu lượng và địa chỉ của đối tác.
Việc tái lập khóa làm phức tạp bức tranh trong vài giây, vì trạng thái cũ và trạng thái thay thế có thể chồng lấn. Nếu triệu chứng bắt đầu quanh một lần đổi khóa, hãy thu thập định danh liên kết và dấu thời gian cùng nhau chứ không chỉ tên kết nối.
Bên nhận phải làm gì trước khi có bất cứ thứ gì phản hồi
| Stage | What to look at | Wrong conclusion if skipped |
|---|---|---|
| Sender encrypts | outbound SA packet counter | "the tunnel is up" |
| Peer receives | inbound SA counter and replay window | "the peer is down" |
| Inner delivery | target host or service logs | "routing is broken" |
| Application replies | the app's own trace | "the reply was dropped" |
| Protected return | the peer's outbound SA | "ESP only works one way" |
Mỗi hàng hỏng độc lập và mỗi lỗi có một chủ sở hữu khác nhau, đó là lý do một bản bắt gói không thể phân biệt chúng. Bộ đếm vào là bằng chứng trực tiếp duy nhất về việc đến, vì một gói không qua được xác thực hoặc kiểm tra lặp lại sẽ bị loại bỏ mà không có bất kỳ phản hồi nào. Một đối tác có bộ đếm vào không nhúc nhích do đó không cung cấp cho bạn thông tin nào về chính sách của nó.
Việc chuyển giao là một bước riêng so với giải mã. Trạng thái có thể hợp lệ mà gói vẫn bị loại bỏ sau đó bởi chính sách vào hoặc bởi tuyến đường không bao gồm đích bên trong, nên hãy kiểm tra xem máy chủ đích có thấy văn bản rõ hay không thay vì cho rằng bộ đếm sạch nghĩa là gói đã đi đúng nơi bạn muốn.
ESP gốc không phải UDP
ESP gốc là giao thức IP 50, không phải TCP cũng không phải UDP và không có cổng nào cả. Vì vậy một quy tắc tường lửa cho phép IKE trên UDP 500 không nói gì về đường dữ liệu, và một bộ lọc viết quanh các cổng có thể cho đường hầm thương lượng rồi sau đó loại bỏ mọi thứ được mang bên trong. Hãy kiểm tra đường dữ liệu riêng, ở chế độ bạn thực sự quan sát được.
Phía sau NAT hình dạng thay đổi: tải trọng được bảo vệ đi bên trong UDP, thường trên cổng 4500, như RFC 3948 định nghĩa. Ghi lại chế độ đang hoạt động trước khi viết bất kỳ quy tắc nào, vì một thiết bị trên đường đi có thể xử lý ESP gốc và ESP đóng gói trong UDP hoàn toàn khác nhau, và một số hộp trung gian cho phép cái này nhưng loại bỏ cái kia.
Đọc các bộ đếm thuộc về sự cố này
Trên máy chủ strongSwan, swanctl --list-sas báo cáo bộ đếm gói và byte cho từng liên kết theo cả hai chiều, đủ để tách „chưa từng đến“ khỏi „đã đến và không được trả lời“. Trên Linux, /proc/net/xfrm_stat đếm các lỗi tổng hợp như thiếu trạng thái, thiếu chính sách và lỗi giao thức. Những tổng đó tích lũy từ lúc khởi động và thuộc về một không gian tên mạng duy nhất, nên một con số lớn không phải là quy kết.
Lấy hai lần đọc quanh cửa sổ sự cố trong đúng không gian tên và so sánh các delta, nếu không bạn sẽ gán lỗi tuần trước vào phiếu của chiều nay. Ghi không gian tên và cả hai dấu thời gian vào phiếu để người đọc tiếp theo có thể tái tạo phép so sánh thay vì tin vào một tổng.
Gọi tên giai đoạn, không phải nghi phạm
Một kết luận hữu ích nói gói đã dừng ở đâu: chưa từng nhận, nhận rồi bị loại bỏ, chuyển giao nhưng không được trả lời, hoặc đã trả lời và bị mất trên đường về. Mỗi trường hợp chỉ ra một chủ sở hữu khác và một lệnh tiếp theo khác. „Không có phản hồi từ máy chủ VPN“ gộp bốn lỗi riêng biệt thành một câu mà bản bắt gói chưa bao giờ biện minh.
Giữ các bản bắt gói hẹp, và để trạng thái nhân thô ra ngoài phiếu, vì nó có thể mang vật liệu khóa không nên rời khỏi máy chủ. Các delta bộ đếm và dấu thời gian là những phần đáng để chuyển cho người tiếp theo.