د VPN رټ شوی کلینټ تر سرور رسیږي خو تر LAN کوربه نه رسیږي

ټونل پورته کیږي، کلینټ VPN سرور ته پنګ کوي، او یو ګام لرې ماشین کې شریکه شوې پوښۍ هیڅکله ځواب نه ورکوي۔ د کلینټ په ترتیب کې هیڅ شی دا نه تشریح کوي، ځکه غوښتنه واقعیا د کلینټ څخه ووتله او واقعیا ورسیده۔ هغه څه چې ناکام شول د بیرته راستنیدو سفر و، او ناکامه وسیله معمولا د VPN کوربه نه، بلکې LAN ګیټوې ده۔ د ځواب بنډل تعقیبول د دې ټولې نښې طبقې تشریح کوي۔

د غوښتنې نه، د ځواب تعقیب وکړئ

VPN سرور د کلینټ بنډل کوډ پرانیزي او د کلینټ پته لا هم د سرچینې په ساحه کې ساتل کیږي، هغه LAN ته لیږي۔ د منزل کوربه هغې پتې ته ځواب ورکوي، او اوس د هغه خپله رټینګ جدول هر څه فیصله کوي۔ د هغه ډیفالټ ګیټوې د ټونل حوض په اړه هیڅ نه پوهیږي، نو ځواب د انټرنېټ چمتو کوونکي په لور وځي او په هغه لار کې یو ځای غورځول کیږي۔

په کلینټ کې نښه غلی وخت تیریدل دي: نه انکار، نه بیا تنظیمول، یوازې هیڅ نه۔ د شریکې پوښۍ لټول بند پاتې کیږي، پنګ راپور ورکوي چې ځواب نشته، او د سرور ثبتونه روغ ښکاري ځکه سرور خپله دنده ترسره کړه۔

د بیرته ستنیدو لاره هغه ځای کیږدي چې کوربه ګوري

هر LAN کوربه خپل ډیفالټ ګیټوې ته مشوره اخلي، نو ګیټوې یوازینی وسیله ده چې باید پوه شي چې د ټونل حوض چیرته دی۔ هلته یو ثابت رټ اضافه کړئ او هر کوربه پرته له لاس وهنې سمه لار ترلاسه کوي۔

که ګیټوې خپله پته د DHCP انتخاب په توګه وویشي، رټ هم همداسې وویشئ تر څو نوي ماشینونه یې په اتوماتيک ډول واخلي۔ که نه، رټ په یوه ترتیبي فایل کې ژوند کوي او په راتلونکي بیا رغونه کې ورک شیږي۔

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

ولې د سرچینې NAT داسې ښکاري چې دا سمونې

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

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

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

د ورېځې لار درې تنظیماتو ته اړتیا لري

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

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

کتنې په دې ترتیب ترسره کړئ

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

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

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

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