ping له VPN پیرودونکي څخه بریالی کیږي، TCP خدمت وخت پای ته رسوي، او ufw allow 443/tcp هیڅ شی نه بدلوي۔ کله چې اپلیکیشن د دروازې په خپله نه بلکې د دروازې شاته مېزبان باندې چلیږي، هغه اجازه د غلط ترافیک لار لپاره لیکل شوې وه۔ بسته د اورېدونکي والټ ته نه ده پته شوې او محلي پروسې ته نه سپارل کیږي، نو د ننوتلو قواعد یې هېڅکله نه ویني۔ حل د لېږدول شوي جریان په نښه کولو لارې قاعده ده، او د هغې شاهد لا دمخه په ثبت کې دی۔

پریکړه وکړئ چې منزل محلي دی که لېږدول شوی

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

د ثبت هغه کرښه چې په IN او OUT دواړو ډګرونو کې یو شان انټرفیس ښیي، بیا هم کولی شي لارښوونکې بسته بیان کړي، ځکه هغه تونل چې پیرودونکي له یوې وسیلې دننه او بهر وړي همداسې ښکاري۔ د منزل پته د انټرفیس نومونو په پرتله دا پوښتنه ژر حل کوي۔ یو نوم دوه ځله لیدل محلي سپارل ثابتوي نه، او د هغه تونل انټرفیس جوړول چې ځای پرځای کول یې هېڅکله نه دی رامنځته کړی هم مرسته نه کوي۔

له هرې قاعدې اضافه کولو دمخه بلاک ولولئ

یوه اجازه شوې د نښلولو هڅه بیا جوړه کړئ او د هغې سرچینه، منزل، پروتوکول او منزل پورټ هغسې ثبت کړئ لکه دروازې چې ثبت کړي دي۔ هغه څلور ارزښتونه د ثبت له ننوتلو او د خدمت له ریښتیني ځای سره پرتله کړئ۔ دمخه بریالی ping یوازې دا ثابتوي چې خپله تبادله یې اجازه درلوده، او اورېدونکی والټ کولی شي د اپلیکیشن پر لور TCP SYN په بشپړه توګه بل ډول وګوري۔

sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered

لومړی حکم فیصله د خپلو ډګرونو سره بېرته راګرځوي، او دویم ښیي چې څه لا دمخه بار شوي او په کوم ترتیب۔ د هر څه سمون دمخه دواړه ولولئ، ځکه ستاسو د قاعدې پورتنۍ پخوانۍ ردېدنه پرته له کومې ورکې قاعدې ورته نښه توضیح کوي۔

تر ټولو تنګه مناسبه لارې قاعده ولیکئ

په دې بېلګه کې پیرودونکي له 172.20.8.0/24 څخه tun0 ته راځي، خدمت د 8443 پورټ پر 10.30.0.15 غوږ نیسي، او دروازه د ens5 له لارې وځي۔ هغه ارزښتونه د دې لپاره غوره شول چې د کلاوډ VPC د تلواله 10.0.0.0/16 یا د کور 192.168.0.0/16 په څېر هېڅ ونه ښکاري، او 8443 بېلګه د دروازې له خپل 443 اورېدونکي لرې ساتي۔

sudo ufw --dry-run route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443

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

د بېرته راتلو لار په حالت سره وساتئ

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

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

sudo ufw route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
sudo ufw status numbered

وګورئ چې UFW ستاسو په استازیتوب څه نشي پلي کولی

سمه قاعده بیا هم د کرنل لېږد او هغې لارې ته اړتیا لري چې خدمت ته ورسیږي۔ دواړه تایید کړئ دمخه لدې چې اورېدونکي والټ ته دویم ځل ملامتیا ورکړئ۔

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

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

د اورېدونکي والټ په فعال حالت کې نوې نښلونه ازموئ او پای ته ورسئ، له یوې اجازه شوې سرچینې او له یوې بې‌اړیکې سرچینې څخه۔ UFW بندول په همدې حکم کې نښه لرې کوي او شاهد له منځه وړي، له همدې امله باید لومړی نه بلکې وروستی تجربه وي۔

اړوندې مقالې