DNS Azure P2S thất bại khi resolver nằm trong VNet đã kết nối ngang hàng

Ping VM và nó trả lời; hỏi tên của nó và máy khách nói máy chủ không xác định. Khi resolver nằm trong một mạng ảo đã kết nối ngang hàng thay vì mạng chứa gateway VPN, cặp kết quả đó là điều dự kiến, và không lượng chẩn đoán resolver nào thay đổi được. Điều còn thiếu là một hợp đồng định tuyến mà peering giữ lại theo mặc định. Hai cấu trúc trông gần như giống hệt trên giấy, và khoảng cách giữa chạy được và hỏng là một cặp công tắc peering được đặt đúng hướng.

Hãy hình dung một laptop đang tạo đường hầm vào gateway trong VNet2, trong khi bộ điều khiển miền phục vụ DNS ngồi ở VNet1.

Hai cấu trúc, một khác biệt

Đặt resolver vào chính mạng ảo của gateway và tên được phân giải ngay khi đường hầm dựng lên. Không cài đặt peering nào tham gia vào lần tra cứu đó.

Chuyển cùng resolver đó sang bên kia một peering và máy khách vẫn nhận câu trả lời từ VM trong khi tên vẫn không xác định. Chứng chỉ, đường hầm và máy khách không đổi. Thứ duy nhất di chuyển là nơi resolver sống. Peering đã cho nó một tuyến đến địa chỉ đó, không phải quyền cho gateway chở lưu lượng đến đó.

Phía A: cho phép chuyển tuyến gateway tại chủ sở hữu gateway

Một peering nối hai mạng ảo, nhưng sự nối kết không có tính bắc cầu với lưu lượng đến qua gateway, và yêu cầu điểm-tới-trang đến đúng như vậy. Vì thế gateway trong VNet2 không có cơ sở để giao việc tra cứu cho VNet1 cho đến khi thiết kế cho phép. Sự cho phép là một công tắc trên peering thuộc mạng chứa gateway.

Đặt Allow gateway transit trên peering của VNet2 hướng tới VNet1. Thuộc tính thuộc về đối tượng peering, không phải tài nguyên gateway, nên bạn đọc và thay đổi nó trong lưỡi peering. Đó là toàn bộ phía A.

Phía B: dùng gateway từ xa ở đối tác

Nửa còn lại là hình ảnh phản chiếu: trên peering của VNet1 quay lại VNet2, bật Use remote gateways. Bật cùng cờ đó ở cả hai đầu, hoặc chỉ một đầu, để lại một đường đi xây dở và triệu chứng ban đầu không bị đụng tới. Chỉ mạng có gateway VPN mới cho phép chuyển tuyến, và đối tác là phía sử dụng nó.

Đọc cả hai thuộc tính trên cả hai mạng thay vì tin vào lưỡi cổng thông tin bạn mở lần cuối.

Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet2 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways
Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet1 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways

Nhìn thấy cặp đó cạnh nhau là cách nhanh nhất để bắt một thiết lập bị đảo. Một peering báo AllowGatewayTransit false ở phía gateway giải thích toàn bộ sự cố mà không cần bắt gói tin.

Máy khách vẫn phải nhận được gì

Định tuyến là cần thiết và chưa đủ, vì hồ sơ điểm-tới-trang cũng phải trao cho máy khách một địa chỉ DNS trả lời sau khi chuyển tuyến hoạt động. Resolver của nền tảng không phải địa chỉ đó: nó trả lời các vùng Azure Private DNS liên kết với mạng ảo, nhưng không trả lời gì cho vùng được lưu trữ trên máy chủ thư mục của riêng bạn, và đây chính là thứ mà triển khai này dùng. Trỏ một máy khách vào đó và các tên công cộng phân giải vui vẻ trong khi máy chủ nội bộ vẫn không xác định.

Hỏi resolver từ laptop đã kết nối trước khi thay đổi bất cứ điều gì khác.

nslookup dc01.corp.example 10.1.0.4

Hết thời gian nghĩa là đường đi vẫn còn thiếu. Một câu trả lời có thẩm quyền đẩy vấn đề trở lại máy khách, thường là một hậu tố không bao giờ được thêm vào, nên các tên ngắn đi đến một resolver công cộng khiến chúng thất bại vui vẻ.

So sánh cùng hợp đồng đó ở phía trang-tới-trang

Không điều nào trong số này thuộc riêng về laptop. Thay máy khách bằng một chi nhánh trang-tới-trang và yêu cầu hai phía quay lại: chi nhánh đến trực tiếp mạng của gateway, và một dịch vụ cách hai mạng vẫn ở sau peering.

Chuyển tuyến phải được cấp trên cả hai peering, và công tắc cấp nó nằm trên peering chứ không phải trên loại máy khách.

Trước khi đổ lỗi cho gateway

Windows giữ một danh sách resolver theo từng bộ điều hợp, nên hãy xác nhận giao diện đường hầm thực sự nhận được gì trước khi đổ lỗi cho gateway.

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
ipconfig /flushdns

Một câu trả lời phủ định tồn tại trong bộ nhớ đệm lâu hơn bản sửa định tuyến, và một danh sách hậu tố cũ tiếp tục gửi truy vấn đến nơi chưa bao giờ lưu trữ vùng đó. Xóa đi, hỏi lại, và ghi lại máy chủ nào trả lời.

Hai điều kiện nhỏ hơn quyết định đường đi có giữ được không: các không gian địa chỉ không được chồng lên nhau, và nhóm bảo mật mạng trên mạng con của resolver phải chấp nhận nhóm máy khách, vốn chỉ là một dải nguồn khác. Hãy chứng minh bằng kiểm tra tuyến hiệu lực từ phía VM cộng một truy vấn trực tiếp từ máy khách, để sự cố vùng, sự cố hậu tố hay bộ lọc không bao giờ bị nhầm với chuyển tuyến thiếu.