ولې د سرچینې پورت قاعده ستاسو یو له SSH لارو ماتوي

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

دوه ننوتل، یو د خدمت پورت

کوربه د LAN خوا پته او د VPN پته لري، او sshd په دواړو غوږ نیسي۔ نو مستقیمه ناسته او تونلي ناسته د خدمت پورت شریکوي او یوازې په دې توپیر لري چې کومه ځایي پته اړیکه ترلاسه کوي۔

دا توپیر د ځواب لارې د ټاکلو لپاره بس دی، او دا هغه ټاکونکی توپیر دی چې د پورت پر بنسټ قاعده یې غورځوي۔ دواړه ناستې هغه ځوابونه جوړوي چې د سرچینې پورت یې 22 دی، نو هغه قاعده چې دې پورت سره سمون خوري نشي کولای دوی بېل کړي۔ دا دواړه پلټنې یوې جدولې ته لېږي، او یوه یې داسې ځواب ترلاسه کوي چې سم نه راځي۔ سمون دا دی چې له هغې ځانګړنې سره سمون وشي چې واقعاً توپیر لري۔

هر ننوتلو ته خپل پورت ورکول هم به کار وکړي، او دا د اړتیا په توګه ګڼل د SSH ځانګړتیا نه ده، بلکې د ډیزاین انتخاب دی۔

قاعده ولولئ، بیا جدوله

د سیاست قاعده یوه ترتیب شوې ټاکنې کوونکې ده، او لومړنۍ چې د کارولو وړ ځواب راوګرځوي پلټنه پای ته رسوي۔ لیست په ترتیب سره ولولئ او وګورئ کومه قاعده کولای شي وګټي۔

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

ip -4 rule show
ip route show table 100
ip route show table main

دا دواړه پایلې یوځای نتیجه تشریح کوي؛ هر یو یې یوازې غلط پایلې ته بلنه ورکوي۔

قاعده هغه جریان ته محدوده کړئ چې تاسو یې په زړه کې یاست

هغه ځانګړنه چې دوه ننوتل بېلوي ځایي سرچینه پته ده۔ هغه قاعده چې له دې پتې سره سمون خوري یوازې تونلي ناستې خصوصي جدولې ته لېږي او مستقیمې ناستې په اصلي جدوله کې پرېږدي۔

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

sudo ip rule add from 10.90.0.1 lookup 100 priority 100
sudo ip route add 10.90.0.0/24 dev wg0 table 100
ip route get 10.90.5.20 from 10.90.0.1

که دواړه ننوتل یوې ځایي پتې ته وژباړل شي، دا توپیر ورکېږي او ډیزاین ته پرځای یې د اړیکې خبرېدو حالت ته اړتیا وي۔

اورېدونکی، اجازه او د ځواب ټاکنه بېل وساتئ

درې بېل شیان باید ریښتیني وي مخکې له دې چې ناسته کار وکړي: پته شته، خدمت پرې غوږ نیسي، او ځواب د بېرته تګ لار مومي۔ د لارې بدلون یوازې درېیم سمول کوي۔

د اورېدونکي ترتیبات خپل فایل او خپل بیا بارول لري، او څو اورېدلو پتې نورمالې دي۔ تصدیق بیا درېیمه پرېکړه ده، او د لارې استثنا هیچا ته لاسرسی نه ورکوي۔ په دواړو ننوتلو کې د کوربه کیلي تصدیق، د حساب تصدیق او د سرچینې محدودیتونه وساتئ، او د یوې مدیریتي لارې د کار کولو لپاره د تونل نور کنټرولونه کمزوري کولو هیله مخالفه کړئ۔

هغه بیا رغونې چینل وساتئ چې هغې لارې ته چې تاسو یې بدلوئ تړاو نه لري، ځکه دلته تېروتنه سمون خپله بندوي۔

دا په نوې ناسته سره ثابت کړئ، نه په زړه

جوړ شوی ټرمینل هېڅ نه ثابتوي، ځکه چې د بدلون نه مخکې منل شوی و۔ د هرې موخنې ننوتلې له لارې نوې ناسته پرانیستل کړئ۔

ss -ltnp | grep ':22'
sudo sshd -T | grep -i listenaddress
ssh -v [email protected] true
sudo journalctl -u ssh -n 30

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