ike-scan không nhận được phản hồi từ một cổng IPsec đang hoạt động

Cổng này phục vụ điện thoại và máy tính xách tay mỗi ngày, vậy mà ike-scan báo cáo không có máy chủ nào phản hồi. Kết quả đó được đọc như bằng chứng rằng thiết bị không có IPsec. Thông thường điều đó có nghĩa là thiết bị đã loại bỏ mọi đề xuất trong lần thăm dò và chọn không trả lời gì cả. Sự im lặng cũng là một phản hồi, và đó là phản hồi ít thông tin nhất mà công cụ này có thể cung cấp cho bạn.

Hãy xử lý ba câu hỏi riêng biệt: gói tin đã đến chưa, có đề xuất nào khớp không, và có thứ gì khác từ chối đối tác không?

Bước 1: đọc đề xuất mà công cụ gửi đi

Chế độ chính bắt đầu bằng tải trọng SA liệt kê các chuyển đổi mà bên khởi tạo sẽ chấp nhận, và ike-scan điền danh sách đó từ giá trị mặc định đã biên dịch. Bộ mặc định cố ý cũ: DES và 3DES để mã hóa, MD5 và SHA1 để băm, nhóm 1 và 2 để trao đổi khóa, khóa chia sẻ trước để xác thực. Không có AES, không có SHA-2, không có nhóm 14. Một cổng được cấu hình cho AES-256 với SHA-256 và modp2048 không chia sẻ gì với bộ này.

Một số triển khai trả lời một lần thăm dò không khớp bằng thông báo NO-PROPOSAL-CHOSEN. Những triển khai khác chỉ đơn giản bỏ qua, điều thường gặp trên các thiết bị coi đối tác lạ là nhiễu. Dù thế nào thì lần quét cũng không in ra gì, và sự không có đó giống hệt với UDP 500 bị lọc khi nhìn từ bên ngoài, như tài liệu dự án ike-scan nói rõ về bộ mặc định.

Bước 2: đề xuất một bộ hiện đại

Thay bộ mặc định bằng --trans. Dạng thuộc tính lấy trực tiếp số thuộc tính IKE: 1 cho mã hóa, 2 cho băm, 3 cho xác thực, 4 cho nhóm và 14 cho độ dài khóa khi thuật toán nhận một giá trị. Kết quả là một dòng bạn có thể đọc to trong buổi xem xét thay đổi.

Dạng vị trí mang cùng các giá trị theo thứ tự và tránh dấu ngoặc, điều quan trọng khi lệnh đi qua một trình bao.

ike-scan --trans="(1=7,14=256,2=5,3=1,4=14)" 203.0.113.10

Một đề xuất mỗi gói là chậm khi bạn liệt kê, vì vậy hãy lặp qua các giá trị hợp lý: mã hóa 5, 7/128, 7/192, 7/256; băm 1, 2, 5, 6, 7; nhóm 1, 2, 5, 14, 15, 19, 20, 21; xác thực 1 cho khóa chia sẻ trước và 3 cho chữ ký RSA. In từng lệnh trước khi chạy để bản ghi cho thấy điều gì đã được đề xuất và theo thứ tự nào.

Bước 3: diễn giải một phản hồi

Một phản hồi chứng minh chính xác hai điều: có một bộ trả lời IKE truy cập được tại địa chỉ đó, và một đề xuất được đưa ra là chấp nhận được. Nó không nói gì về khóa chia sẻ trước, lớp L2TP hay việc tài khoản người dùng có tồn tại hay không. Một lần quét thành công hoàn toàn tương thích với việc mọi giai đoạn sau đó thất bại.

Trên một cổng bạn vận hành, đây là phần thực sự hữu ích. Lần quét cho bạn biết thiết bị vẫn chấp nhận những đề xuất nào, và một kết quả chỉ giới hạn ở các chuyển đổi cũ là một phát hiện về chính sách thiết bị, không phải lý do để làm yếu máy khách.

Bước 4: diễn giải sự im lặng

Sự im lặng là bằng chứng yếu hơn vẻ ngoài của nó. Mọi đề xuất có thể đã bị từ chối, UDP 500 và 4500 có thể bị lọc, nguồn có thể bị giới hạn tốc độ sau một đợt bùng nổ, hoặc dịch vụ có thể lắng nghe ở địa chỉ khác với địa chỉ bạn đã quét. Hãy so sánh nhật ký IKE của cổng với một máy khách đã kết nối bằng thông tin đăng nhập hợp lệ trước khi kết luận bất cứ điều gì về chiếc hộp đó.

Hành vi bùng nổ thuộc danh sách đó vì việc liệt kê tạo ra nhiều gói trong một khoảng thời gian ngắn. Một cổng trả lời những lần thử đầu rồi im bặt đang mô tả chính sách chống DoS của nó chứ không phải bộ đề xuất.

Bước 5: ghi lại những gì bạn đã chứng minh

Viết tổ hợp được chấp nhận bên cạnh phiên bản phần sụn, rồi so sánh với các chuyển đổi mà những máy khách bạn quan tâm cung cấp theo mặc định. Khoảng cách giữa hai danh sách đó chính là vấn đề cấu hình, và lần quét chỉ làm nó hiện ra. Nếu những đề xuất duy nhất được chấp nhận là những thứ bạn sẽ không chọn, thì bản sửa thuộc về chính sách cổng hoặc hồ sơ máy khách, không bao giờ thuộc về lần thăm dò.

Một lần thăm dò không bao giờ trả lời vẫn đã trả lời điều gì đó: nó cho thấy thiết bị này sẵn sàng thảo luận những đề xuất nào, và thích thả rơi những đề xuất nào xuống sàn.