Đường hầm hoạt động trên mạng văn phòng và bị kẹt ở nhà, và nhật ký cho thấy lần trao đổi đầu tiên hoàn tất trước khi bất cứ điều gì khác xảy ra. Mẫu đó chỉ vào trao đổi xác thực, không phải thông tin đăng nhập: chuỗi chứng chỉ làm thông điệp đó lớn hơn nhiều so với thông điệp trước, và một đường đi không thích datagram lớn sẽ âm thầm bỏ nó. Có hai cơ chế phân mảnh khác nhau liên quan, và biết mình đang nhìn cơ chế nào sẽ quyết định cách sửa.

Hai cơ chế phân mảnh, một triệu chứng

IKEv2 có phần mở rộng phân mảnh riêng, được định nghĩa trong RFC 7383, chia các thông điệp IKE được bảo vệ thành các thông điệp IKE nhỏ hơn. Hai bên thương lượng khả năng đó, và thông điệp được triển khai IKE lắp ráp lại chứ không phải lớp IP.

Phân mảnh IP thông thường là cơ chế khác với kiểu hỏng khác. Bộ định tuyến giữa hai bên phân mảnh một datagram lớn, hoặc bỏ nó và trả về thông điệp ICMP có thể không bao giờ đến người gửi. Một số mạng âm thầm bỏ mảnh, và một số thiết bị trung gian xử lý mảnh đầu nhưng không xử lý phần còn lại. Từ góc nhìn ứng dụng, cả ba trường hợp trông giống nhau.

Đi qua NAT thêm một biến thứ ba, vì khi đó ESP được bọc trong UDP và gói bên ngoài lớn hơn trong khi trông giống lưu lượng UDP thường trên cổng 4500. Một đường đi cho UDP qua tốt vẫn có thể hỏng với datagram không còn vừa.

Đọc lần trao đổi đã hỏng

Tìm sự chuyển tiếp thay vì lỗi. Nhật ký cho thấy lần trao đổi đầu được gửi và được trả lời, rồi không có gì, nói với bạn rằng thông điệp tiếp theo chưa bao giờ hoàn tất. Tạm thời nâng mức nhật ký và so sánh kích thước được báo trên cả hai bên.

Điều bạn muốn xác lập là bên trả lời có nhìn thấy yêu cầu hay không. Nếu bên khởi tạo đã gửi gì đó mà bên trả lời không có bản ghi nào về nó, vấn đề là việc gửi đến. Nếu bên trả lời đã phân tích yêu cầu và từ chối nó, vấn đề là chính chứng chỉ, và phân mảnh chỉ làm phân tâm. Sự khác biệt đó đáng giá hơn một trang thông điệp hết thời gian.

Đổi đường đi, không đổi chứng chỉ

Thử cùng máy khách, cùng chứng chỉ và cùng cấu hình từ một mạng khác. Điểm phát di động thường là đường thứ hai rẻ nhất, và nó thực sự khác với liên kết văn phòng, không chỉ trên danh nghĩa.

Nếu bắt tay hoàn tất trên đường thứ hai, chuỗi chứng chỉ ổn và đường đầu tiên là biến số. Nếu nó hỏng giống hệt trên cả hai, hãy ngừng thử mạng và nhìn vào chính các thông điệp. Một phép so sánh đó loại bỏ khoảng một nửa các giải thích khả dĩ.

Đo lần trao đổi trước khi sửa bất cứ điều gì

Lấy kích thước của chuỗi và kích thước của đường đi. Cả hai con số đều giới hạn những gì bắt tay có thể gửi, và cả hai đều rẻ để đo:

openssl crl2pkcs7 -nocrl -certfile chain.pem | openssl pkcs7 -print_certs -noout | grep -c subject
ls -l chain.pem
ping -M do -s 1400 198.51.100.7
ip -s link show eth0 | sed -n '1,6p'

Hai mục đầu cho số lượng chứng chỉ và kích thước tệp, đây là chỉ báo hợp lý cho việc thông điệp xác thực sẽ lớn đến đâu. Phép thử ping báo cáo liệu một datagram cỡ đó có sống sót qua đường đi không, và bộ đếm giao diện cho thấy các mảnh có bị bỏ ở phía bạn không. Trên Windows, phép thử tương đương là ping với cờ do-not-fragment và kích thước tải trọng rõ ràng.

Lặp lại phép thử theo hướng giảm dần cho đến khi thành công. Kích thước lớn nhất đi qua là ngân sách làm việc cho đường đó, và nó hữu ích hơn bất kỳ giá trị mặc định nào được công bố.

Sửa lớp thực sự bị hỏng

Nếu đường đi bỏ datagram lớn, hãy bật phân mảnh IKE trên cả hai bên và xác nhận rằng phần mở rộng đã được thương lượng chứ không chỉ được đề nghị. Nếu đường đi xử lý mảnh kém ở mức IP, cách sửa thuộc về nơi đó hoặc MTU của giao diện ngoài, không phải kho chứng chỉ.

Nếu chuỗi dài không cần thiết, hãy cắt nó xuống các chứng chỉ trung gian mà một bên thực sự cần. Việc bỏ một gốc mà máy khách đã tin tưởng là bảo trì hợp lý; bỏ một chứng chỉ trung gian thì không, và tắt xác minh để thu nhỏ thông điệp là đánh đổi vấn đề gửi đến lấy vấn đề bảo mật.

Ghi lại cơ chế nào bạn đã thay đổi và bắt tay trông thế nào sau đó. Lần xuất hiện tiếp theo thường ở một mạng khác với cùng triệu chứng, và ghi chú chính là thứ biến hai giờ thành mười phút.

Bài viết liên quan