Cách đọc trao đổi IKEv2 đầu tiên trong một bản bắt gói

Các bản bắt gói được thực hiện giữa phiên là lý do thường gặp khiến một vết IKEv2 trông như nhiễu, vì hai bên đã và đang đổi khóa hoặc trao đổi tải trọng mã hóa khi bắt đầu ghi. Thay vào đó hãy bắt đầu bằng một lần thử kết nối mới, để thông điệp đầu tiên trong tệp là thông điệp mở ra cuộc thương lượng. Thứ tự đọc dưới đây giả định điều đó và đánh dấu điểm mà tại đó một gói không còn chứng minh được gì về đầu xa. Bỏ qua bước ấy chính là cách một đường hầm đang hoạt động bị chẩn đoán thành cổng bị chặn.

Xác nhận bạn đang xem trao đổi mở đầu

Một cuộc thương lượng IKEv2 bắt đầu bằng IKE_SA_INIT, loại trao đổi 34, ID thông điệp 0. Bên khởi tạo chọn một SPI khác không, và SPI của bên phản hồi bằng không trong yêu cầu đầu tiên đó và khác không trong phản hồi. Ba sự thật đó tách một lần thử mới khỏi việc đổi khóa hoặc khỏi một thông điệp IKE_AUTH tình cờ nằm ở đầu bản bắt gói.

Các trường tiêu đề đọc được, và các tải trọng đề xuất, trao đổi khóa cùng nonce cũng vậy. Đọc được không có nghĩa là đã xác thực: không bên nào đã chứng minh danh tính tại thời điểm này, và giá trị riêng của Diffie-Hellman không bao giờ xuất hiện trên đường truyền.

In các trường thành bảng thay vì cuộn một khung giải mã, vì việc truyền lại và SPI không khớp trở nên rõ ràng theo cột.

tshark -r ike.pcapng -Y "isakmp" -T fields -e frame.number -e ip.src -e udp.srcport -e isakmp.exchangetype -e isakmp.messageid -e isakmp.initiator_spi -e isakmp.responder_spi

Đọc kết quả theo cặp. Một yêu cầu với ID thông điệp 0 được theo sau bởi phản hồi mang cùng ID đó và một SPI bên phản hồi khác không là một trao đổi, kể cả khi nó xuất hiện ba lần vì yêu cầu đã được truyền lại. Ba yêu cầu giống nhau không phải ba lần đăng nhập, và coi chúng như vậy chính là cách người ta kết luận máy khách đang lặp vòng trong khi nó chỉ kiên nhẫn. Sắp xếp theo ID thông điệp, rồi theo dấu thời gian, và toàn bộ cuộc trò chuyện thu lại thành một danh sách ngắn các lần thử.

Đọc một lần từ chối trước khi đọc một lần thành công

Một phản hồi không tự động là tiến triển. Bên phản hồi có thể trả lời bằng một thông báo cookie và chờ bên khởi tạo thử lại, hoặc bằng INVALID_KE_PAYLOAD nêu tên một nhóm mà nó sẵn lòng chấp nhận thay thế. Cả hai đến dưới dạng thông điệp IKE đúng định dạng, và cả hai đều trông như một trao đổi đã xong với một bộ lọc chỉ đếm gói.

Mở tải trọng thông báo và đọc loại trước mọi thứ khác. Một thách thức cookie nghĩa là bên phản hồi đang tự vệ trước các địa chỉ nguồn giả mạo, và máy khách phải gửi lại kèm cookie. Một nhóm không hợp lệ nghĩa là hai đề xuất không khớp nhau, và không lượng thử lại nào thay đổi được điều đó cho đến khi cấu hình của một bên thay đổi.

Chỉ IKE_AUTH, tức trao đổi thứ hai, mang danh tính được mã hóa và các tải trọng xác thực. Vì vậy một IKE_SA_INIT hoàn tất cho bạn biết hai bên đồng ý về thuật toán và khóa dẫn xuất, và hoàn toàn không nói gì về việc thông tin đăng nhập có được chấp nhận hay không. Cũng hãy chờ hai thông điệp ở đó, và chờ rằng cả hai sẽ mờ đục nếu không có khóa phiên.

Cổng 4500 không phải một giao thức

UDP 500 thường mang trao đổi mở đầu. Khi việc phát hiện NAT đã chạy, IKE chuyển sang 4500 và đặt trước mỗi thông điệp một dấu hiệu bốn byte bằng không không phải ESP. ESP đóng gói trên cùng cổng lại bắt đầu bằng một SPI ESP khác không, và một keepalive NAT một byte là dạng thứ ba xuất hiện khi không có gì khác xảy ra.

Một bộ lọc chỉ khớp cổng sẽ trộn cả ba, vì thế "có lưu lượng trên 4500" quyết định được rất ít. Hãy tách khung nhìn theo giao thức trước khi kết luận bất cứ điều gì về đầu xa.

tshark -r ike.pcapng -Y "udp.port == 4500 && isakmp" -T fields -e frame.number -e isakmp.exchangetype
tshark -r ike.pcapng -Y "udp.port == 4500 && !isakmp" -T fields -e frame.number -e esp.spi

Sự im lặng mô tả điểm quan sát

Các yêu cầu không có phản hồi xác lập đúng một điều: tại điểm bắt gói đó, không có phản hồi nào xuất hiện. Lọc, một tuyến đường gửi phản hồi đi nơi khác, một bên phản hồi không thể tới, hay một bên phản hồi không thích đề xuất đều cho cùng một kết quả rỗng, và một phép thử UDP chung sẽ không phân biệt được chúng.

ICMP không thể tới là bằng chứng thuộc loại khác. Hãy đọc gói được trích dẫn bên trong và xác định thiết bị nào đã phát ra nó, vì sự từ chối mang tính quản trị của một bộ định tuyến không phải lỗi đã được xác thực từ đầu xa.

tshark -r ike.pcapng -Y "icmp.type == 3" -T fields -e frame.number -e ip.src -e icmp.code

Đối chiếu cùng lần thử đó với nhật ký phía máy chủ ở nơi bạn được phép đọc chúng. Yêu cầu có tới không, dịch vụ có trả lời không, và phản hồi dừng ở đâu? Ba câu trả lời đó đưa bạn tới một vấn đề đường đi hoặc một vấn đề chính sách, và chúng tốn ít hơn việc xoay thông tin đăng nhập lần thứ tư.