Azure point-to-site kết nối nhưng không tài nguyên riêng nào phản hồi

Đã kết nối là một trạng thái của đường hầm, không phải tuyên bố về khả năng tiếp cận. Một máy khách point-to-site có thể hoàn tất IKE, nhận địa chỉ và vẫn không tới được gì, vì cổng chỉ chuyển tiếp lưu lượng cho những mạng mà VNet đã biết. Hãy làm năm bước kiểm tra này theo thứ tự và dừng ở lỗi đầu tiên. Nhảy cóc chính là cách một sự cố DNS bị coi là sự cố tường lửa trong cả một giờ.

Thứ tự quan trọng hơn danh sách.

Kiểm tra 1: quyết định đường hầm phải mang gì

Azure VPN Gateway kết thúc đường hầm và chuyển tiếp lưu lượng thuộc về VNet; nó không phảimột lối ra internet chung. Nếu người dùng mong việc duyệt web của họ đi ra qua Azure, thiết kế đã sai trước cả khi bất kỳ thiết lập máy khách nào xuất hiện. Bật split tunneling để internet cục bộ vẫn đi theo đường cục bộ, và dùng một phiên bản NAT hoặc đường hầm site-to-site khi thực sự cần một địa chỉ ra cố định.

Viết ra máy khách cần tới đâu trước khi kiểm tra bất cứ điều gì. Không có danh sách đó, mọi kết quả một phần đều trông như tiến bộ.

Kiểm tra 2: so sánh không gian địa chỉ trước chứng chỉ

Sự chồng lấn được xét trên các dải rộng hơn, nên hai mạng trông khác nhau ở mức subnet vẫn đụng nhau nếu các khối cha của chúng chồng lấn. Subnet của cổng phải chuyên dụng và đủ lớn cho SKU, và pool địa chỉ máy khách không được đụng với VNet hay với bất cứ thứ gì tiếp cận được qua peering. Hãy đổi kế hoạch và triển khai lại, vì thêm tuyến để bù đắp tạo ra một đường hầm chạy được với vài đích và không chạy được một cách khó hiểu với những đích khác. Việc cấp phát ở đây thất bại ầm ĩ, và đó là trường hợp tốt.

Xác thực là cổng tiếp theo. Hồ sơ chứng chỉ, RADIUS và Entra ID không thể hoán đổi cho nhau, và gói máy khách khác nhau cho từng loại.

Kiểm tra 3: phân giải một tên riêng từ bên trong

Máy khách giữ trình phân giải của riêng mình trừ khi hồ sơ đã tải xuống mang theo các máy chủ DNS của VNet, và danh sách đó được nhúng ngay lúc tải xuống. Thêm một forwarder bên trong VNet, đặt nó làm máy chủ DNS của VNet, rồi tải xuống và nhập lại gói máy khách. Dùng lại gói cũ chỉ kiểm tra danh sách trình phân giải cũ.

Hãy thử một địa chỉ trước, vì việc đó tách định tuyến khỏi việc đặt tên trong một bước: Test-NetConnection 10.20.1.4 -Port 3389.

Nếu địa chỉ trả lời mà tên không, hãy hỏi trình phân giải trực tiếp bằng Resolve-DnsName files.corp.example -Server 10.20.0.4. Nếu cả hai đều thất bại, lỗi không phải ở DNS và bạn nên ngừng sửa thiết lập DNS. DNS nền tảng Azure tại 168.63.129.16 chỉ trả lời từ bên trong VNet, nên máy khách ở ngoài không thể dùng địa chỉ đó làm trình phân giải.

Kiểm tra 4: kiểm tra dịch vụ phía sau đường hầm

Một đường hầm khỏe và một cổng đóng trông giống nhau từ phía máy khách. Kiểm tra tường lửa của khách, rồi nhóm bảo mật mạng trên subnet hoặc NIC, rồi xem dịch vụ có lắng nghe trên địa chỉ riêng chứ không chỉ trên loopback. Cho phép pool máy khách làm nguồn thay vì mở một quy tắc ra internet, và nhớ rằng SMB tới Azure Files cần đường của điểm cuối riêng được định tuyến qua đường hầm. Khi một tài nguyên trả lời bằng IP nhưng không bằng tên, hãy quay lại kiểm tra 3 thay vì động vào cổng.

Một bảng giữ các lớp tách biệt trong khi bạn làm việc:

Kiểm tra 5: ghi lại hồ sơ trước khi leo thang

Điền loại cổng, loại đường hầm, phương thức xác thực và hệ điều hành máy khách vào phiếu. Hồ sơ IKEv2 có chứng chỉ và hồ sơ RADIUS thất bại vì những lý do khác nhau, và máy khách được tạo cho loại đường hầm khác chỉ kết nối khi cổng cung cấp một giao thức tương thích.

Với một nhóm nhỏ, thiết kế bền vững là một VNet, một forwarder DNS và một máy khách split-tunnel có tài liệu. Nếu yêu cầu là một lối ra công cộng cố định, hãy kết thúc một đường hầm site-to-site trên tường lửa bạn kiểm soát và định tuyến lưu lượng internet tới đó, thay vì yêu cầu cổng point-to-site làm điều nó chưa từng được tạo ra để làm.