Gói IKE trùng lặp: tìm bước chuyển còn thiếu

Nhật ký hiển thị cùng một yêu cầu IKE hai lần, ai đó chỉ vào đường truyền di động, và phiếu sự cố được đóng bằng một phỏng đoán. Phỏng đoán đó chính là lầm tưởng: một gói lặp lại là quan sát về một lần trao đổi, không phải chẩn đoán về một liên kết. Truyền lại là hành vi bình thường với những quy tắc riêng, và nó xuất hiện trên những đường lành mạnh mỗi khi phản hồi chậm. Hãy theo phản hồi trước khi đổ lỗi cho một giao diện.

Lầm tưởng: một yêu cầu lặp lại chứng minh mất mát trên một liên kết

Hai thứ khác nhau tạo ra bản trùng, và không thứ nào gọi tên thủ phạm. Bên gửi có thể lặp lại yêu cầu vì không nhận được phản hồi, hoặc điểm bắt gói có thể hiển thị cùng một gói hai lần do vị trí nó gắn vào ngăn xếp. Một đầu dò thấy cả lưu lượng vào và ra trên cùng một máy sẽ vui vẻ ghi một gói thành hai, và người vận hành đọc nhật ký đó không có cách nào phân biệt nếu thiếu định danh trao đổi. Hãy coi bản trùng là sự kiện của bộ đếm thời gian cho đến khi bạn nói được mình đang cầm cái nào trong hai.

Hai đường truyền di động làm tình trạng rối tệ hơn chứ không đỡ hơn. Một dòng nhật ký nêu một giao diện, trong khi phản hồi có thể đã đi ra qua giao diện kia, nên giao diện trong thông báo mô tả nơi một gói được thấy chứ không phải hình dạng của cuộc trao đổi. Đó cũng là lý do câu hỏi đầu tiên là bạn đang xem lần trao đổi nào, chứ không phải liên kết nào bị lỗi.

Truyền lại thực sự cho bạn biết điều gì

Trong IKEv2, truyền lại hoạt động như sau: bên gửi lặp lại yêu cầu khi chưa có phản hồi nào đến, và bên trả lời có thể gửi lại phản hồi đã lưu thay vì tính một phản hồi mới. Định danh thông điệp thuộc về lần trao đổi đó, và chính điều này khiến một yêu cầu lặp lại với cùng định danh được nhận ra là giao thức đang chạy chứ không phải một nỗ lực mới. Lần thử đầu thường cần nhiều hơn một địa chỉ nguồn hay một SPI của bên khởi tạo để tương quan, nên bản ghi trao đổi của chính nền tảng tốt hơn danh sách gói. IKEv1 theo các quy tắc khác với định danh khác, và cảnh báo của nhà cung cấp về gói đầu tiên bị trùng không mang cùng ý nghĩa giữa các phiên bản.

Vậy dấu thời gian truyền lại cho bạn biết một bộ đếm thời gian đã hết. Nó không cho biết chặng nào chậm, và chắc chắn không cho biết nhà mạng có lỗi. Đó là những khẳng định riêng biệt, và chỉ khẳng định thứ hai là hữu ích trong một phiếu sự cố.

Hệ quả thực tế là ghi lại lần trao đổi trước khi kết luận. Hãy ghi địa chỉ nhận cục bộ, đường phản hồi mà chính sách đã chọn, bộ giá trị của bên đối tác và các định danh trao đổi vào một chỗ, vì mỗi thứ trả lời một câu hỏi khác khi bản ghi được đọc sau này.

Bốn điểm quan sát như một chuỗi

Hãy nghĩ về lần trao đổi như bốn mắt xích của một chuỗi chứ không phải bốn nơi riêng để nhìn. Mắt xích giữ bằng chứng hoặc vẫn chưa biết, và chuỗi chỉ có thông tin bằng mắt xích yếu nhất đã ghi. Bảng dưới đây là bản kiểm kê: mỗi vị trí có thể chứng minh điều gì và để nguyên điều gì.

Chỉ điền chuỗi ở nơi bạn có quyền truy cập, và đánh dấu phần còn lại là chưa biết thay vì suy diễn. Một móc ghi gói trên một máy không nói gì về những gì máy ở xa nhận được, và một dòng nhật ký ghi rằng đã thấy yêu cầu không phải bằng chứng rằng phản hồi đã từng đi ra. Những khoảng trống trung thực hữu ích hơn một bản ghi trông đầy đủ nhưng dựng từ phỏng đoán.

Tìm bước chuyển đầu tiên còn thiếu

Đi dọc chuỗi từ bên khởi tạo ra ngoài và dừng ở mắt xích đầu tiên không có bằng chứng. Nếu cổng không bao giờ ghi yêu cầu, lỗi nằm trên đường trước nó. Khi cổng ghi cùng yêu cầu lặp đi lặp lại trong khi máy khách không bao giờ ghi phản hồi, hướng quay về là đối tượng bị nghi: địa chỉ nguồn, dịch địa chỉ và lọc ở mỗi ranh giới bạn kiểm soát. Nếu phản hồi đến mà máy khách vẫn không tiến triển, câu hỏi đã rời lớp truyền tải và trở thành chính sách hoặc trạng thái.

Giữ cố định bên đối tác và giao thức trong khi so sánh, và nhớ rằng độ trễ, mất mát, chính sách và trạng thái mỗi thứ tạo ra một dòng thời gian khác nhau. Mạng di động không tự động là nguyên nhân, và đường cố định không tự động đủ tin cậy cho mọi yêu cầu. Hãy bắt cả hai chiều trong khi lần trao đổi còn sống:

tcpdump -ni any -vv 'udp port 500 or udp port 4500'

Khi quyền truy cập dừng trước đầu xa, bản ghi vẫn hữu ích nếu nó nói dừng ở đâu. Bắt gói chỉ trên bên khởi tạo có thể cho thấy một yêu cầu đi ra và không có phản hồi đi vào, điều này thu hẹp lỗi vào mọi thứ sau móc đó mà không giả vờ biết chặng nào đã làm rơi nó. Đánh dấu các mắt xích ở xa là chưa biết và để người tiếp theo có quyền truy cập điền vào. Viết như vậy thì bản ghi vẫn trung thực và vẫn ngắn.

So sánh trước khi thay đổi bất cứ điều gì. Lặp lại cùng yêu cầu tới cùng bên đối tác với cùng giao thức giữ các biến đếm được, trong khi khởi động lại, làm mới khóa hay sửa chính sách giữa hai lần bắt gói phá hủy phép so sánh. Nếu thay đổi là không thể tránh, hãy bắt gói lại ngay sau đó để trước và sau vẫn mô tả cùng một lần trao đổi.

Một báo cáo hữu ích nói gì

Một báo cáo đáng để hành động ghép một yêu cầu với phản hồi của nó và nêu bước đầu tiên không có bằng chứng phía sau. Câu đó chịu được việc bị đọc một tuần sau bởi một kỹ sư không có mặt ở đó, và nó cho người tiếp theo một điểm bắt đầu thay vì một nghi phạm.

Đừng bao giờ làm yếu các kiểm tra danh tính hay mở rộng tập giao thức được phép chỉ để kiểm tra một giả thuyết truyền lại. Hãy lưu các gói và bản ghi sự kiện gốc trước mọi lần khởi động lại, vì khởi động lại phá hủy đúng thứ tài liệu bạn định thu thập và xóa mất mốc thời gian cho thấy lần trao đổi kẹt ở đâu.

Lầm tưởng là một bản trùng chứng minh nhà mạng có lỗi. Thực tế là một bản trùng chứng minh bộ đếm thời gian đã hết, và câu trả lời nằm trên đường phản hồi.