ایا د VPN امنیتي سویچ د بیا پیل کولو وروسته پاتې کیږي؟ څنګه یې وګورو

بیا پیل کول هغه تر ټولو عامه لاره ده چې خلک پرې امنیتي سویچ ازموي، او همدا هغه ازموینه ده چې تر ټولو ډیر درواغ وایي۔ په کالینټ کې چیک بکس یوازې یو غوراوی دی؛ مهمه دا ده چې ایا څه شی د شبکې سټیک د پورته کیدو او د تونل د واقعي جوړیدو تر منځ بندیز لګوي۔ په Windows کې هغه څه معمولا په Windows Filtering Platform کې یو فلټر وي، په Linux کې د یوې واحدې له خوا پورته شوې د قواعدو ټولګه، په macOS کې pf لنګر، په Android کې د سیستم خپل تل-روښان او قلف بیرغونه۔ دا ترتیبات د بیا پیل په اوږدو کې ډیر توپیر لري، او یوازې د پلیټ فارم کچې ترتیبات د دې دمخه چې څوک ننوځي خپل ځای کې وي۔

بیا پیل درې جلا پوښتنې مطرح کوي

پوښتنه وویشئ۔ لومړی، ایا پالیسي په ډیسک کې په داسې بڼه ده چې په بوټ کې څه شی یې لولي؟ دویم، ایا هغه لوستونکی د هر ترافیک د وتلو دمخه ځوړند دی؟ دریم، ایا پالیسي هغه ترافیک پوښي چې تاسو ته مهم دی، یعنې هر بهیر، دواړه د پته کورنۍ او DNS۔ لومړي ته هو او دویم ته نه ویل دقیقا هغه نیمګړتیا جوړوي چې خلک یې د بیا پیل وروسته نه پاتې کیدونکي امنیتي سویچ په توګه راپور کوي: په پیل کې څو ثانیې ترافیک وتښتي، او هیچا تر هغې پورې نه پوهیږي چې څوک وګوري۔

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

هغه شی ومومئ چې بندیز بیا رغوي

په Linux کې د netfilter قواعد په کرنل کې اوسیږي۔ هیڅ شی یې په بوټ کې بیرته نه لیکي پرته له دې چې تاسو ترتیب کړی وي: iptables-save سره netfilter-persistent، nftables.service پورته کوي /etc/nftables.conf، یا یوه systemd واحده چې ستاسو خپل سکریپټ ځوړندوي۔ وګورئ څه فعال دي، نه هغه څه چې یاد دي مو ترتیب کړي۔

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

له بوټ څو ثانیو وروسته خالي د قواعدو ټولګه د سرلیک پوښتنې ځواب دی۔ په Windows کې له کالینټ خدمت وپوښتئ چې څنګه پیل کیږي، بیا د تونل د ښکته کیدو پر مهال د پلیټ فارم فلټر حالت وباسئ۔

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

دویم فرمان wfpstate.xml په اوسني فولډر کې لیکي۔ هغه فلټرونه ولټوئ چې د بندولو عمل لري او د کالینټ له نښلیدو دمخه شته۔ Base Filtering Engine په بوټ کې ژر پیل کیږي او هغه فلټرونه بیا رغوي چې په تلپاتې بیرغ سره ورزیات شوي وو، له همدې امله ځینې امنیتي سویچونه تر دې دمخه چې د کالینټ کړکۍ موجوده وي ترافیک بندوي او ځینې نه۔ په macOS کې sudo pfctl -s info راپور ورکوي چې pf فعال دی که نه، sudo pfctl -s rules ښيي چې څه پورته شوي، او VPN کالینټونه معمولا خپل قواعد لنګر ته نښلوي نه اصلي ټولګې ته۔ هغه قاعده چې utun3 نوموي کیدای شي د راتلونکي بوټ وروسته بل انټرفیس ته اشاره وکړي، ځکه هغه شمیره د چلیدو پر مهال ورکول کیږي۔

د شبکې پورته کیدو او د تونل پورته کیدو تر منځ تشه وګورئ

خطرناکه موده ټول بیا پیل نه دی، هغه تشه ده۔ انټرفیس په یو وخت کې اجاره او تلوالی لاره اخلي، VPN خدمت په بل وخت کې پیل کیږي، او تونل لا وروسته تصدیق کیږي، ځینې وختونه یوازې وروسته له دې چې کاروونکی ننوځي او د اعتبار اسنادو استازی چلیږي۔ که بندیز په آخر کې تطبیق شي، په تشه کې هر څه ښکاره وتښتي۔

د systemd کوربه په، اټکل مه کوئ بلکې ترتیب ولولئ۔ systemctl cat په VPN او وال دیوال واحدونو کې ځوړند کړئ او After= او Before= ته په نسبت network-pre.target یا network-online.target ولټوئ۔ هغه د وال دیوال واحده چې له network-online.target وروسته ترتیب شوې وي له انټرفیس سره بایي؛ هغه چې network-pre.target غواړي او د هغې دمخه ترتیب شوې وي ګټي۔ په Windows کې معادل پوښتنې د خدمت د پیل ډول او د هغې تړاوونه دي، ځکه هغه خدمت چې Manual ته ټاکل شوی د بوټ پر مهال بهیر نشي بندولی۔ که ستاسو اړتیا د ننوتلو دمخه ترافیک هم رانغاړي، یوازې د وسیلې کچې ترتیب یې پوره کوي: Always On VPN د وسیلې تونل د ماشین سند سره تصدیق کیږي او د کاروونکي له ننوتلو دمخه نښلي، او Microsoft د وسیلې تونل ترتیب مستند کوي له کاروونکي تونل څخه جلا۔ Android بله لاره اخلي، تل-روښان VPN تحمیلوي او له هغې پرته نښلونې له اپلیکیشن بهیر څخه نه بلکې له سیستم څخه بندوي۔

ازموینه ځوړند کړئ، بیا دوه وخت کرښې پرتله کړئ

د هغې مقصد سره بیا پیل کړئ چې که وچویځي هیڅ لګښت نلري، او حالت د تشې وروسته نه بلکې د تشې پر مهال ثبت کړئ۔ تر ټولو پاکه طریقه د بوټ وخت پلټونکی دی: یوه oneshot واحده یا ټاکل شوې دنده چې څومره ژر چې پلیټ فارم اجازه ورکوي پیل کیږي، تلوالی لاره او د وال دیوال حالت ثبتوي، په لنډ وخت کې یوه غوښتنه ازموي او په محلي فایل کې یوه کرښه زیاتوي۔ هغه ثبت journalctl -b -u یا د سیستم لاګ څخه د VPN خدمت د پیل وخت سره پرتله کړئ۔

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

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

که د بوټ پر مهال بندیز نه وي، تطبیق یوه طبقه ښکته کړئ نه دا چې دویم د کالینټ قاعده ورزیاته کړئ۔ د قواعدو ټولګه خوندي کړئ او د شبکې د کاریدو دمخه له یوې ترتیب شوې واحدې څخه یې پورته کړئ، او ډاډه شئ چې هغه واحده د DNS پلټنې یا د شبکې د نصب اړتیا نلري چې باید یې ساتنه وکړي۔ ساحه د وخت په څیر مهمه ده: هغه قواعد چې د کاروونکي ID یا cgroup سره سمون لري هر سیسټم ډیمون له بندیز څخه بهر پریږدي، او هغه ټولګه چې یوازې IPv4 سمبالوي IPv6 او DNS د لاسرسي وړ پریږدي۔

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

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