د میزبان ټرافیک د VM په VPN له لارې روټ کول: شپږ ګڼنې

شپږ ګڼنې، چې په ترتیب سره کیږي، دا فیصله کوي چې ایا یو VM کولی شي د خپل میزبان لپاره د VPN دروازه وي۔ هایپروایزر په دې کې له تاسو لپاره هېڅ نه کوي: ټونل د مېلمه ملکیت دی، روټ د میزبان ملکیت دی، او د دوی تر منځ شبکه عادي روټینګ دی۔ زه دا لیست ساتم ځکه چې یو ګام پرېښودل تل همدا نښه ورکوي، غلې، چې میزبان مېلمه په خوښۍ پنګ کوي خو کوم داخلي شي ته نه رسېږي۔

له لامل پیل وکړئ۔ یا شرکت کلاینټ یوازې د مېلمه په داخل کې نصبېږي، یا پالیسي هغه هماغلته ساتي، او تاسو لا هم له میزبان څخه داخلي build سرور ته اړتیا لرئ۔ که میزبان ته خپل کلاینټ اجازه وي، هماغه وکړئ: په میزبان کې یو ټونل تل له دوو شبکو او NAT څخه غوره وي۔

ګڼنه 1: میزبان ته داسې لینک ته اړتیا ده چې پته ورکړل شي

میزبان باید د مېلمه دویم اډاپټر سره په ورته پریفکس کې انټرفېس ولري۔ VirtualBox کې host-only، VMware Workstation کې host-only یا ځانګړی VMnet، QEMU/KVM کې داخلي پل یا tap وسیله، او Hyper-V کې Internal سویچ ټول وړ دي۔ مېلمه 192.168.56.2، میزبان 192.168.56.1، پریفکس 192.168.56.0/24 هغه ترتیب دی چې په لابراتوارونو کې کاروم۔

QEMU د کاروونکي حالت شبکه (-netdev user، تلوالی SLIRP backend) او VirtualBox NAT په دې ګڼنه کې بشپړ ناکام شي۔ د مېلمه پاکټونه په میزبان کې پروکسي بهیر ته رسېږي، نو میزبان هېڅکله د مېلمه پتې لېږدونکې وسیله نه ویني او د روټ د ښودلو لپاره هېڅ نه لري۔ د Hyper-V Default Switch هماغه کیسه ده۔ که له میزبان څخه ping 192.168.56.2 ناکام شي، ودروئ: وروسته اضافه شوی هېڅ روټ به یې سم نه کړي۔

ګڼنه 2: مېلمه لېږدوي او ژباړي

له میزبان څخه راغلي پاکټونه د host-only سرچینې پتې او داخلي منزل سره راځي، نو مېلمه باید هغه ولېږدوي او بیا د خپل ټونل پتې تر شا یې پټ کړي۔ په Linux مېلمه کې دا لېږد، د FORWARD accept یوه جوړه، او ټونل ته source NAT مانا لري:

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
sudo iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t nat -A POSTROUTING -s 192.168.56.0/24 -o tun0 -j MASQUERADE

د MASQUERADE قاعده هغه برخه ده چې خلک یې پرېږدي۔ شرکت روټرونه په کمه توګه پوهېږي چې 192.168.56.0/24 شته؛ د قاعدې سره داخلي سرورونه د مېلمه ټونل پته ویني او ځواب ورته وایي، او ځواب بیرته مېلمه ته لار مومي۔

د Windows مېلمه نور هم بېډوله دی۔ SYSTEM\CurrentControlSet\Services\Tcpip\Parameters لاندې IPEnableRouter=1 پرته له ژباړې لېږد چالانوي، نو یوازې هغه ځای کار کوي چې شرکت روټینګ مخکې ستاسو host-only پریفکس ته بیرته اشاره کوي۔ Internet Connection Sharing ژباړي، خو شریک اډاپټر 192.168.137.1 ته بیا شمېرنه کوي، نو د میزبان روټونو له لیکلو مخکې هغه پته ولولئ چې واقعاً یې اخیستې ده۔

ګڼنه 3: د میزبان روټونه مېلمه نوموي، نه ټونل

د مېلمه له لارې یوازې هغه پریفکسونه ولېږئ چې میزبان ورته اړتیا لري۔ په Linux کې د هر پریفکس لپاره یو روټ بس دی او پاک بیرته ګرځي:

sudo ip route add 10.20.0.0/16 via 192.168.56.2
ip route get 10.20.30.40

په Windows کې یې معادل route add 10.20.0.0 mask 255.255.0.0 192.168.56.2 دی۔ د ازموینې پر مهال -p پرېږدئ، تر څو بد روټ په بیا چالانېدو کې مړ شي، او کله چې لار کار وکړ نو ورزیات یې کړئ۔ د میزبان تلوالی روټ مه لرې کوئ، پرته له دې چې د میزبان هر اپلیکیشن باید ټونل وکاروي؛ که واقعاً بشپړ ټونل اړتیا وي، دوه /1 روټونه ورزیات کړئ او هایپروایزر شبکې ته مستقیم روټ وساتئ:

sudo ip route add 0.0.0.0/1 via 192.168.56.2
sudo ip route add 128.0.0.0/1 via 192.168.56.2

په Windows میزبان کې د انټرفېس مېټریک هم وګورئ۔ هغه روټ چې د host-only اډاپټر د بندېدو پر مهال ورزیات شو په جدول کې پاتې کیږي خو هېڅکله ټرافیک نه وړي، او د لږ مېټریک لرونکی دویم اډاپټر د هماغه پریفکس پلټنه ګټلی شي۔

ګڼنه 4: DNS د روټ پسې ځي، نه د ټونل تلوالي

روټونه پاکټونه خوځوي؛ د حل کوونکی فیصله کوي چې کوم نومونه پاکټونه جوړوي۔ د میزبان حل کوونکی د بدلولو پر ځای شرکت حل کوونکی شرکت زون ته محدود کړئ، او هغه داسې DNS سرور ته وښایاست چې نوی روټ ورته رسېږي۔ په میزبان کې د systemd-resolved سره:

resolvectl dns eth1 10.20.0.53
resolvectl domain eth1 '~corp.example.com'

په Windows کې د نوم حل تګلارې جدول کې یوه ننوتنه هماغه کار کوي: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53۔ که مېلمه په host-only پته کې خپل حل کوونکی چلوي، پر ځای یې هغه پته وکاروئ، خو یوازې وروسته له دې چې ډاډ ترلاسه کړئ چې په loopback نه، بلکې 192.168.56.2 کې ځواب وایي۔

بیا MTU وګورئ، مخکې له دې چې DNS د ورو پاڼو په خاطر ملامت کړئ۔ د ټونل انټرفېس د میزبان له 1500 بایټي انټرفېس څخه کوچنی دی، نو هغه میزبان چې د DF بټ سره بشپړ اندازې سګمېنټونه لېږي، هغه د مېلمه په داخل کې یوې خوا ورکوي۔ کلاسیکه نښه کاري ping او یو داخلي ویب اپلیکیشن دی چې د TLS لاس ورکولو وروسته ودروي۔ د مېلمه په لېږد لار کې MSS کلېمپ کړئ:

sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

ګڼنه 5: له دواړو خواوو تایید کړئ

له میزبان څخه، داخلي پتې ته traceroute یا tracert باید لومړی هپ په توګه فزیکي دروازه نه، بلکې 192.168.56.2 وښیي۔ په مېلمه کې هغه ورته هڅه وګورئ چې وځي: tcpdump -ni any host 10.20.30.40 host-only خوا ته لېږل شوې غوښتنه او په ټونل کې ژباړل شوې غوښتنه ښیي۔ هغه غوښتنه چې وځي، بیرته راځي او بیا هم میزبان غلې پرېږدي، د بېرته تګ لارې ته اشاره کوي۔

دوه ناکامۍ یې ډېره برخه تشریح کوي۔ یا دا چې د NAT قاعدې نشتوالي له امله د مېلمه ټونل د host-only پریفکس لپاره د بیرته تګ روټ نه لري، یا د میزبان روټ هغې پتې ته اشاره کوي چې مېلمه یې بیا چالانېدو وروسته نه لري۔ د تېرې ناستې یادښتونو ته د باور پر ځای پتې د ip -br addr او ip route get سره بیا ولولئ۔

ګڼنه 6: دا د بیا چالانېدو او هایپروایزر لوړولو لپاره ټینګ کړئ

دواړه نیمې برخې ټینګې وساتئ: په میزبان کې netplan یا NetworkManager د روټ ترتیب، په Windows کې route add ... -p، او په /etc/sysctl.d/ کې net.ipv4.ip_forward=1 د فایر وال د قاعدو ټولګې سره چې په مېلمه کې بیا لوډیږي۔ کله چې ترتیب تایید شو، سمدلاسه د مېلمه snapshot واخلئ، مخکې له دې چې بل شرکت کلاینټ تازه کول راشي۔

کله چې هایپروایزر خپل اډاپټرونه بیا جوړوي، host-only شبکې بیا شمېرل کیږي، او دا په غلې توګه هره هغه روټ او NAT قاعده باطله کوي چې په 192.168.56.0/24 جوړه شوې ده۔ له لوړولو وروسته لومړنۍ درې ګڼنې په ترتیب سره بیا وچلوئ؛ دا یوه دقیقه نیسي او هغه حالت نیسي چې میزبان خپل روټ لا لري خو مېلمه نوي فرعي شبکې ته تللی دی۔

IPv6 خپله خپله دوره غواړي۔ ip6tables قواعد، AAAA ثبتونه او د میزبان روټونو دویمه کورنۍ د IPv4 ترتیب پسې نه ځي، او هغه شرکت خدمت چې د IPv6 له لارې ورته رسېدل کیږي به تل مات ښکاره شي، په داسې حال کې چې IPv4 کار کوي۔

بریالی یا ناکام، په ترتیب سره: میزبان د مېلمه host-only پته پنګ کولی شي؛ مېلمه ټونل ته لېږد او MASQUERADE کوي؛ ip route get داخلي پریفکس لپاره د دروازې په توګه مېلمه بیرته ورکوي؛ شرکت نومونه د محدود حل کوونکي له لارې حلیږي؛ traceroute مېلمه لومړی ښیي؛ او هماغه شپږ ځوابونه د بیا چالانېدو څخه ژوندي پاتې کیږي۔