ولې ستاسو LAN د VPN کلاینټ په یوه خدمت نه رسېږي

د VPN کلاینټ کولای شي داسې خدمت کوربه کړي چې LAN یې نه شي خلاصولای. معمولاً هغه څه چې نیمګړي دي د بیرته راستنېدو لار ده: یوه لاره، یوه DNAT جوړه، یا هغه SNAT کرښه چې هیچوک یې نه زیاتوي.

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

مات شوی تونل نه دی

دواړه سرونه په شخصي حدونو کې ناست دي، دا نورمال حالت دی نه غلط ترتیبات۔ د 10.8.0.6 په څېر پته د تونل په دننه کې ریښتینې ده او بل چېرې نشته، نو LAN هیڅ دلیل نه لري چې هلته څه واستوي۔ د لارښوونې له لمس کولو مخکې تصدیق کړئ چې خدمت په تونل کې دننه لاسرسي وړ دی که نه: په کلاینټ کې ss -ltn ښيي چې اورېدونکی 127.0.0.1، د LAN انټرفېس یا د تونل پتې سره تړل شوی دی۔ یوازې loopback سره تړلی ډیمون له خپل ځان پرته هیچا ته ځواب نه وایي، او هېڅ لاره، DNAT یا د پورټ لېږد دا نه بدلوي۔

د 80 یا 443 پورټ پروکسي بېله بله لیدلوري لرونکی بل اوزار دی۔ دا غوښتنې خوځوي، نه پاکټونه، نو د خام ډېټابیس نښلونې لپاره غلط پوړ دی، او همدا لوري ته لاس اوږدول هغه لاره ده چې دا ستونزه د چا له اندازه کولو مخکې درې اوزارونه ژوره کېږي۔

د لارې بڼه: LAN ته ووایاست چې حوض چېرې دی

د LAN په ګېټوې کې ثابته لاره تر ټولو پاک ځواب دی کله چې LAN او د تونل حوض یو پر بل نه راځي۔ حوض هغه ماشین ته وګرځوئ چې تونل پای ته رسوي:

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

دا یوازې یوه خوا سمه کوي، ځکه د دې بدلون نیمګړي نسخې لکه پرمختګ ښکاري۔ د تونل خوا ته هم سمونکی نیمګړی برخه پکار ده، که نه ځواب کلاینټ پرېږدي او د خپلې ډیفالټ لارې په اوږدو کې مري:

push "route 192.168.1.0 255.255.255.0"

د هغه فرعي شبکې لپاره چې د سرور نه بلکه د یو کلاینټ شاته ده، سرور ته د سیسټم لاره او د هغه کلاینټ په فایل کې iroute ننوتنه دواړه پکار دي، چې client-config-dir لاندې ده۔ د iroute پرته، OpenVPN پوهېږي چې پریفکس شته او نه پوهېږي چې کوم کلاینټ یې مالک دی: پاکټونه رارسي او ډیمون هېڅ نه لري چې هغوی ورسره سم کړي۔

دلته هغه افسانه ده چې نوم ورکول یې ارزښت لري۔ لاره پته لاسرسي وړ کوي؛ خو د مقابل لوري د ځواب ورکولو لپاره چمتو نه کوي۔ د سایټ-تر-سایټ ملګري پر سر یو بل پوړ زیاتوي، ځکه لېرې ګېټوې یوازې هغه سرچینې مني چې د هغې په تګلاره کې د لیست شوو پریفکسونو دننه وي، او د کور حوض نه راغلی لپ‌ټاپ په هغوی کې نه دی۔

د NAT بڼه: دننه DNAT، او هغه SNAT کرښه چې هرڅوک یې پرېږدي

کله چې د LAN ګېټوې لمس نه شئ کولای، یا غواړئ یوازې یو پورټ خپور کړئ، د VPN هوسټ باندې ژباړه پر LAN باندې هېڅ لارې پرته کار کوي۔ پورټ خپور کړئ، مخته یې ولېږئ، او سرچینه د تونل پر لار ژباړئ:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

درېیمه کرښه هغه ده چې ورکېږي۔ پرېږدې یې او کلاینټ اصلي LAN پته لکه سرچینه ویني، د خپلې ډیفالټ لارې له مخې ځواب وایي، او هغه ځواب د LAN خوا ته د بیرته تلو پرځای تونل ته ځي۔ چې نښلون ژوندی پاتې کېږي یا نه بیا پر هغه لارښوونې ولاړ دی چې تاسو هېڅکله پلان نه کړې وه۔ د SNAT سره کلاینټ د سرور د تونل پته ویني، نو ځواب د تونل له مخې بیرته هغه یوازیني هوسټ ته ځي چې ژباړه بېرته اړولای شي۔

د کاروونکو فرم‌ویر خپل د زنځیر نومونه کاروي او هغه ژباړه ستاسو لپاره نه جوړوي۔ په Tomato کې، دننه راتلونکی قاعده WANPREROUTING ته ورځي او بیا د wanin په څېر د فلټر زنځیر ته، او بشپړ ښکارېدونکی قواعدو ټولګه بیا هم لاسي POSTROUTING کرښې ته اړتیا لري۔ دا د فرم‌ویر خرابي نه ده؛ دا یوازې د راتلونکي ترافیک لپاره لیکل شوې قواعدو ټولګه ده۔

ولې سم ښکارېدونکی قاعده بیا هم پاکټ غورځوي

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

  • د زنځیرونو ترتیب۔ iptables -I پورته ورننباسي او -A پای ته زیاتوي، نو پخوانۍ اجازه ورکوونکې یا بندېدونکې قاعده لومړی فیصله کوي۔
  • غلط زنځیر۔ هغه ترافیک چې روټر ته پخپله نښه شوی دی INPUT تېرېږي، او مخته لېږل شوی ترافیک هېڅکله نه لمس کوي۔ یو خدمت خپرول کېدای شي په دواړو کې قواعدو ته اړتیا ولري۔
  • د لوري بیرغونه۔ -i tun0 له کلاینټونو راتلونکي ترافیک سره سمون خوري او -o tun0 هغه ترافیک سره چې دوی ته ځي۔ په غلط بیرغ REJECT هغه څه بندوي چې تاسو یې نه غوښتل۔
  • د سرچینې محدودیت۔ هغه لېږد چې د یو کلاینټ پته مني له هغه کلاینټ نه کار کوي او هرې بلې سرچینې ته پرته له یوې کلمې پرېږدي۔

هغه قاعده چې د پاکټونو شمېر یې صفر وي په لار کې نه ده، او شمېرونکي لوستل تر ټولو ګړندې لار ده چې د غلط-زنځیر ستونزه له غلط-قاعده ستونزې وبلل شي۔

سیمه‌ای لېږد، کله چې پر LAN هېڅ نه شي بدلېدلای

SSH سیمه‌ای لېږد ټول پوښتنه پرېږدي۔ دا پر LAN لار، د کلاینټ د اور دېوال همکاري، او چېرې خپور شوی پورټ ته اړتیا نه لري:

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

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

له بلې قاعدې مخکې دواړه لوري وګورئ

ژباړه نښې پرېږدي، او هغوی لوستل له اټکل نه غوره دي۔ پر VPN هوسټ، conntrack -L ښيي چې ژباړه پېښه شوه که نه، iptables -t nat -L -n -v ښيي چې شمېرونکي وخوځېدل که نه، او tcpdump -ni any port 3000 ښيي کومه سرچینه پته ریښتیا راغله۔ پر کلاینټ، ss -ltn تصدیقوي چې اورېدونکی هغې پتې باندې دی چې تونل ورته رسېدلای شي۔

بیا هغه بڼه غوره کړئ چې ساتئ یې۔ یو خپور پورټ، د ټول حوض لپاره لاره، او د یو اډمین لپاره لېږد درې بېلې ژمنې دي، او د هغوی ګډول همدا هغه لار ده چې یو کارېدونکی ترتیب داسې ته اوړي چې شپږ میاشتې وروسته یې هیڅوک تشریح نه شي کولای۔ ولیکئ چې کومه پته له کومه لاسرسي وړ ده، او بل څوک چې دا ډیبګ کوي له ځوابه پیل کوي نه له تونله۔

اړوندې مقالې