د OpenBSD VPN ګېټوې پر tun0 له لارې د LAN NAT

دوه انجنیران چې یو شان OpenBSD ګېټوې لري، ډېری وختونه د لیرې شبکې ته رسېدو لپاره تاسو ته دوه بېلې قاعدې درکوي، او دواړه د دفاع وړ دي۔ د سرچینې ژباړې او د بېرته راستنېدو لارې ترمنځ ټاکنه هېڅ د نحو پوښتنه نه ده۔ ټول هغه څه ته اړه لري چې بل لوري د 192.168.88.0/24 په اړه مخکې پوهېږي او هغه څه ته چې تاسو یې په خپلو ثبتونو کې ساتل غواړئ۔ دلته تېروتنه وکړئ، نو د nat-to کرښه به بشپړ سم ښکاره شي خو ځوابونه به په لیرې اصلي ګېټوې کې ورک شي۔

لارښوونه او بیا لیکنه بېلو پوښتنو ته ځواب وایي

د لارښوونې جدول پرېکړه کوي چې 172.20.0.0/16 د tun0 له لارې د رسېدو وړ دی، او دا پرېکړه له هر pf ژباړې سره له مشورې مخکې کېږي۔ بیا د سرچینې ژباړه د بنډل سرلیک بدلوي تر څو لیرې سر د LAN کوربه پر ځای د ګېټوې د تونل پته وویني۔ هېڅ یوه طریقه بله نه بدلوي: د nat قاعده نه شي کولای لاره پیدا کړي، او لاره نه شي کولای هغه لیرې لارښوونکي قانع کړي چې ستاسو د شخصي فرعي شبکې په اړه یې هېڅکله نه دي اورېدلي۔ کله چې بل لوري ته د بېرته راستنېدو لار نه وي، ځوابونه غورځول کېږي یا د هغه اصلي ګېټوې ته لېږل کېږي، او د قاعدو هر څومره سمون هم دا نه جوړوي۔

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

درې شرطونه چې پرېکړه کوي

درې پوښتنې په ترتیب سره وپوښتئ او ډیزاین معمولاً پخپله ټاکل کېږي۔ ایا لیرې شبکه د 192.168.88.0/24 لپاره د تونل پتې ته د اشاره کوونکې ثابته لاره لري، که د هغې اداره کوونکی پر هغه لار لارښوونکي کنټرولوي؟ که هو، نو د LAN پتې بې بدله پرېږدئ او ژباړه په بشپړه توګه پرېږدئ۔ ایا تاسو ته په بل لوري کې د هر کاروونکي لیدلو ته اړتیا ده، که د لاسرسي تګلارې لپاره او که د پلټنې د نښان لپاره؟ که هو، نو د سرچینې ساتل د لارښوونې د کار ارزښت لري۔ ایا د تونل پته دومره ثابته ده چې په لیرې لاره کې ولیکل شي، که د بیا نښلولو ترمنځ بدلېږي؟

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

ټوټه داسې کېږدئ چې pf په رښتیا یې ارزونه وکړي

لاندې ټوټه فرض کوي چې LAN د 192.168.88.0/24 دی، لیرې شبکه 172.20.0.0/16 ده او د تونل انټرفېس tun0 دی۔ په دې کې هېڅ شی بل ګام نه ټاکي۔ دا یوازې هغو بنډلونو کې سرچینه بیا لیکي چې لا دمخه د تونل له لارې وتلې دي۔

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

د هغې لومړنۍ کرښې دوه تفصیلات ډېر وزن پورته کوي۔ د tun0 شاوخوا قوسونه pf ته وایي چې هرکله چې د حالت نوملیکنه جوړوي د انټرفېس پته ولولي، چې د بیا نښلولو وروسته د تونل د بیا شمېرنې پر مهال اهمیت لري۔ د match کلمه مانا دا ده چې قاعده بیا لیکي او بیا لاندې ورځي، نو جلا pass قاعده باید لا هم جریان ومني۔ په match کرښه کې نومول شوی انټرفېس باید هماغه وي چې د لارښوونې جدول یې ټاکي، که نه نو pf قاعده په هغې بېلې وتنې لار کې ارزوي چې بنډل په رښتیا نه پرې ځي۔

د کرنل لور مه هېروئ۔ IPv4 لېږد باید فعال وي، او د تونل او LAN لپاره حالت لرونکې pass قاعدې باید موجودې وي تر څو دا ټول معنا ولري۔ دلته د کیلودونو ترتیب لپاره د OpenBSD FAQ د PF NAT برخه سمه سرچینه ده۔

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

لومړی د pfctl -nf /etc/pf.conf سره نحو وګورئ، کوم چې دوتنه پرته له لوډولو شنوي۔ بیا تګلاره لوډ کړئ او هغه څه ولولئ چې کرنل په رښتیا ساتي، ځکه چې پاکه شوې قاعده بیا هم تر سیوري لاندې کېدای شي یا له غلط انټرفېس سره ونښلول شي۔ pfctl -sn د ژباړې قاعدې په لوډ شوي بڼه چاپوي، او pfctl -sr د فلټر قاعدې د ارزونې په ترتیب چاپوي۔

بیا تار وګورئ۔ پر ګېټوې tcpdump -ni tun0 'host 172.20.0.10' ښیي چې د تونل څخه وتونکې سرچینه د تونل پته ده که د LAN کوربه۔ ژر netstat -rn -f inet تاییدوي چې منزل کوم انټرفېس ته حل کېږي۔ کله چې ترافیک بهېدل پیل کړي، pfctl -ss د حالت نوملیکنې لیستوي؛ که یوه بهېدنه حالت ونه جوړاوه، بنډل هېڅکله هغې قاعدې ته ونه رسېده چې یو جوړوي۔

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

کله چې ژباړه له سپما څخه ډېره لګښت ولري

ژباړه کاروونکي پټوي، او کله ناکله دا په رښتیا غلطه معامله ده۔ یو پر بل وراوړېدونکې فرعي شبکې یوه پېښه ده: که بل لوری په داخلي توګه 192.168.88.0/24 هم کاروي، نو LAN کوربې د ګېټوې په توګه ښودل ټکر نور هم خرابوي نه چې ښه یې کړي۔ هغه IPsec تګلارې چې ترافیک د پتې جوړه له مخې ټاکي بله پېښه ده، ځکه چې د امنیت تګلارې ډیټابیس له ژباړې مخکې پرتله کېږي او ستاسو بیا لیکل شوی بنډل هېڅکله نه ویني۔ هر هغه ځای پر ځای کول چې د هر کاروونکي له مخې بیل یا محدودیت یا پلټنه کوي، هماغه پېژندنه هم له لاسه ورکوي چې د هغې پېښې پر مهال ورته اړتیا لري کله چې سرچینه یوې پتې ته راټیټه شي۔

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

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