ولې ستاسو عامه Linux خدمت د VPN له لارې ځواب ورکوي

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

غلط تصور: ځوابونه هغه انټرفیس تعقیبوي چې پرې راغلي

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

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

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

کرنل په رښتیا څه لارښوونه کوي: د سرچینې پته

هغه لاستی چې تاسو ته اړین دی هغه ځایي پته ده چې خدمت یې د ځوابونو لپاره کاروي۔ په کوربه چې د eth0 پته یې بېلګه 192.0.2.10/24 او ګېټوې 192.0.2.1 وي، هغه پته پر انټرفیس موجوده ده۔ په کلاوډ VM کې عامه پته ممکن پورته ژباړل شوې وي او په مېلمه کې نه وي، نو هغه پته وکاروئ چې کوربه یې واقعاً لري۔

د جدول شمېرې یا د قاعدې لومړیتوب له خوندي کولو مخکې اوسنی حالت وګورئ۔ موجودې پالیسي قاعدې کولی شي نوی سیوری کړي، او د همدې شمېرې زوړ جدول ممکن لا دمخه بې اړیکې لارې ولري:

ip -4 addr show dev eth0
ip -4 rule show
ip -4 route show table all

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

نیم ډیفالټ نه، بشپړ د راستنېدو جدول جوړ کړئ

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

ip -4 route add table 100 192.0.2.0/24 dev eth0 src 192.0.2.10
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 from 192.0.2.10/32 lookup 100

د بېلګې کاپي کولو پرځای ریښتینی پریفکس او ګېټوې وکاروئ۔ د on-link ګېټوې سره /32 په توګه تنظیم شوی کلاوډ انټرفیس بلې نښلول شوې لارې ته اړتیا لري، او له غلط پریفکس څخه جوړ شوی جدول په لومړي ټوپ کې ناکامېږي۔ src ځانګړتیا د هغې لارې غوره سرچینه ښیي؛ دا د سرچینې قاعده نه بدلوي۔

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

د سرچینې له مخې د ځانګړي لټون سره تایید کړئ

له کرنل وغواړئ چې د خدمت له پتې یو ازموینه منزل ته لارښوونه وکړي۔ ځواب باید eth0 او WAN ګېټوې ونوموي، نه تونل:

ip -4 route get 198.51.100.25 from 192.0.2.10

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

وروستي لارې او قاعده د هغه شبکه مدیر لاندې کېږدئ چې انټرفیس یې لري۔ د پتې بدلونونه، DHCP نوي کول او د VPN بیا اړیکې ټول د کرنل حالت بیا لیکي، او په لاس زیاتول شوې قاعده له بلې پېښې وروسته ورکېږي یا زړې ګېټوې ته اشاره کوي۔

دا استثنا چېرې درېږي

قاعده له یوې سرچینې پتې څخه په ځایي توګه پای ته رسېدلی ټرافیک معاف کوي۔ دا د Docker خپرول شوي پورتونه، DNAT یا د کوربه له لارې لېږدول شوي خدمتونه نه رانغاړي، ځکه هغه پیکټونه د لېږدول شوي ټرافیک په توګه لارښوونه کیږي او هیڅکله د کوربه ځایي سرچینه په همدې توګه نه لري۔ داسې ډیزاینونه عموماً په انګریس کې ایښودل شوي نښې او د هغې نښې سره سمون لرونکې قاعدې ته اړتیا لري۔

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

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

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