د Pi په هټسپاټ کې کليانټان د TUN VPN له لارې کور LAN ته نه رسېږي

ځایي Wi-Fi او Ethernet کليانټان د Pi هټسپاټ سره نښلوي، د هغه له DHCP حد څخه پته اخلي او پرته له شکایت انټرنیټ پاڼې باروي. بیا همدغه کليانټان کله چې په کور LAN کې د فایل شریکول یا ویب انټرفېس پرانیزي وخت ورته پای ته رسېږي، په داسې حال کې چې Pi پخپله د تونل له لارې هغه LAN ته رسېږي. په بېسیمه طبقه کې هېڅ خراب نه دی. هغه څه چې ورک دي د لارې ورکړل شوی تړون دی: د هټسپاټ مخکښ باید TUN انټرفېس ته وړل شي، او په کور خوا کې باید یو څه پوه شي چې څنګه ځوابونه هلته بېرته واستوي. دواړه نیمې باید شتون ولري مخکې لدې چې یو پاکټ سفر بشپړ کړي.

درې نښلونې چې درې جلا دندې لري

د Linux Ethernet پل چوکاټونه د منزل MAC پتې له مخې لېږي. OpenVPN په TUN حالت کې IP پاکټونه وړي او په بشپړه توګه د MAC طبقه نه لري، نو ځایي پل زیاتول تونل هېڅکله د پورت په توګه ثبت نه کوي. د کرنل TUN/TAP اسناد هغه جلاوالی تشریح کوي: TAP وسیله د Ethernet انټرفېس په څېر ښکاري، TUN وسیله نه. هغه ډیزاین چې دوه ځایي پورټونه پل کوي او بیا لارښوونه کوي، روټر دی، هر څه چې د انټرفېسونو نومونه ووایي.

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

موډم هم د کليانټ پل څخه بهر وساتئ. PPP نښلونه د بل لیبل سره Ethernet وسیله نه ده، او د pppd مستند ډیفالټ-لار منطق د IPCP خبرو اترو وروسته کار کوي او کله چې هغه لینک ولوېږي خپله لار بېرته اخلي. د DHCP کاپي کول او هر usb0 ته ppp0 نوم ورکول د ګېټوې، میټریک یا ژوند دوره په اړه هېڅ ثابت نه کوي.

مخکې لدې چې هر تنظیم سم کړئ مخکښونه وټاکئ

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

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

لومړی حوض هغه underlay پته ده چې ټلېکام موډم ته ورکړې؛ باید د هر کليانټ-مخ ته پلان څخه بهر پاتې شي. دویم د تونل فرعي شبکه ده چې سرور غوره کړې، ډېری وخت خپله شخصي /24 شبکه. درېیم د هټسپاټ پل دی، او څلورم هغه کور مخکښ دی چې غواړئ ورته ورسیږئ. په دې تګ کې هټسپاټ 172.28.90.0/24 اخلي، پل پر 172.28.90.1 دی، او د کور خدمت LAN 192.168.77.0/24 ساتي، چې د مصرف کوونکو روټرونو سره راغلي 192.168.1.0/24 او 10.0.0.0/24 ډیفالټونه او د ټلېکام 100.64.0.0/10 حد نه تېرېږي.

د هټسپاټ په DHCP حد کې یوازې د پل پته د ګېټوې په توګه اعلان کړئ او نور هېڅ. هټسپاټ کليانټانو ته هېڅکله د ګېټوې په توګه د کور پته مه ورکوئ؛ دوی د هغه برخې ته د لینک طبقې لار نه لري.

هر لوری په هغه خوا کې لارښوونه کړئ چې مالک یې دی

Pi د تونل له لارې د کور مخکښ لپاره لارې ته اړتیا لري. په سرور حالت کې سرورونه معمولاً هغه لاره ټېله کوي، نو لومړی ډاډ ترلاسه کړئ چې لېږد فعال دی او کرنل د tun0 څخه د کور پته حل کوي.

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

که ip route get لا هم د underlay انټرفېس راپور ورکوي، هلته ودرېږئ؛ په لاره کې نور هېڅ ناسمه لټون نه شي سمولای.

د کور وسایلو ته 172.28.90.0/24 ته لار نشته، نو ځوابونه یې ډیفالټ ګېټوې تعقیبوي او په روټر کې مري. دوه ملاتړ شوي سمونونه شته. یا په کور روټر کې یوه ثابته لار زیاته کړئ چې هټسپاټ مخکښ VPN سرور LAN پتې ته اشاره کوي، یا کله چې سرور پخپله ګېټوې وي، د کليانټ مخکښ په سرور خپل لارښوونې جدول کې ثبت کړئ. د OpenVPN په څو-کليانټ حالت کې کليانټ-ځانګړې ډایرکټري هغه اړیکه وړي: د کليانټ سند عام نوم ته نومول شوې فایل، چې iroute 172.28.90.0 255.255.255.0 او هغه سره سمون لرونکې route کرښه لري چې هغه په سرور کرنل کې نصبوي. په سرور باندې اټکل شوې کرنل لار د سرور ته د دې ویلو سره سمه اعلامیه نه ده چې کوم کليانټ مخکښ مالک دی.

د دې کار کولو لپاره د کور شبکې DHCP خدمت VPN سرور ته مه انتقالوئ. د یوې ټولې کور لپاره ډیفالټ ګېټوې بدلول له یوې شخصي بېرته راستنېدو لارې زیاتولو څخه ډېر لوی بدلون دی، او DNS، د پتو زیرمې او هر هغه وسیله چې نوی کرایه نه مني ناکامۍ ته ښکته کوي.

لېږد پرانیزئ پرته لدې چې د فایر وال اټکل وکړئ

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

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

د br0 څخه tun0 ته د منلو قاعده او سمون لرونکې ځواب لوری، او داسې postrouting قاعده وپلټئ چې سرچینه بیا ولیکي. که د زنځیر تګلاره drop وي او هېڅ قاعده سمون ونه لري، تنګ منل زیات کړئ او بیا ازموینه وکړئ، نه دا چې تګلاره accept ته واړوئ.

ژباړه اړتیا نه ده، د تګلارې غوره کول دي. د کور LAN په لوري سرچینه NAT هر هټسپاټ کليانټ د Pi د تونل پتې په څېر ښکاره کوي، چې په کور ثبتونو کې د هر کليانټ نسبت له لاسه ورکوي او هغه خدمتونه ماتوي چې اصلي سرچینه تمه لري. پرته له NAT لارښوونه د کليانټ پتې ښکاره ساتي خو پورتنۍ بېرته راستنېدو لارې ته تړلې ده. یوه وټاکئ او DNS او IPv6 ته هماغسې چلند وکړئ، ځکه چې د ماتې IPv6 لارې ترڅنګ فعاله IPv4 لار لا هم په براوزر کې نیمه ماتې لوستل کېږي.

د تګ راتګ سفر تایید کړئ، بیا یې په قصد مات کړئ

له هټسپاټ کليانټ څخه ازموینه وکړئ، هېڅکله له Pi څخه نه، ځکه چې د Pi خپل ترافیک د مخکې او بېرته لارې دواړه پریږدي. دواړه انټرفېسې وګورئ کله چې یو کليانټ د کور خدمت ته د رسېدو هڅه کوي.

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

دواړه ثبتونه یوځای ولولئ. پر br0 غوښتنې چې هېڅکله پر tun0 نه ښکاري مانا چې Pi لېږد نه کوي یا لار بلې خوا ته اشاره کوي. پر tun0 پرته له ځواب غوښتنې مانا چې کور خوا بېرته لار نه لري یا سرور پاکټ فلټر کړی. پر tun0 ځوابونه چې هېڅکله پر br0 بېرته نه ښکاري مانا چې د معکوس فلټر قاعده ورکه ده، چېرې چې تونل بشپړ ښکاري او کليانټ لا هم هېڅ نه ویني.

بیا لاره په قصد مات کړئ. د موډم نښلونه ښکته او بیا پورته کړئ او د لارې او ثبت ازموینې بیا وچلوئ؛ هغه لار چې تونل ته ژوندی پاتې کېږي خو د بیا نښلونې پر مهال ورکېږي د نښلونې پروفایل پورې اړه لري، نه یو ځلې امر ته. ډاډ ترلاسه کړئ چې د تونل لېږد لا هم د underlay له لارې وځي او نه د خپله ځانه، دا هغه کلاسیکه حلقه ده کله چې ټېل وهل شوې ډیفالټ لار پرته لدې چې پیر ته د هوسټ لار وي منل کېږي.

ډیزاین یوازې هغه وخت ومنئ چې هټسپاټ کليانټ د کور نوم حل کړي، TCP خدمت پرانیزي او یوه غونډه د یو موډم بیا نښلونې په اوږدو کې ژوندۍ وساتي. که یو اپلیکیشن واقعاً په کور برخه کې د Ethernet کچې کشف غواړي، د دې پر ځای چې ځایي پل د پل شویو په توګه تشریح کړئ او د خپرونې انتظار وکړئ، ملاتړ شوی Layer 2 ډیزاین وټاکئ.