آیا د Pi د دروازې کوربه نوم په خپله سټاټیک لارې تازه کوي؟

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

د DNS ځواب او لاره بېل شیان دي

فرض کړئ ستاسو Pi vpn-gw.lan ته ځواب وایي او 10.44.0.0/16 یوې تونل ته لېږدوي۔ په 192.168.30.0/24 کې مراجعین د سټاټیک لارې له لارې هلته رسېږي۔ کله چې د Pi پت له 192.168.30.4 څخه 192.168.30.11 ته واوښت، ریکارډ د خپل TTL په موده کې ورسره لاړ او لارې لاړې نه۔

دواړه لیدونه په داسې ډول سره نه جوړېږي چې له لاسه وتل یې اسانه وي، ځکه چې جلا جلا پوښتنې کول دواړه باوري ښکاري:

$ ip route get 10.44.0.1
10.44.0.1 via 192.168.30.4 dev eth0 src 192.168.30.20
$ dig +short vpn-gw.lan
192.168.30.11

یوازې لومړۍ کرښه پرېکړه کوي چې کڅوړې چېرې ځي۔ دویمه کرښه هغې پوښتنې ته ځواب وایي چې کرنل هېڅکله نه ده کړې۔ څو A ریکارډونو لرونکی ریکارډ هم د ناکامۍ پر مهال د بدلون تګلاره نه ګرځي، ځکه چې هر پت باید په هغه برخه کې د کار وړ بله ټوپ وي۔

د کمانډ له پای وروسته په جدول کې څه پاتې کېږي

د Linux لاره دوې مهمې شیان ثبتوي: بله ټوپ د پروتوکول پت په توګه، او د وتلو انټرفیس د انډیکس شمیرې په توګه۔ د rtnetlink د لارې ځانګړنې هغه لومړی ساحه RTA_GATEWAY بولي، او په هغې کې بایټونه ساتل کېږي۔ کله چې ننوتنه خپل ځای ته ورسېده، هېڅ TTL ورسره نه تړل کېږي او هېڅ شالید لټون یې تازه نه کوي۔

له همدې امله ip route add 10.44.0.0/16 via vpn-gw.lan داسې ښکاري چې کار کوي۔ وسیله د کمانډ د چلېدو پر مهال نوم حل کوي، ترلاسه شوی پت لیکي، او نوم په بشپړه توګه هېروي۔ وروسته ip route show 10.44.0.0/16 وچلوئ او تاسو ته لفظي پت بېرته راځي۔

دا چلند د تونل په تورنولو دمخه د پېژندلو وړ دی۔

هغه وسایل چې نوم ستاسو لپاره حل کوي، او کله

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

مدیریت شوي ترتیبات کار ویشي۔ د DHCP زیرمه یا سټاټیک کرایه Pi په یوه پت کې ساتي، او DNS ریکارډ یوازې کرایه تعقیبوي۔ هېڅ شی ته اړتیا نه ده چې خوځېدونکی هدف تعقیب کړي، ځکه هدف نه خوځېږي۔

څارل شوی تازه کوونکی بله قانوني بڼه ده، او مالک ته اړتیا لري۔

پت ټینګ کړئ یا تازه کوونکی پخپله وچلوئ

د یوې کوچنۍ LAN لپاره د DHCP سرور باندې زیرمه ترټولو ارزانه حل دی۔ د متحرک حوض بهر پت وټاکئ، هغه د Pi د MAC پت سره وتړئ، او د بلې کرایې له نوي کېدو وروسته یې د ip -4 addr show dev eth0 سره تایید کړئ۔ بیا د مراجعینو بله ټوپ یو ځل هغه پت ته واړوئ۔ اوس تاسو یوه ټینګه دروازه او هغه ریکارډ لرئ چې هغه بیانوي، او دا هغه ترتیب دی چې دا اړیکه واقعاً پرې کار کوي۔

که Pi واقعاً باید وخوځېږي، د هر مراجع په لاس سمونې پر ځای د لارې سمون په یوه ځای کې وساتئ۔ لنډ سکریپټ چې حل کوي، پرتله کوي او بدلوي، د دې لپاره بسنه کوي چې ګام تکرارېدونکی شي:

new=$(dig +short vpn-gw.lan | head -n1)
cur=$(ip route get 10.44.0.1 | awk '{print $3}')
if [ "$new" != "$cur" ]; then
  ip route replace 10.44.0.0/16 via "$new"
fi
ip route get 10.44.0.1

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

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