VPN S2S trên Azure đã kết nối nhưng không có lưu lượng: đọc nhật ký IKE

Cổng thông tin báo Connected, đường hầm có bộ đếm thời gian hoạt động, và một trace từ máy ảo của bạn chết ở hop thứ hai. Trạng thái kết nối mô tả quá trình thương lượng IKE và IPsec, không phải việc một gói tin có đi qua lớp chính sách ở bên nào hay không. Hai lỗi giải thích phần lớn các phiếu này, và không lỗi nào được sửa bằng cách đổi một tuyến Azure. Cả hai đã được ghi trong nhật ký mà cổng tạo ra, vì thế tôi bắt đầu từ đó thay vì từ bảng tuyến.

Connected thực sự chứng nhận điều gì

Một kết nối site-to-site đã kết nối có nghĩa là pha 1 và pha 2 đã hoàn tất và các hiệp hội bảo mật đang hoạt động. Đó là phát biểu về thương lượng: hai bên đã đồng ý một đề xuất, trao đổi khóa và cài đặt cặp SA. Nó không nói gì về việc bộ chọn lưu lượng có khớp với các mạng con mà bạn cho là được bảo vệ hay không, và cũng không nói về việc bên xa có định tuyến gói tin đi đâu đó sau khi giải mã hay không. Một đường hầm có thể tồn tại nhiều tuần trong khi bỏ mọi luồng đáng quan tâm, và chính mô thức đó khiến người ta dựng lại một cổng vốn đang khỏe mạnh.

Hai lỗi nên kiểm tra trước là một peer đề xuất AH thay vì ESP, và một mạng ảo được đánh số trong không gian mà cổng sẽ không coi là nội bộ.

Mở nhật ký đã xuất trước khi chạm vào tuyến

Trong cổng thông tin, mở cổng mạng ảo và chạy thao tác VPN troubleshoot trên kết nối, sau đó tải gói mà nó tạo ra và giải nén. Bên trong là nhật ký IKE với các trao đổi pha 1 và pha 2, có dấu thời gian và đọc được như văn bản thường. Hãy tìm trong đó dòng transform thay vì đọc từ trên xuống dưới, vì mục đáng chú ý thường nằm sâu vài trăm dòng. Nếu không có quyền truy cập cổng thông tin, cùng các chẩn đoán đó xuất hiện ở đích nhật ký của cổng khi bật cài đặt chẩn đoán.

Hai mục mang phần lớn giá trị. Mục đầu đọc gần giống expected ESP with combined authentication and cipher, received AH. Mục thứ hai là lỗi payload không hợp lệ trong quá trình trao đổi IKE, thường có nghĩa là trường đề xuất bị tạo sai định dạng hoặc không được hỗ trợ.

Cả hai mô tả điều thiết bị tại chỗ đã đề xuất, nên cả hai đều là cài đặt phía peer. Việc tạo lại phía Azure của kết nối không làm thay đổi đề xuất mà tường lửa của bạn gửi đi, và làm vậy dù thế nào cũng là giờ bị lãng phí phổ biến nhất trong quy trình này. Trên peer, đặt pha 2 sang ESP với xác thực và mã hóa kết hợp và để nó thương lượng thuật toán, sau đó kiểm tra xem một hộp kiểm của nhà cung cấp có tên kiểu combined mode có đang âm thầm chọn một đề xuất AH bên dưới hay không.

Xác nhận không gian địa chỉ của mạng ảo

Cổng mong đợi mạng ảo nằm trong dải riêng tư. Một mạng được đánh số trong khối công cộng, ví dụ bắt đầu bằng 111.x, có thể dựng đường hầm lên trong khi Azure từ chối coi không gian đó là nội bộ, nên kết nối trông khỏe mạnh và không luồng nào được chấp nhận. Hãy xác nhận không gian địa chỉ trước khi dành cả buổi chiều cho bộ chọn. Nếu việc đánh số là yêu cầu cứng từ một phân bổ cũ, cách sửa là thay đổi quy hoạch địa chỉ chứ không phải một cổng khác.

Ghi lại phần chồng lấn với các dải tại chỗ khi bạn đang ở trang không gian địa chỉ, vì các tiền tố chồng lấn tạo ra một kiểu hỏng khác mà từ phía máy khách trông tương tự.

Kiểm tra tiền tố theo cả hai chiều

Tài nguyên cổng mạng cục bộ chứa các tiền tố tại chỗ, và chúng phải khớp với các mạng con mà thiết bị từ xa thực sự bảo vệ. Một bản tóm tắt bao gồm các địa chỉ mà thiết bị bỏ đi sẽ cho một số luồng đi qua và hỏng ở các luồng khác, điều này được đọc như một lỗi định tuyến chập chờn chứ không phải sự lệch cấu hình. Hãy xem cả phía xa: một đầu liệt kê /16 trong khi đầu kia liệt kê ba /24 bên trong nó — đó là kiểu hỏng một phần kinh điển. Không danh sách nào tự nó là chuẩn mực, nên hãy so sánh hai danh sách cạnh nhau thay vì tin vào cái bạn nhìn thấy.

Thay đổi tiền tố không phải lúc nào cũng được nhận tự động, nên hãy dự kiến lưu lại hoặc tạo lại đối tượng kết nối rồi xác nhận các tiền tố mới xuất hiện ở cả hai phía.

Kiểm tra một đường đi, không phải một ping

Trace phân biệt một đường hầm hoạt động với một tuyến hoạt động trông như sau: hop đầu là cổng tại chỗ, rồi vài hop không trả lời, rồi máy chủ từ xa trả lời. Nếu trace không bao giờ tới máy chủ, hãy kiểm tra cổng TCP mà ứng dụng thực sự dùng, vì ICMP bị lọc đủ thường xuyên để một ping thất bại chứng minh rất ít. Chạy cùng trace đó từ một máy chủ từ xa về phía máy ảo trong Azure. Sự bất đối xứng giữa hai kết quả là cách nhanh nhất để tìm một tuyến quay về bị thiếu hoặc một quy tắc chỉ cho phép một chiều.

Ghi đề xuất của peer, cả hai không gian địa chỉ và thời điểm tạo kết nối vào phiếu, để kỹ sư tiếp theo biết giá trị nào đã được dựng lại và giá trị nào chưa từng bị chạm tới.

Nếu nhật ký trả về trống, có thể cổng hoàn toàn không kết thúc kết nối của bạn. Hãy xác nhận địa chỉ peer trên cổng mạng cục bộ khớp với thiết bị mà bạn đọc nhật ký, vì hai cổng trong một đăng ký dễ bị nhầm lẫn trong lúc dựng lại. Sai sót đó tốn một ngày và không để lại dấu vết trong bất kỳ nhật ký nào.