د UID قواعدو سره یو Linux اپ VPN ته نښلول

یو پروګرام په Linux کې VPN ته نښلول ډېری د لارښوونې ستونزه ده، او د اورېدې دېوال قاعده یوازې دا فیصله کوي چې وروسته له لارې انتخاب څه پیښیږي۔ که تاسو د پروګرام UID په OUTPUT کې هغه مهال سره سم کړئ چې تونل لا د ډیفالټ لارې مالک نه دی، قاعده هغه ترافیک غورځوي چې تاسو یې ساتل غوښتل۔ هماغه قاعده هغه resolver پروسه هم نه ویني چې د پروګرام DNS پوښتنو ته ځواب وایي۔ ترتیب سم کړئ، او یو بې امتیاز حساب باوري د ویشل شوي تونل غورونکی کیږي۔

له پرېکړې دمخه حساب ته لاره ورکړئ

د مالک سمون یوې پوښتنې ته ځواب وایي: ایا د دې UID پورې اړوند ځایي ساکټ پاکټ جوړ کړ؟ دا انٹرفیس نه ټاکي، او نه هغه ترافیک لېږدولی شي چې اصلي جدول یې له مخکې د فزیکي NIC له لارې لېږي۔ نو ځکه د سمې لارې پرته UID قاعده پروګرام بندوي نه دا چې بل لوري ته یې واړوي۔

حساب لومړی د هغه خپل جدول له لارې تېر کړئ، بیا دې اورېدې دېوال پایله تایید کړي۔ دا په هغه کوربه کار کوي چې iproute2 یې uidrange پوهیږي، کوم چې ip rule help په یوه کرښه کې راپور ورکوي۔ جدول 100 د تونل له لارې ډیفالټ لاره ساتي، او قاعده یوازې UID 1000 هغه جدول ته لېږي۔ نور هر څه په اصلي جدول کې پاتې کیږي او فزیکي اړیکه کاروي۔

ip rule add uidrange 1000-1000 table 100
ip route add default dev tun0 table 100

دوهم حساب چې بل تونل ته اړتیا لري جدول 101 او خپله قاعده ترلاسه کوي، ځکه دوه پروفایلونه نشي کولی په یو جدول کې دواړه د ډیفالټ لارې مالک وي۔ د NetworkManager پروفایلونه سیسټم-پراخ دي، نو دا برخه په لاس کې پاتې کیږي، او قواعد د بیا پیل په وخت کې ورکیږي، پرته له دې چې یو څه یې بیرته راولي۔ جدولونه د تونل تعریف ترڅنګ د بوت سکریپټ کې ولیکئ، ترڅو بیا نښلېدل یو حساب په غلطه لاره نه پریږدي۔

ولې د loopback استثنا تونل وژني

د قاعدې ډېری کاپي شوي نسخې هغه هر پاکټ غورځوي چې د loopback له لارې نه وځي۔ تونل loopback نه دی، نو هغه بڼه د تونل ترافیک هم غورځوي، او پایله د اورېدې دېوال غلطۍ پرځای د مړ VPN په څېر ښکاري۔

کله چې OUTPUT ځي، کرنل لا دمخه د وتلو انٹرفیس ټاکلی وي، نو -o د پاکټ سرلیک سره نه، بلکې د لارې ځواب سره پرتله کیږي۔ د مالک سمون یوازې په OUTPUT او POSTROUTING کې کتل کیږي، او لېږدول شوي پاکټونه داسې ساکټ نه لري چې هغه یې ولولي۔ دا یوځای والی مانا دا ده چې استثنا باید د تونل انٹرفیس ونوموي او هغه سمون رد کړي، نه دا چې loopback رد کړي۔

loopback لا هم د DROP له پاسه خپل ACCEPT مستحق دی، ځکه د پروګرام لومړی DNS پاکټ lo له لارې ځایي سټب ته ځي۔ دوه قاعدې په دې ترتیب کې کېږدئ، او حساب سټب ته رسیږي، بیا تونل ته، او بل چیرته نه۔

iptables -I OUTPUT 1 -o lo -m owner --uid-owner vpnapp -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner vpnapp ! -o tun0 -j DROP

IPv6 جلا قاعده-ټولګه ده، او یوازې v4 لپاره جوړه ip6tables نه لمس شوی پریږدي۔ هغه پروګرام چې AAAA ریکارډونه غوره کوي بیا به د DROP ته نه رسېدو پرته فزیکي اړیکې له لارې ووځي۔ دواړه قاعدې ip6tables کې منعکس کړئ، یا کله چې تونل v6 پته نه لېږي په کوربه کې IPv6 بند کړئ۔ په لاس اضافه شوي قاعدې هم د بیا پیل په وخت کې ورکیږي، نو هغه netfilter-persistent save سره خوندي کړئ یا هماغه منطق د بوت واحد لخوا لوډ شوي nftables جدول په توګه بیا جوړ کړئ۔

DNS ځوابونه له بلې پروسې راځي

د پروګرام پوښتنه 127.0.0.53 ته د loopback ACCEPT له لارې تېریږي، او هماغه ځای کې د UID سمون ودریږي۔ سټب resolver له خپل خدمت حساب څخه پورته لېږي، نو هغه قاعده چې vpnapp ته تړل شوې ده هېڅکله دوهمه پوښتنه نه ویني۔ که resolver د اړیکې لپاره LAN سرور وټاکي، ځوابونه د فزیکي NIC له لارې بیرته راځي، پداسې حال کې چې د پروګرام خپل پاکټونه په تونل کې پاتې کیږي۔ ښکاره پایله یو کار کوونکی تونل دی چې نومونه یې مات شوي، یا هغه نومونه چې هغه سرور ځواب ورکوي چې تاسو نه دي ټاکلی۔

د نومونو حل په تونل اړیکه کې سم کړئ، نه په اپلیکیشن کې۔ تونل پروفایل ته DNS سرور او د لارښوونې ډومین ورکړئ، بیا resolvectl query او resolvectl status tun0 سره تایید کړئ چې resolver هغه د مهمو نومونو لپاره کاروي۔ د شبکې د نومونو فضا په داخل کې ستونزه ورکیږي، ځکه د فضا resolver یوازې تونل پېژني۔

قاعده له هماغه حساب څخه وګورئ

له کرنل وپوښتئ چې UID کومه لاره ترلاسه کوي، بیا د هماغه حساب په توګه غوښتنه وکړئ او د وتلو پته د خپل حساب پتې سره پرتله کړئ۔ که دواړه یوه پته راپور کړي، قاعده له هغه ترافیک پرته بل څه سره سمون خوري چې تاسو ازمویلی۔ لاندې لومړی امر د پاکټ نه لېږلو سره د لارې پلټنه ښیي، کوم چې د لارښوونې غلطي د اورېدې دېوال غلطۍ څخه بېلوي۔

ip route get 1.1.1.1 uid 1000
sudo -u vpnapp curl -s https://ifconfig.co

شمېرونکي ښیي چې قاعده کله هم فعاله شوې که نه۔ iptables -vnL OUTPUT چل کړئ، د هرې قاعدې ترڅنګ د پاکټونو شمېر ولولئ، او د ریښتیني ترافیک وروسته د DROP ترڅنګ صفر د سمون غلطي وګڼئ۔

لېږدول شوی ترافیک له دې ډیزاین بهر دی۔ د پولې شاته کنټینر یا VM vpnapp ته د مالکیت ځایي ساکټ نه لري، نو د مالک سمون هېڅکله فعال نه کیږي او هغه پاکټونه د FORWARD پالیسۍ پیروي کوي۔ که هغه کار بار باید پوښل شي، جلا یې ازموئ او د پولې یا کنټینر پتې سره تړلې پالیسي ولیکئ۔ ډیزاین هغه وخت ټینګ پاتې کیږي چې جدول، د انٹرفیس استثنا، resolver او v6 قاعدې ټولې یو لوري ته اشاره وکړي؛ له دوی څخه هر یو پرېږدئ او حساب یا بهیږي یا اړیکه له لاسه ورکوي۔