Các phản hồi DPD chứng minh IKE peer còn sống, không phải dữ liệu của bạn đang chảy
Phản hồi về sự sống, một thông báo đệm và các bộ chọn đã thu hẹp mô tả ba thứ khác nhau. Hãy đọc riêng chúng trước khi đổ lỗi cho một thứ vì một lần dừng.
Nhật ký IPsec có thể hiển thị phản hồi về sự sống trong khi ứng dụng phía trước đang đứng yên, và cả hai sự thật đều có thể đúng cùng lúc. Một phản hồi DPD xác nhận rằng xử lý IKE của peer đã trả lời tại thời điểm đó; nó không nói gì về việc SA con có mang gói tin bạn quan tâm hay không. Coi mọi cảnh báo gần một sự cố là nguyên nhân của nó chính là cách một vấn đề bộ chọn bị chẩn đoán thành lỗi giao thức. Có ba quan sát thường bị nhầm lẫn nhất, và chúng trả lời ba câu hỏi khác nhau. Hãy đọc chúng theo liên hệ và mục đích trước khi đọc theo dấu thời gian.
Mỗi quan sát chứng minh điều gì
Bảng phân tách điều mỗi quan sát xác lập khỏi điều nó chỉ đi kèm.
| Observation | What it establishes | What it leaves open |
|---|---|---|
| DPD replies arrive | The peer's IKE process answered | The child SA, forwarding path and application reply |
| TFC padding notification | The peer will not accept padding for that child SA | Whether ordinary ESP protection still works, which it does |
| Selectors reported as narrowed | The accepted traffic set is a subset of the offer | Whether the subset includes the flow the user needs |
Không quan sát nào trong ba là lỗi tự thân. Mỗi quan sát chỉ trở nên đáng chú ý bên cạnh luồng bạn đang gỡ lỗi, và một hàng không thể gắn với luồng cụ thể là ngữ cảnh, không phải bằng chứng.
Sự sống không phải sức khỏe dữ liệu
DPD chạy như một trao đổi INFORMATIONAL, một cuộc trò chuyện ở mặt phẳng điều khiển giữa các daemon IKE. Một phản hồi chứng minh rằng tiến trình IKE của peer có thể tiếp cận và sẵn sàng trả lời, còn hết thời gian chứng minh rằng không. Không kết quả nào kiểm tra SA con, bộ chọn, đường chuyển tiếp hay phản hồi của ứng dụng, nên một DPD khỏe mạnh bên cạnh một phiên truyền bị đứng là bức tranh mạch lạc, không phải mâu thuẫn.
Đó là lý do các dòng về sự sống là phần ít hữu ích nhất của một phiếu ở mặt phẳng dữ liệu, dù chúng trông an tâm đến đâu ở đầu nhật ký.
Thông báo đệm là một phát biểu về đệm
Đệm TFC là dòng bị đọc quá mức nhiều nhất trong các nhật ký này. Nó nói rằng đệm cho tính bí mật của luồng giao thông sẽ không được chấp nhận cho SA con đó, đây là phát biểu về một tính năng đệm tùy chọn chứ không phải từ chối bảo vệ ESP. Tìm thấy nó gần một lỗi thường là sự trùng hợp của việc nhiều lời, và bật hay tắt đệm không thay đổi gì trong phạm vi bao phủ của bộ chọn.
Đặc tả IKEv2 định nghĩa cả thông báo lẫn đàm phán bộ chọn, và nhãn cảnh báo của một triển khai không thay thế ý nghĩa giao thức trong cả hai trường hợp.
Việc thu hẹp im lặng hơn và có nhiều khả năng quan trọng hơn
Bên trả lời có thể chấp nhận một tập con của các bộ chọn được đề nghị, và tập được chấp nhận có thể được in trên nhiều mục, một mục có định cổng và mục kia bao phủ mọi cổng. Chỉ đọc dòng đầu tiên có định cổng sẽ đánh giá thấp điều đã được chấp nhận; chỉ đọc dòng rộng sẽ đánh giá cao nó. Hãy so sánh đề nghị đã in với chính sách đã cài đặt, vì đề nghị là điều các peer đã nói còn chính sách là điều nhân sẽ khớp. Khi chúng không khớp, đường hầm tồn tại còn lưu lượng thì không, đó là khiếu nại gián đoạn kinh điển. Đảo ngược góc nhìn cục bộ và từ xa khi so sánh các peer, vì cục bộ của mỗi bên là từ xa của bên kia.
Các mục dành riêng cho máy chủ có giới hạn cổng đáng được đọc hai lần, vì chính chúng loại trừ ICMP hoặc cổng thứ hai trong khi ping tới cổng vẫn hoạt động.
Xây dựng một bản ghi cho luồng đang hỏng
Ghi lại nguồn, đích, họ địa chỉ, giao thức và cổng như chúng xuất hiện tại quyết định bảo vệ, bao gồm mọi chuyển dịch có chủ ý. Đây là những giá trị phải khớp với một bộ chọn, và cũng là những giá trị mà người ta gõ lại từ trí nhớ khi phiếu đến tay cặp thứ ba.
Sau đó xác định SA con và các bộ đếm theo hướng của nó: swanctl --list-sas cung cấp bản tóm tắt liên kết trên một máy chủ strongSwan, và ip -s xfrm state cung cấp các bộ đếm. Hãy đọc chúng sau một yêu cầu được phép mới chứ không phải khi hệ thống đang rảnh. Không có sự gia tăng lưu lượng đi nào chỉ vào việc chọn hoặc đường cục bộ; lưu lượng đi mà không có lưu lượng đến tương ứng chỉ vào peer, việc chuyển tiếp hoặc các phản hồi của nó.
Một trao đổi ứng dụng hoàn tất cao hơn bất kỳ bộ đếm nào, vì thế bài kiểm tra nên kết thúc ở ứng dụng chứ không phải ở chỉ báo đường hầm.
Chọn cách sửa sau đó
Chỉ khi bản ghi đó tồn tại mới có cách sửa để chọn: bộ chọn đã được chấp nhận, tuyến, lọc, triển khai của peer, hoặc một ranh giới mà bạn vừa chứng minh. Đặt lại peer thay đổi nhiều trạng thái cùng lúc và thường khôi phục lưu lượng mà không giải thích cái nào sai, nên sự cố quay lại. Giữ các bản kết xuất trạng thái nhân ngoài phiếu, vì chúng có thể chứa khóa và bản tóm tắt hẹp là đủ cho bất kỳ ai cần giúp.
Khi bản ghi mâu thuẫn với lý thuyết đầu tiên của bạn, hãy tin bản ghi và viết lại lý thuyết; thói quen đó đáng giá hơn bất kỳ dòng nhật ký đơn lẻ nào được bàn ở đây.