Kunhavigi la VPN-seancon de la gastiganto kun VMware-gasto

Tunela adaptilo ne aliĝas al ponto, kaj Windows 10 ne enkursigas inter subretoj. Host-only segmento kun NAT portas la gaston anstataŭe.

Via virtuala maŝino ne atingas internan sistemon, kiu perfekte funkcias ĉe la gastiganto, kaj la gastiganto estas konektita tra kliento, kiu posedas la enkursigan tabelon. Ponti la virtualan adaptilon al la tunelo ŝajnas evidenta kaj malsukcesas pro du apartaj kaŭzoj. Traduko sur segmento, kiun ambaŭ maŝinoj posedas, estas tio, kio funkcias. La kosto estas reala: ĉiu gasto perdas sian propran identecon en la korporacia reto.

Du kaŭzoj, kial la ponto ne povas funkcii

La adaptilo de la kliento kutime portas unu adreson, ofte /32, kaj la kliento reskribas la itinerojn de la gastiganto tiel, ke ordinara elira trafiko preferas la tunelon. Aplikoj ĉe la gastiganto obeas tiun tabelon kaj atingas la privatan sistemon. Pontita gasto tute ne legas la tabelon, ĉar ĝiaj kadroj eliras tra komutilo sub la IP-tavolo.

Meti la tunelan adaptilon en ponton teorie solvus la vojon, kaj la pelilo tion ne akceptos. Windows 10 ankaŭ permesas nur unu pontan aparaton kaj rifuzas la enkursigan rolon, kiu lasus laborejon plusendi inter du subretoj. Kio restas estas fonta traduko. Igigu la trafikon de la gasto ŝajni deveni de la gastiganto, kaj la propraj decidoj de la gastiganto portas ĝin en la tunelon, sen ke la gasto bezonu itineron, kiun ĝi ne povas havi.

Kreu segmenton, kiun posedas la gastiganto

En la redaktilo de virtuala reto, aldonu host-only reton kiel VMnet3 sur prefikso, kiun vi neniel alie enkursigas, ekzemple 172.28.90.0/24. La gastiganto prenas 172.28.90.1 sur tiu adaptilo kaj la gasto aliĝas al la sama komutilo. Malŝaltu la DHCP de la hipervidilo sur tiu segmento, por ke unu adresa servo posedu ĝin.

Konfirmu, ke Windows vidas la interfacon antaŭ ol konstrui ion sur ĝi, ĉar la tuta dezajno dependas de tio, ke tiu adaptilo estas ordinara:

Get-NetAdapter | Format-Table Name, InterfaceDescription, Status
Get-NetIPAddress -AddressFamily IPv4 | Where-Object PrefixLength -eq 24

host-only adaptilo aperas tie kiel ĉiu fizika. Ĝuste tio estas la diferenco de la tunela adaptilo, kiu ne povas esti alligita al io ajn.

Traduku la prefikson de la gasto

Malfermu sesion kun pliigitaj rajtoj kaj traduku la prefikson. Unue kontrolu, kio jam ekzistas, ĉar ujo-runtime kaj hipervidiloj instalas proprajn tradukojn, kaj forigi la malĝustan rompas alian produkton.

Get-NetNat | Format-Table Name, InternalIPInterfaceAddressPrefix, Active
New-NetNat -Name "LabGuestEgress" -InternalIPInterfaceAddressPrefix 172.28.90.0/24

Poste agordu la gaston kun statika adreso en tiu prefikso, 172.28.90.1 kiel ĝia enirejo, kaj la solvilaj adresoj, kiujn la tunelo donas al la gastiganto. Traduko plusendas pakaĵojn kaj instruas al la gasto nenion pri DNS, do gasto lasita sur la loka enkursigilo solvas publikajn nomojn kaj malsukcesas ĉe ĉiu interna.

Kontrolu la unuan salton, poste la koston

Testu la plej proksiman limon antaŭ ol testi aplikaĵon. Spuro, kiu haltas ĉe la enirejo de la gastiganto, signifas, ke traduko ne okazas, dum tiu, kiu haltas trans la gastiganto, signifas, ke la tunelo estas senfunkcia aŭ la fora flanko rifuzis la tradukitan adreson.

tracert -d 172.20.31.10
nslookup intranet.corp.example
Get-NetNatSession -NatName "LabGuestEgress"

Komparu kun la propra aliro de la gastiganto al la sama celo, dum la tunelo funkcias. Se la gastiganto sukcesas kaj la gasto ne, la kulpo estas en traduko aŭ en la enireja agordo de la gasto, ne en la konekto.

Poste akceptu la interŝanĝon. Korporaciaj sistemoj nun vidas unu adreson por ĉiu gasto, do aparataj atestiloj kaj statokontroloj po aparato ne povas distingi ilin, kaj iuj politikoj tute malpermesas tion. Decidu ankaŭ la faligan konduton, ĉar tradukita trafiko povas fali al la ordinara interreta vojo, kiam la tunelo malsukcesas, se vi ne blokas tiun prefikson ĉe la fajroŝirmilo de la gastiganto.

Rilataj artikoloj