Hyper-V-gasto perdas DNS, kiam la gastiga VPN konektiĝas

La gasto estis bone ĉi-matene. Poste la gastiganto ekigis Cisco AnyConnect kaj la VM perdis DNS, sian domajnan fidon kaj la kunhavigitan dosierujon, sen ke io ajn ŝanĝiĝis ene de ĝi. Gastiga tunelo kaj gasta reto estas apartaj vojoj, kaj konekti unu ne movas la alian. Laboru de interne de la gasto eksteren, kaj notu tion, kion vi vidas, antaŭ ol ŝanĝi ion ajn.

Kion la gasto ankoraŭ povas vidi

Registru la adreson, la defaŭltan enirejon kaj la solvilon en la VM, unufoje antaŭ ol la gastiganto konektiĝas kaj unufoje poste. Gasto, kiu konservis sian adreson kaj perdis nur nomrezolucion, havas solvilan problemon. Gasto, kiu neniam havis itineron, havas vojan problemon, kaj ambaŭ postulas malsaman laboron. De la gastiganto vi ne povas distingi ilin, tial la legado devas veni de interne.

Tiuj tri legadoj, prenitaj dufoje, estas via bazlinio. Ĉio posta mezuriĝas kontraŭ ili.

Kiun eliron la gasto uzas

Hyper-V respondas tion per du komandoj: Get-VMSwitch listigas la ŝaltilojn, kaj Get-VMNetworkAdapter -VMName TestVM montras tiun, al kiu la gasto estas alligita. La Default Switch estas NAT-reto administrata de Windows; ekstera ŝaltilo transdonas trafikon al fizika adaptilo; interna ŝaltilo portas nenion ĝis iu aldonas NAT aŭ enkursigilon. VirtualBox prezentas la samajn tri ideojn kiel NAT, NAT Network kaj bridged.

La reĝimo decidas ĉu la gastiga tunelo povas entute gravi. NAT-gasto estas tradukata de WinNAT kaj poste plusendata de la gastiga stako, do ĝi sekvas la gastigan itineran tabelon; kun plentunela kliento ĝia trafiko estas la trafiko, kiu eniras la VPN-adaptilon, kaj ĝi estas forĵetata kiam la kliento blokas la lokan subreton. Pontigita gasto ĉe ekstera ŝaltilo neniam atingas gastigan enkursigadon: ĝiaj kadroj forlasas la fizikan NIC rekte, do ĝi preteriras kaj la tunelon kaj la lokretan politikon de la kliento.

Kunhavigi la gastigan tunelon kun Hyper-V

Se la gasto bezonas la tunelon kaj ne povas ruli sian propran klienton, Windows povas kunhavigi la VPN-konekton. Malfermu la ecojn de la VPN-adaptilo, iru al Kunhavigado, kaj permesu al aliaj retaj uzantoj konektiĝi tra ĝi. Direktu la hejman retan konekton al la Hyper-V-adaptilo, vEthernet (Default Switch), kaj poste testu novan peton de interne de la gasto.

Traktu la aranĝon kiel laboratorian solvon, ĉar ĝi kondutas tiel. Ĝi devas esti reaplikata post malkonekto, rekonekto aŭ restartigo de la gastiganto. En iuj Windows 11-konstruoj la adaptilo tute mankas en la falmenuo, kaj tiam ĉi tiu vojo estas fermita.

Reinstalo de la Hyper-V-funkcio savis kelkajn obstinajn gastojn. Konservu tion por la fino, kaj unue notu la staton de la gasto.

Plusendo de havenoj kiam la subreto estas filtrita

Gastiga VPN, kiu filtras la NAT-subreton de la gasto, rompas rektan aliron anstataŭ nomrezolucion. La VM funkcias, tamen ssh [email protected] pendas, dum la tradukado de la hipervidilo ankoraŭ funkcias. Plusendu la havenojn, kiujn la laboro bezonas, kaj konektiĝu al la gastiga adreso anstataŭe. La Vagrantfile-linioj sube kovras SSH kaj unu HTTPS-servon; ambaŭ eniras antaŭ la reŝargo.

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

Nomrezolucio estas aparta decido kaj meritas sian propran riparon. Ŝaltu la solvilan funkcion de la gastiganto por tiu NAT-adaptilo, aŭ agordu la internan DNS-servilon ene de la gasto permane. Direkti la gaston al publika solvilo igas retumadon funkcii kaj rompas ĉiun internan nomon, kio estas pli malbona ol la interrompo ĉar ĝi aspektas kiel sukceso. Testu nomon, kiun scias nur la interna solvilo.

La kontrolo, kiu diras al vi, ke ĝi funkciis

Post iu ajn el ĉi tiuj ŝanĝoj, rulu novan peton de interne de la gasto kun la gastiga VPN konektita, ne antaŭe. Rekontrolu la kunhavigadon post rekonekto kaj post restartigo, ĉar ripeto, kiu postvivas nur unu el ili, ne estas ripeto. Konfirmu, ke la solvila listo de la gasto kongruas kun la reto, kiun ĝia trafiko vere uzas. Poste testu la plusendadon de havenoj de la gastiga adreso, ĉar testi ĝin de la gasto pruvas nenion. De interne de la gasto, du PowerShell-kontroloj kovras la solvilon kaj la plusenditan havenon:

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

Registru ĉiun ŝaltilan aŭ pelilan ŝanĝon kun ĝia malfara paŝo. La gvidilo de Microsoft pri Hyper-V NAT klarigas, kio fakte estas la Default Switch, kaj indas legi ĝin antaŭ ol vi kreu duan NAT-reton, kiu konfliktas kun ĝi.