Máy ảo Azure không tới được IMDS hay WireServer sau khi VPN khởi động

Máy ảo đang chạy, ứng dụng VPN báo đã kết nối, và vài phút sau agent Azure bắt đầu báo trạng thái không khỏe. Đôi khi SSH vẫn sống còn Run Command từ cổng thì không, khiến người ta nhìn agent thay vì bảng định tuyến. Các quyết định chuyển tiếp của khách đã thay đổi khi đường hầm dựng lên, và hai địa chỉ nền tảng thường là nạn nhân đầu tiên. Tôi xem đó là triệu chứng định tuyến trước khi xem là lỗi agent.

Triệu chứng trông như agent hỏng

Cả hai địa chỉ bên dưới đều được đề xuất như cách sửa, nhưng chúng không phải cùng một dịch vụ. Sao chép một /32 cho cái này vì nó đã hiệu quả với cái kia chính là cách một giải pháp tạm thời trở thành cấu hình vĩnh viễn mà không ai dám gỡ.

Thứ tự hiệu quả là xác nhận lời gọi thất bại thực sự nhắm tới địa chỉ nào, rồi đọc cách khách phân giải nó. Mọi thứ khác là đoán mò với thêm bước và cửa sổ thay đổi dài hơn.

168.63.129.16 không phải đích công cộng

168.63.129.16 là địa chỉ nền tảng ảo đặc biệt của Azure, và một trong các vai trò của nó là WireServer, thứ agent máy ảo dùng để nói chuyện với fabric. Microsoft ghi rõ lưu lượng của agent tới cổng TCP 80 và 32526 phải luôn sẵn sàng. Đây không phải máy chủ internet thông thường, và không phải thứ mà VPN đường hầm đầy đủ nên mang tới một lối ra từ xa. Đó là lý do một đường hầm trông khỏe vẫn có thể bỏ đói agent.

Tài liệu về địa chỉ nền tảng cũng nói địa chỉ này không chịu sự điều chỉnh của tuyến do người dùng định nghĩa, đó là thuộc tính của fabric Azure chứ không phải lời hứa về khách của bạn. Một quy tắc tường lửa cục bộ hoặc chính sách định tuyến của ứng dụng VPN vẫn có thể làm gãy đường đi, và cả hai đều không sống trong bảng định tuyến của VNet.

Nếu agent là bên báo sự cố, hãy kiểm tra trạng thái dịch vụ và đường tới địa chỉ đó trước khi cài lại bất cứ thứ gì.

169.254.169.254 có quy tắc riêng

169.254.169.254 là địa chỉ link-local của Azure Instance Metadata Service. Các yêu cầu tới đó có yêu cầu riêng: NIC chính và IP chính, cấu hình DHCP hỗ trợ địa chỉ, và bỏ qua mọi proxy HTTP. Gửi chúng qua lối ra VPN từ xa hay một cổng internet tùy tiện không phải mô hình truy cập mà Microsoft mô tả.

Điều khoản proxy đó bắt những người đã sửa tuyến mà vẫn thấy lỗi. Proxy HTTP trong khách có thể làm hỏng IMDS trong khi ip route get trả về đúng giao diện bạn mong đợi, nên hãy kiểm tra cả ngoại lệ proxy lẫn tuyến.

Đừng dán phản hồi metadata vào phiếu hỗ trợ khi gỡ lỗi việc này. Chúng có thể mang thông tin đăng nhập và chi tiết phiên bản sống lâu hơn sự cố.

Đọc định tuyến chính sách của khách, không chỉ bảng chính

Trên khách Linux, ba lệnh chỉ đọc tách các lớp: ip -4 rule show cho quy tắc chính sách, rồi ip -4 route get 168.63.129.16 và ip -4 route get 169.254.169.254 cho các quyết định mà nhân thực sự đưa ra. Chạy chúng trước và sau khi VPN kết nối. Chênh lệch giữa hai đầu ra đó là tập thay đổi của bạn, và nó hữu ích hơn mọi phỏng đoán về việc ứng dụng đã làm gì.

Ứng dụng VPN cài quy tắc chính sách có thể để bảng chính nguyên vẹn mà vẫn chuyển hướng các tra cứu đó. Đó là lý do cách sửa chỉ bảng chính có vẻ hiệu quả trên máy này và không làm gì trên máy kế tiếp. Khách nhiều NIC thêm cùng vấn đề từ phía ngược lại, vì câu trả lời phụ thuộc vào NIC và địa chỉ nguồn mà quy tắc chọn.

Chống lại công thức thêm cả hai tuyến /32 qua cổng cũ. Đường nền tảng link-local và bước nhảy WAN tổng quát là hai đối tượng khác nhau, và một ngoại lệ bao trùm che giấu xung đột chính sách thật.

Tách quản trị và phục hồi

Phản hồi SSH hoặc RDP của bạn cũng có thể bị mặc định đường hầm đầy đủ bắt, nhưng nó nhắm tới địa chỉ quan sát được của quản trị viên chứ không phải điểm cuối nền tảng. Chẩn đoán nó từ cặp yêu cầu-phản hồi của chính nó, và giữ một kênh phục hồi độc lập như bảng điều khiển nối tiếp trước khi đổi chính sách VPN. Nếu triển khai khởi động lại máy ảo và agent báo không khỏe, hãy xem hành động đã ghi và dịch vụ chịu trách nhiệm thay vì cho rằng thay đổi tuyến đã gây ra việc khởi động lại.

Sau đó xác minh ba luồng riêng rẽ: tài nguyên riêng bạn thực sự muốn, liên lạc agent và nền tảng được hỗ trợ, và đường quản trị. Khôi phục một luồng không phải bằng chứng hai luồng kia sống sót.

Ghi ngoại lệ đã duyệt dưới tên chủ sở hữu mạng khách và cấu hình VPN, gồm cả điều gì xảy ra khi kết nối lại và khởi động lại. UDR của Azure không phải bảng định tuyến của khách, và sửa chúng sẽ không sửa được quy tắc chính sách cục bộ.