د یوې اپلیکیشن VPN له لارې تېرول پرته له ټول ماشین

د VPN کلاینټ نښلول کیږي، براوزر کار کوي، او هغه یوازینی کمانډ چې تاسو واقعاً ورته اړ یاست لا هم ستاسو د کور له اړیکې راوځي. یا برعکس پیښیږي: تونل د پخواني لارې کنټرول اخلي او محلي فایل سرور له ډیسک ټاپ نه ورک کیږي. ما دا د یو جوړونکي ایجنټ سره تجربه کړ چې باید داخلي آرټیفکټ عکس ته ورسیده، پداسې حال کې چې د کوربه پاتې برخه د دفتر په LAN کې پاتې وه، او کلاینټ یوازې دوه انتخابونه وړاندې کړل، ټول ټرافیک یا هیڅ. غوښتنه دواړو خواو ته یو شان ده، دا پروګرام او نه ټول ماشین، او ډیرو کلاینټونو کې د دې لپاره د تیک بکس نشت دی، ځکه چې د لارې جدول هیڅکله نه پوهیده چې پروګرام څه دی.

ولې د لارې جدول ستاسو پروګرام نه شي لیدلی

کله چې یوه پروسه پاکټ واستوي، سټیک د منزل پته د لارې جدول کې لټوي. نه د اجرا وړ فایل نوم او نه پورټ په دې لټون کې راځي. ډومین نومونه هم د همدې دلیل له امله ناکامېږي: تونل ټرافیک یوې پتې ته رسوي، او کله چې یو نوم پتې ته حل شي، لارښوونه یوازینی اهر دی چې کرنل یې لا لري. له همدې امله "VPN یوازې د دې سایټ لپاره" په پای کې پراکسي مانا لري، او "VPN یوازې د دې پروګرام لپاره" د لږ شمیر میتودونو څخه یو مانا لري.

له دې څخه هیڅ یو د پروسې لپاره لار نه ده. هر یو پرېکړه هغه پوړ ته وړي چې پروګرام، کارن یا د اپلیکیشن خپل تنظیمات لیدلی شي.

یو منزل لا هم لار ده، نه د پروګرام قاعده. په macOS کې معمول لار دا ده چې "ټول ټرافیک د VPN له لارې ولېږه" غیر فعال کړئ او یوه کوربه لار اضافه کړئ: sudo route add -host internal-tuner.example -interface ppp0، چې بیا په دې لرې کیږي sudo route delete -host internal-tuner.example -interface ppp0. لومړی د انټرفیس نوم له دې ځایه ولولئ ifconfig، ځکه چې ppp0 یوازې یوه بیلګه ده. په کوربه لاره کې وائلډ کارډونه نه کار کوي، نو هغه خدمت چې له څو نومونو سره خبرې کوي د هر نوم لپاره یو داخله ته اړتیا لري، او قاعده په ماشین کې هرې پروسې ته رسي، نه یوازې هغې ته چې تاسو یې په فکر کې و.

ساکټ د تونل پتې سره وتړئ

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

import socket
s = socket.socket()
s.bind(("10.8.0.2", 0))
s.connect(("build.internal.example", 443))

لوړې کچې وسیلې همدا نظر ښیي: curl --interface 10.8.0.2، CURLOPT_INTERFACE په PHP کې او source_address دلیل د Python HTTP کلاینټونو کې. پته باید د تونل وي، او دلته د ټایپ تېروتنه د عادي اړیکې تېروتنې په توګه ناکامېږي، نه د لارښوونې شکایت. د پتې پرځای د وسیلې نوم سره تړل د Linux امتیاز دی او Windows یا macOS ته نه ځي، له همدې امله د لېږد وړ سکریپټونه پته لیږي.

Linux: خاوند سره سمون وخورئ، نه د پروګرام نوم

کرنل کولی شي د ساکټ خاوند کارن سره سمون وخورئ، نو یو ځانګړی حساب ټاکونکی کیږي. تونل په خپل لارې جدول کې کېږدئ او یوازې د هغه حساب ټرافیک هلته ولېږئ:

ip rule add uidrange 1001-1001 lookup 100
ip route add default dev tun0 table 100

دا یوازې هغه وخت کار کوي چې تونل لا دمخه پخوانۍ لاره نه وي. کلاینټ په --route-nopull سره پیل کړئ، یا هغه رالیږل شوی ریډایرکټ د --pull-filter ignore "redirect-gateway" په مرسته OpenVPN 2.4 او وروستو کې فلټر کړئ، بیا د جدول داخله پخپله اضافه کړئ. که نه، دواړه پخوانۍ لارې شته او لږ لومړیتوب لرونکې ګټي. د دې قصدې بڼه دا ده چې پخوانۍ لاره د تونل ګیټوې ته واړوئ، یا له منښل سکریپټ نه یې وکړئ: دا ټرافیک له انټرنیټ نه لرې ساتي کله چې تونل ولوېږي، خو دا یو وژونکی سویچ دی، نه ټاکونکی، او تر هغه پاتې کیږي چې څوک یې لرې کړي.

پیاوړې بڼه یې د شبکې نوم ځای دی. جوړ یې کړئ، کلاینټ دننه وچلوئ، او اپلیکیشن په ip netns exec سره پیل کړئ. له نوم ځای نه بهر هیڅ شی د تونل انټرفیس نه ویني، نو اپلیکیشن په ناڅاپي ډول کوربه لارې ته نه شي کولی. لګښت ریښتینی دی: نوم ځای ته د فزیکي شبکې رسیدو لپاره د veth جوړه او خپل ریزالور فایل ته اړتیا ده، ځکه چې د نصب نوم ځای د کوربه د نوم حل تنظیمات نه شریکوي.

دوه ناکامۍ بڼې ډیرې ویستنې تشریح کوي. د نوم حل لا هم د کوربه په ریزالور کې کیږي، نو پوښتنه له تونل نهر راوځي حتی کله چې TCP اړیکه دننه ځي. او IPv6 ته خپله ip -6 rule ته اړتیا ده، ځکه چې v4 قاعده یې نه پوښي.

Windows او macOS: فایر وال محدود کړئ یا پراکسي وسپارئ

Windows هم د اپلیکیشن لپاره د لارې ټاکونکی نه لري، خو د فایر وال قواعد کولی شي یو پروفایل ته محدود شي، او VPN اډاپټر کولی شي عام وګڼل شي پداسې حال کې چې کورنی LAN شخصي پاتې کیږي. د پروګرام لپاره په شخصي او ډومین پروفایلونو کې د وتلو بندیز قواعد جوړ کړئ، عام خلاص پرېږدئ، او اپلیکیشن یوازې د تونل له لارې شبکې ته رسیږي. لومړی د اړیکې شبکه طبقه وټاکئ، بیا د فایر وال د څار پینل کې تایید کړئ چې قاعده سمه وه. دا بندیز دی، لار نه: کله چې تونل ولوېږي په بند حالت کې ناکامېږي، او هغه اپلیکیشن نه شي بندولی چې فایر وال له پامه غورځوي.

macOS همدا منطق د بلو وسایلو سره تعقیبوي. د SSH له لارې رسیدونکی SOCKS اوریدونکی ترټولو لږ مداخله کوونکی انتخاب دی، ځکه چې ssh -D 1080 user@host یو محلي پورټ جوړوي او یوازې هغه اپلیکیشنونه چې د هغې کارولو لپاره تنظیم شوي وي هغه لار اخلي. یوه pf قاعده کولی شي پروګرام د کارن یا ګروپ له مخې بند کړي، خو بیا هم یوازې د هغه پروګرام لپاره تونل نه شي ټاکلی. Tunnelblick د ډومین له مخې فلټر نه شي کولی، ځکه چې لارې له پتو سره کار کوي؛ د OpenConnect کاروونکي vpn-slice ته مخه کوي کله چې سرور ډیر پراخه مخکښ لیست رالیږي.

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

د هغو وسیلو لپاره SOCKS ټوپ چې د تړلو انتخاب نه لري

ډیرې اپلیکیشنونه کولی شي HTTP یا SOCKS پراکسي ته واوړي حتی کله چې د انټرفیسونو په اړه هیڅ نه پوهیږي. SSH کلاینټ د سرور په خوا کې د هیڅ بدلون پرته یو وړاندې کوي:

ssh -N -D 127.0.0.1:9999 [email protected]

هر څه چې د دې پورټ کارولو لپاره تنظیم شوي وي د کلا په خوا راوځي پداسې حال کې چې د ډیسک ټاپ پاتې برخه خپله عادي اړیکه ساتي. یو محلي 3proxy بېلګه چې د تونل پتې سره تړل شوې وي د SSH پرته د یو پورټ لپاره همدا کار کوي، او stunnel یوازې یو د TLS پوښل شوی پورټ پوښي. محدودیتونه عملي دي: پراکسي یوازې هغه پروتوکولونه وړي چې د هغې کارول پوهیږي، UDP د SOCKS5 UDP یوځای کیدو ته اړتیا لري چې د ډیرو کلاینټونو "SOCKS5" تنظیم یې نه فعالوي، او DNS باید د پراکسي له خوا حل شي (socks5h په curl کې) که نه نوم محلي ریزالور ته ویستل کیږي.

اوریدونکی په لوپ بیک کې وساتئ پرته له دې چې بل ماشین ورته اړتیا ولري.

لاره د کیپچر سره وازموئ، نه د حالت پیغام سره

د اپلیکیشن حالت کړکۍ تنظیم بیانوي، نه پاکټ. په دواړو انټرفیسونو ټرافیک ونیسئ او پرتله یې کړئ:

tcpdump -i any -n port 443
ss -tnp | grep 443

که اړیکه په فزیکي انټرفیس کې ښکاره شي او په تونل کې یې سمون لرونکې داخله نه وي، ټاکونکی په کار کې نه دی، هر څه چې کلاینټ راپور ورکړي. IPv6 او ریزالور جلا وګورئ، او د دوهمې لارې لټون وکړئ لکه مرستندویه پروسه یا میراثي سیسټم پراکسي.

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