د OpenVPN کلاینټ سرور ته رسېږي خو LAN هوسټونو ته نه: د چک لیست
ټونل پورته دی او سرور ځواب ورکوي، خو د LAN هوسټونه غلی دي۔ پاکټ له کلاینټ لارې تر بیرته راستنیدو لارې پورې تعقیب کړئ، بیا NAT یا ثابته لاره وټاکئ۔
کلاینټ وایي چې وصل دی، د ټونل پته ping ته ځواب ورکوي، او په دفتر LAN کې هېڅ هم ځواب نه ورکوي۔ زه دا له نږدې هر کلاینټ اپډیټ وروسته وینم، او لومړی غریزه د فایر وال خلاصول دي، چې معمولاً غلط ګام دی: ټونل سم دی، او ماتېدل د درې هغو ټوپونو په یوه کې دي چې پاکټ باید تېر کړي۔ لاره په هغه ترتیب وګرځوئ چې پاکټ یې اخلي، لومړی د کلاینټ لاره، بیا د سرور لېږدول، بیا ستنېدنه، او په څو دقیقو کې به د خرابۍ خاوند ومومئ۔
لومړی ګام: د کلاینټ د لارښوونې پرېکړه وګورئ
د سرور د لمس کولو دمخه ثابته کړئ چې کلاینټ پاکټ ټونل ته لېږي۔ له ټول جدول لوستلو پرځای له کرنل څخه وپوښتئ چې د یوه ځانګړي LAN هوسټ لپاره کوم انټرفیس به وکاروي:
ip route get 192.168.50.10که ځواب ستاسو فزیکي اډاپټر او د دفتر ګیټ وې ته نوم واخلي، نو د سرور په اړخ کې هېڅ بدلون مرسته نه شي کولی۔ OpenVPN لارې یوازې هغه وخت وېشي چې سرور یې ټېل وهي، نو په سرور کنفیګ کې push "route 192.168.50.0 255.255.255.0" ولټوئ، او بیا کلاینټ بیا وصل کړئ۔ ډېری کلاینټونه ټېل وهل شوې لارې د وصلېدو پر مهال پلي کوي، نه د پروفایل بیا لوستلو پر مهال۔
په Windows کې همدې پوښتنې بل کمانډ لري۔ Find-NetRoute -RemoteIPAddress 192.168.50.10 هغه انټرفیس او بل ټوپ چاپوي چې سټک به یې غوره کړي، او route print -4 ښیي چې ټېل وهل شوی پریفکس اصلاً شته که نه۔
دویم ګام: تایید کړئ چې سرور به پاکټ ولېږدوي
که د کلاینټ لاره سمه وي، پاکټ سرور ته رسېږي او سرور باید د هغه د لېږدولو سره موافق شي۔ د کرنل سویچ لومړی دروازه دی، او sysctl net.ipv4.ip_forward باید 1 بیرته راولي۔ په echo 1 > /proc/sys/net/ipv4/ip_forward یې ټاکل تر بل ریبوټ پورې کار کوي، او همدا لامل دی چې هماغه شکایت بیا څو اونۍ وروسته راځي۔
دا چېرې ولیکئ چې د ریسټارټ وروسته هم پاتې شي:
echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --systemدویمه دروازه د فلټر جدول دی۔ هغه هوسټ چې Docker پر نصب دی ډېری وخت د FORWARD تګلاره DROP لري، او ټونل هغه پرېکړه په میراث اخلي۔ iptables -L FORWARD -v -n هم تګلاره او هم د پاکټ شمېرونکي ښیي؛ که تګلاره DROP وي، لېږدولو ته د ټونل څخه LAN ته د لوري لپاره یو څرګند اجازه او د ځواب لپاره بله ته اړتیا ده۔
دریم ګام: پاکټ تر LAN پورې تعقیب کړئ او ځواب ولټوئ
د سرور دواړه اړخونه په یو وخت وګورئ۔ په ټونل او په LAN انټرفیس کې ثبت کړئ، یو کلاینټ او یو هوسټ ته فلټر کړئ تر څو پایله لوستل کېدونکې پاتې شي:
tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10هغه غوښتنې چې په tun0 او بیا په eth0 باندې د 10.8.0.x سرچینې سره څرګندېږي، او بیا چوپتیا راځي، مانا دا ده چې پاکټ ورسېد او ځواب بل ځای ته لاړ۔ LAN هوسټ خپل ډیفالټ ګیټ وې ته ځواب ورکوي، هغه ګیټ وې د VPN پول لپاره لاره نه لري، او ځواب په LAN روټر کې مري۔ له سرور څخه LAN هوسټ ته ping کول د دې لارې په اړه هېڅ نه ثابتوي، ځکه هغه ټرافیک هېڅکله ټونل نه تېرېږي۔
څلورم ګام: د ژباړې او ستنېدنې لارې ترمنځ وټاکئ
دوه ترمیمات سوری بندوي، او دا انتخاب د دې نه ور هاخوا پایلې لري چې ping کار کوي که نه۔ د سرچینې ژباړه سرور ظاهري لېږونکی جوړوي:
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADEقاعده پول او LAN انټرفیس ته محدوده کړئ، بیا یې تلپاتې کړئ، که نه نو بله فایر وال بیا لوستل ستاسو ترمیم په خاموشۍ لرې کوي۔ بیه یې پیژندنه ده: هر کلاینټ په LAN لاګونو او د لاسرسي په قواعدو کې د VPN سرور په څېر ښکاري، او per-client policy becomes guesswork۔
په LAN روټر کې د VPN سرور ته اشاره کوونکې د 10.8.0.0/24 لپاره ثابته لاره د کلاینټ پتې ښکاره ساتي او کله چې هغه روټر ستاسو وي، دا غوره اوږدمهاله ځواب دی۔ ډېرې سایټونه یو څه وخت دواړه چلوي، NAT د سملاسي ترمیم لپاره او لاره کله چې د فایر وال تګلاره ولیکل شي۔ که سرور د پول پرځای د سایټ-تر-سایټ ملګری وي، د سرور اړخ هم د لیرې فرعي شبکې لپاره iroute ته اړتیا لري، که نه د ملګري لاره شته خو د کلاینټ ټرافیک هېڅکله ورسره نه تړل کېږي۔
پنځم ګام: له کلاینټ څخه تایید کړئ او ولیکئ چې څه بدل شول
حلقه له سرور نه، بلکې له کلاینټ څخه بنده کړئ۔ په LAN هوسټ کې ریښتیني خدمت ته وصل شئ، بیا تایید کړئ چې د ژباړې شمېرونکي په iptables -t nat -L POSTROUTING -v -n سره ښویېدلي، ځکه صفر پاکټه قاعده هغه قاعده ده چې هېڅکله سمه نه وه۔ کله چې د ستنېدنې لوري د تعقیب ثبوت ته اړتیا ولرئ، conntrack -L -s 10.8.0.5 بهیر او د هغه حالت ښیي۔
په سرور کنفیګ کې یادښت پریږدئ: کومه فرعي شبکه، کوم انټرفیس، کومه قاعده، او ایا LAN روټر بیرته لاره لري۔ بله ځل چې د کلاینټ اپډیټ ټېل وهل شوې لاره پاکه کړي، هغه یادښت د اور مړولو ناسته یوې کرښې ترمیم ته اړوي۔