Khách Hyper-V mất DNS khi VPN của máy chủ kết nối

Khách vẫn ổn sáng nay. Rồi máy chủ khởi động Cisco AnyConnect và VM mất DNS, tin cậy miền và thư mục chia sẻ, dù bên trong không có gì thay đổi. Đường hầm của máy chủ và mạng của khách là hai đường riêng, và kết nối cái này không di chuyển cái kia. Hãy làm việc từ trong khách ra ngoài, và ghi lại những gì bạn thấy trước khi thay đổi bất cứ điều gì.

Những gì khách vẫn có thể thấy

Ghi lại địa chỉ, cổng mặc định và bộ phân giải trong VM, một lần trước khi máy chủ kết nối và một lần sau đó. Khách giữ địa chỉ và chỉ mất phân giải tên có vấn đề về bộ phân giải. Khách chưa từng có tuyến có vấn đề về đường đi, và cả hai cần công việc khác nhau. Từ máy chủ bạn không thể phân biệt chúng, vì vậy việc đọc phải đến từ bên trong.

Ba lần đọc đó, lấy hai lần, là đường cơ sở của bạn. Mọi thứ sau đó được đo so với chúng.

Khách đang dùng lối ra nào

Hyper-V trả lời điều này bằng hai lệnh: Get-VMSwitch liệt kê các switch, và Get-VMNetworkAdapter -VMName TestVM hiển thị switch mà khách được gắn vào. Default Switch là mạng NAT do Windows quản lý; switch ngoài chuyển lưu lượng tới bộ điều hợp vật lý; switch trong không mang gì cho đến khi ai đó thêm NAT hoặc bộ định tuyến. VirtualBox trình bày cùng ba ý tưởng dưới dạng NAT, NAT Network và bridged.

Chế độ quyết định liệu đường hầm của máy chủ có thể quan trọng hay không. Khách NAT được WinNAT dịch và sau đó được ngăn xếp máy chủ chuyển tiếp, nên nó theo bảng định tuyến của máy chủ; với ứng dụng khách đường hầm đầy đủ, lưu lượng của nó là lưu lượng đi vào bộ điều hợp VPN, và bị bỏ khi ứng dụng khách chặn mạng con cục bộ. Khách được bắc cầu trên switch ngoài không bao giờ đến được định tuyến của máy chủ: các khung của nó rời NIC vật lý trực tiếp, nên nó bỏ qua cả đường hầm và chính sách LAN cục bộ của ứng dụng khách.

Chia sẻ đường hầm của máy chủ với Hyper-V

Nếu khách cần đường hầm và không thể chạy ứng dụng khách riêng, Windows có thể chia sẻ kết nối VPN. Mở thuộc tính của bộ điều hợp VPN, vào Chia sẻ và cho phép người dùng mạng khác kết nối qua nó. Trỏ kết nối mạng gia đình tới bộ điều hợp Hyper-V, vEthernet (Default Switch), sau đó thử một yêu cầu mới từ bên trong khách.

Hãy coi cách bố trí này là giải pháp phòng thí nghiệm, vì nó cư xử như vậy. Nó phải được áp dụng lại sau khi ngắt kết nối, kết nối lại hoặc khởi động lại máy chủ. Trong một số bản dựng Windows 11, bộ điều hợp hoàn toàn không có trong danh sách thả xuống, và khi đó con đường này bị đóng.

Cài đặt lại tính năng Hyper-V đã cứu vài khách cứng đầu. Hãy để việc đó sau cùng, và ghi lại trạng thái của khách trước.

Chuyển tiếp cổng khi mạng con bị lọc

VPN của máy chủ lọc mạng con NAT của khách phá vỡ truy cập trực tiếp chứ không phải phân giải tên. VM đang chạy, nhưng ssh [email protected] bị treo, trong khi bản dịch của hypervisor vẫn hoạt động. Chuyển tiếp các cổng mà công việc cần và kết nối tới địa chỉ máy chủ thay vào đó. Các dòng Vagrantfile bên dưới bao gồm SSH và một dịch vụ HTTPS; cả hai được chèn trước khi tải lại.

config.vm.network "forwarded_port", guest: 22, host: 22
config.vm.network "forwarded_port", guest: 3443, host: 3443

Phân giải tên là quyết định riêng và xứng đáng có bản sửa riêng. Bật tính năng bộ phân giải của máy chủ cho bộ điều hợp NAT đó, hoặc cấu hình máy chủ DNS nội bộ bên trong khách bằng tay. Trỏ khách tới bộ phân giải công cộng làm duyệt web hoạt động và phá vỡ mọi tên nội bộ, điều này tệ hơn sự cố vì nó trông giống thành công. Hãy thử một tên mà chỉ bộ phân giải nội bộ biết.

Kiểm tra cho bạn biết nó đã hoạt động

Sau bất kỳ thay đổi nào trong số này, hãy chạy một yêu cầu mới từ bên trong khách khi VPN của máy chủ được kết nối, không phải trước đó. Kiểm tra lại việc chia sẻ sau khi kết nối lại và sau khi khởi động lại, vì một bản sửa chỉ tồn tại qua một trong hai thì không phải là bản sửa. Xác nhận rằng danh sách bộ phân giải của khách khớp với mạng mà lưu lượng của nó thực sự dùng. Sau đó thử chuyển tiếp cổng từ địa chỉ máy chủ, vì thử từ khách không chứng minh được gì. Từ bên trong khách, hai kiểm tra PowerShell bao quát bộ phân giải và cổng được chuyển tiếp:

Resolve-DnsName intranet.corp
Test-NetConnection 192.0.2.10 -Port 22

Ghi lại mọi thay đổi switch hoặc trình điều khiển cùng bước hoàn tác. Hướng dẫn của Microsoft về Hyper-V NAT giải thích Default Switch thực sự là gì, và đáng đọc trước khi bạn tạo mạng NAT thứ hai xung đột với nó.