Azure P2S VPN không phân giải được tên điểm cuối riêng tư

Bạn kết nối đường hầm point-to-site, ping địa chỉ riêng tư, mở ứng dụng và nhận 403 hoặc lỗi chứng chỉ thay vì kết quả mong đợi. Cả hai triệu chứng đều chỉ về DNS, nhưng là hai lỗi khác nhau: một nghĩa là máy khách đã phân giải địa chỉ công khai, còn kia nghĩa là máy khách phân giải địa chỉ riêng tư rồi đưa ra một tên mà chứng chỉ không bao phủ. Hãy làm các bước kiểm tra dưới đây theo thứ tự và dừng ở lỗi đầu tiên, vì một mục hosts hoặc câu trả lời trong bộ nhớ đệm có thể khiến mọi bước kiểm tra sau đó đều đạt vì lý do sai. Tôi giữ thứ tự này trong một tệp văn bản cạnh các hồ sơ VPN của mình, vì bản sửa không thay đổi gì ở đường hầm và thay đổi mọi thứ ở những gì máy khách biết.

Bắt đầu từ địa chỉ mà máy khách thực sự nhận được

Hỏi thẳng trình phân giải thay vì tin ứng dụng. Trên Windows, nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net cho biết máy khách đã nhận góc nhìn nào. Câu trả lời công khai nghĩa là không gì ở phía dưới sẽ đến được điểm cuối; địa chỉ riêng tư của điểm cuối nghĩa là DNS đã xong và bước kiểm tra tiếp theo chính là kết nối.

Điểm cuối riêng tư không đổi tên dịch vụ. Tài khoản hoặc ứng dụng giữ nguyên tên đầy đủ thông thường, và điểm cuối chỉ đổi địa chỉ mà tên đó phân giải tới cho các máy khách bên trong mạng ảo. Đó là lý do cùng một tên máy chủ phân giải riêng tư từ một VM trong mạng và công khai từ một máy tính xách tay chưa từng được cấp góc nhìn riêng tư.

Kiểm tra vùng, liên kết và bản ghi trước đường hầm

Ba điều kiện phải cùng đúng: vùng riêng tư tồn tại, nó được liên kết với mạng ảo nơi cổng VPN và các máy khách đi vào Azure, và nó có bản ghi A cho điểm cuối trỏ tới địa chỉ riêng tư. Liên kết vùng với một mạng không liên quan và cổng sẽ tiếp tục phân giải bản ghi công khai trong khi mọi thứ ở đường hầm vẫn trông khỏe mạnh.

Tên vùng thuộc về các dịch vụ, không thuộc về liên kết riêng tư nói chung. App Service thường dùng privatelink.azurewebsites.net, lưu trữ và SQL có không gian tên riêng, và mượn vùng của dịch vụ khác tạo ra một vùng tồn tại nhưng không trả lời được gì hữu ích.

Cấp cho máy khách một trình phân giải mà nó thực sự với tới được

168.63.129.16 trả lời từ các máy ảo Azure và không phải máy chủ DNS cho một máy tính xách tay ở phía bên kia đường hầm point-to-site. Máy khách cần một trình phân giải truy cập được qua đường hầm: điểm cuối vào của Azure DNS Private Resolver, một bộ chuyển tiếp bên trong mạng ảo, hoặc các mục máy chủ DNS được mang trong hồ sơ máy khách VPN để máy khách hỏi thẳng mạng ảo.

Một trình phân giải đã cấu hình nhưng không với tới được hành xử y hệt như không có trình phân giải, và triệu chứng là hết thời gian chứ không phải câu trả lời sai, nên nó bị đọc nhầm thành vấn đề tường lửa. Hãy thử nó bằng một truy vấn mà đường hầm phải mang, không phải bằng một tên công khai vốn dĩ sẽ thành công qua liên kết cục bộ.

Nếu bạn chuyển tiếp thay vì đẩy cấu hình, hãy chuyển tiếp không gian tên mà vùng riêng tư sở hữu, privatelink.azurewebsites.net chứ không phải toàn bộ azurewebsites.net. Một bộ chuyển tiếp có điều kiện nuốt toàn bộ hậu tố cha sẽ gửi mọi tra cứu của dịch vụ tới Azure, kể cả những tra cứu nên ở lại cục bộ.

Dùng tên mà chứng chỉ được cấp cho

Khi địa chỉ đã đúng, lỗi thứ hai lộ ra. Lưu trữ và App Service công bố một bí danh privatelink, và bí danh đó không nhất thiết là tên trong chứng chỉ. Một lần tải lên AzCopy trỏ tới privatelink.blob.core.windows.net đã trượt khâu xác thực; cùng lần tải đó tới <account>.blob.core.windows.net/<container> lại phân giải tới địa chỉ riêng tư và vượt qua, nên nó ở lại đường riêng tư mà không cần bất kỳ cách vòng nào.

Quy tắc đúng trong trình duyệt và cả với App Service: kết nối bằng tên máy chủ mà chứng chỉ bao phủ và để DNS cung cấp địa chỉ riêng tư. Đừng tìm cách vòng qua xác thực, vì nó biến một lỗi đặt tên thành một bước thoái lui về bảo mật. Một ping thành công chứng minh đường đi và không nói gì về tên bên trong bắt tay, nên đây vẫn là những bước kiểm tra riêng.

Một thứ tự bốn bước tách riêng từng lớp

1. Xác nhận máy khách VPN có địa chỉ từ nhóm point-to-site và có đường đi tới địa chỉ riêng tư của điểm cuối.
2. Phân giải đúng tên mà ứng dụng dùng và so câu trả lời với địa chỉ của điểm cuối.
3. Mở kết nối TCP tới điểm cuối trên cổng dịch vụ, rồi đọc tên chứng chỉ được trình bày trên kết nối đó.
4. Chỉ lúc này mới thử phân quyền, vì đường đi hoạt động và chứng chỉ hợp lệ vẫn chưa cấp quyền truy cập tài nguyên.

Một kết nối bị từ chối khi địa chỉ đúng chỉ về nhóm bảo mật mạng hoặc trạng thái kết nối của điểm cuối riêng tư, không phải DNS, nên hãy kiểm tra những thứ đó trước khi sửa lại cấu hình trình phân giải. Tên TLS không khớp đưa bạn trở lại tên máy chủ trong URL và subject của chứng chỉ. Giữ cùng nhau đầu ra phân giải, tên chứng chỉ và URL chính xác; ba giá trị đó giải thích phần lớn các trường hợp này mà không cần chạm vào cổng.

Dùng một VM bên trong mạng ảo làm đối chứng. Nếu tên phân giải riêng tư ở đó và công khai từ đường hầm, vùng và bản ghi đúng và khác biệt duy nhất là đường đi của trình phân giải phía máy khách, thứ xác nhận nhanh hơn một vòng nữa qua cấu hình điểm cuối.

Máy khách cũng lưu bộ nhớ đệm. Một bản ghi đã trả lời công khai mười phút trước vẫn tiếp tục trả lời sau khi bạn sửa vùng, nên hãy xả bộ nhớ đệm trước khi thử lại. Trên Windows, ipconfig /flushdns xóa bộ nhớ đệm của máy khách; các quy tắc chính sách phân giải tên vẫn còn, quyết định hậu tố nào đi tới máy chủ nào, và có thể tiếp tục gửi không gian tên tới trình phân giải mà bạn vừa thay thế.

Một mục hosts nên nằm ở đâu

Thêm địa chỉ của điểm cuối vào tệp hosts là chẩn đoán tốt và thiết kế tồi. Nó chứng minh rằng ánh xạ tên sang địa chỉ là mảnh còn thiếu và cho bạn kiểm tra mọi thứ sau bước đó, nhưng nó vô hình với người dùng của bạn, hỏng khi địa chỉ điểm cuối thay đổi và che mất vùng lẽ ra phải trả lời.

Một mục thử nghiệm còn sót lại tệ hơn một bộ nhớ đệm cũ, vì nó có thể làm đường đã sửa trông như hỏng hoặc đường hỏng trông như đã sửa, tùy theo hướng của lỗi. Hãy xóa nó trước lần chạy cuối và chỉ phân giải bằng trình phân giải của môi trường sản xuất.

Tên ngắn cần hậu tố tìm kiếm còn tên đầy đủ thì không, nên hãy thử tên đầy đủ trước, rồi quyết định xem quy trình làm việc có cần một hậu tố được đẩy qua hồ sơ máy khách hay không. Microsoft ghi lại tên vùng và dạng bản ghi theo từng dịch vụ trong hướng dẫn DNS cho điểm cuối riêng tư của họ; hãy đọc mục cho dịch vụ của bạn thay vì sao chép vùng từ dịch vụ khác.