د Hyper-V میلمه هغه وخت DNS له لاسه ورکوي چې د کوربه VPN وصل شي

میلمه نن سهار سمه وه. بیا کوربه Cisco AnyConnect پیل کړ او VM خپل DNS، د ډومین باور او شریک فولډر له لاسه ورکړ، پرته له دې چې دننه یې څه بدل شوي وي. د کوربه تونل او د میلمه شبکه جلا لارې دي، او یو ځای کول بل نه خوځوي. د میلمه له دننه بهر کار وکړئ، او مخکې له دې چې څه بدل کړئ هغه څه ولیکئ چې ګورئ.

میلمه لا هم څه لیدلی شي

په VM کې پته، ډیفالټ ګیټ وې او حل کوونکی یو ځل د کوربه له وصل کیدو مخکې او یو ځل وروسته ثبت کړئ. هغه میلمه چې خپله پته یې ساتلې او یوازې د نومونو حل یې له لاسه ورکړی، د حل کوونکي ستونزه لري. هغه میلمه چې هېڅکله لاره نه لري، د لارې ستونزه لري، او دواړه جلا کار ته اړتیا لري. له کوربه تاسو نشئ کولی دوی سره توپیر وکړئ، نو لوستل باید له دننه راشي.

هغه درې لوستل، دوه ځله اخیستل شوي، ستاسو اساس کرښه ده. هر څه چې وروسته وي د هغوی پر وړاندې اندازه کیږي.

میلمه کومه وتنه کاروي

Hyper-V دې ته په دوو کمانډونو ځواب ورکوي: Get-VMSwitch سویچونه لیست کوي، او Get-VMNetworkAdapter -VMName TestVM هغه ښیي چې میلمه ورسره نښلول شوې ده. Default Switch هغه NAT شبکه ده چې Windows یې مدیریت کوي؛ بهرنی سویچ ترافیک فزیکي اډاپټر ته سپاري؛ داخلي سویچ هغه وخت پورې هیڅ نه وړي چې یو څوک NAT یا روټر اضافه کړي. VirtualBox همدغه درې مفکورې د NAT، NAT Network او bridged په توګه وړاندې کوي.

حالت فیصله کوي چې ایا د کوربه تونل کولی شي په بشپړ ډول اهمیت ولري۔ NAT میلمه د WinNAT لخوا ژباړل کیږي او بیا د کوربه سټیک لخوا مخې ته وړل کیږي، نو د کوربه د لارې جدول تعقیبوي؛ د بشپړ تونل کلینټ سره د هغې ترافیک هغه ترافیک دی چې VPN اډاپټر ته ننوځي، او کله چې کلینټ ځایي فرعي شبکه بنده کړي نو وغورځول شي. په بهرني سویچ باندې پله شوې میلمه هېڅکله د کوربه روټینګ ته نه رسي: د هغې فریمونه مستقیم فزیکي NIC څخه وځي، نو هم تونل او هم د کلینټ ځایي-LAN پالیسي پریږدي.

د کوربه تونل د Hyper-V سره شریکول

که میلمه تونل ته اړتیا لري او خپل کلینټ نه شي چلولی، Windows کولی شي د VPN اړیکه شریکه کړي. د VPN اډاپټر ځانګړتیاوې پرانیزئ، شریکولو ته لاړ شئ، او نورو شبکه کاروونکو ته اجازه ورکړئ چې د هغې له لارې وصل شي. کورني شبکه اړیکه Hyper-V اډاپټر ته اشاره کړئ، vEthernet (Default Switch)، بیا د میلمه له دننه نوی غوښتنه وازموئ.

دا ترتیب د لابراتوار حل په توګه وګڼئ، ځکه چې دا همداسې چلند کوي. باید د جلا کیدو، بیا وصل کیدو یا د کوربه بیا پیل وروسته بیا پلي شي. په ځینو Windows 11 جوړښتونو کې اډاپټر په ښکته لیست کې په بشپړ ډول نشته، او بیا دا لاره بنده ده.

د Hyper-V ځانګړتیا بیا نصبول ځینې سرسختې میلمنې وژغورلې. هغه د پای لپاره وساتئ، او لومړی د میلمه حالت ولیکئ.

د پورټ مخې ته وړل کله چې فرعي شبکه فلټر شي

هغه کوربه VPN چې د میلمه NAT فرعي شبکه فلټروي مستقیم لاسرسي ماتوي، نه د نومونو حل. VM روانه ده، بیا هم ssh [email protected] ځړیږي، پداسې حال کې چې د هایپر وایزر ژباړه لا هم کار کوي. هغه پورټونه چې کار ته اړتیا لري مخې ته واستوئ او پرځای یې د کوربه پتې سره وصل شئ. لاندې Vagrantfile کرښې SSH او یوه HTTPS خدمت پوښي؛ دواړه د بیا لوستلو مخکې اضافه کیږي.

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

د نومونو حل جلا پرېکړه ده او خپل اصلاح ته اړتیا لري. د هغه NAT اډاپټر لپاره د کوربه حل کوونکي ځانګړتیا فعاله کړئ، یا د میلمه په دننه کې داخلي DNS سرور په لاس تنظیم کړئ. میلمه عامه حل کوونکي ته اشاره کول لټون کاروي او هر داخلي نوم ماتوي، کوم چې د قطعې څخه بدتر دی ځکه چې د بریا په څیر ښکاري. هغه نوم وازموئ چې یوازې داخلي حل کوونکی یې پېژني.

هغه کتنه چې تاسو ته وایي دا کار وکړ

د دې بدلونونو له هر یوه وروسته، د کوربه VPN وصل حالت کې د میلمه له دننه نوی غوښتنه چل کړئ، نه مخکې. د بیا وصل کیدو وروسته او د بیا پیل وروسته شریکول بیا وګورئ، ځکه چې هغه اصلاح چې یوازې یو یې زغمي اصلاح نه ده. تایید کړئ چې د میلمه حل کوونکو لیست د هغې شبکې سره سمون لري چې ترافیک یې واقعیا کاروي. بیا د کوربه پتې څخه پورټ مخې ته وړل وازموئ، ځکه چې د میلمه څخه ازموینه هیڅ نه ثابتوي. د میلمه له دننه، دوه PowerShell کتنې حل کوونکی او مخې ته وړل شوی پورټ پوښي:

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

هر سویچ یا ډرایور بدلون د هغه د بیرته راګرځولو ګام سره ولیکئ. د Microsoft لارښود د Hyper-V NAT په اړه تشریح کوي چې Default Switch واقعیا څه دی، او دا د دوهم NAT شبکې جوړولو مخکې چې ورسره ټکر ولري لوستل ارزښت لري.