په LAN سرور کې VPN کلاینټ: ولې ځوابونه ناسم لوري ته وځي

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

ځواب یو نوی پیکټ دی، د لارې بېرته تګ نه

دا نظر پرېښودل مرسته کوي چې ځواب د هغې لارې بېرته راځي چې غوښتنه پرې تللې وه۔ روټینګ د هر پیکټ او هر لوري لپاره په لېږونکي هوسټ کې ټاکل کېږي۔ په تونل کې دننه د 10.64.0.23 څخه راغلې غوښتنه کومه بېرته تګ لاره نه جوړوي؛ کله چې هوسټ ځواب ووايي، هغه ځواب د نوي پیکټ په توګه له جدول سره پرتله کېږي او د هغې لارې وځي چې ګټي۔

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

پاتې برخه لوستلې مهال دوه فرعي شبکې په یاد وساتئ۔ یوه د VPN پت پول دی چې لرې کلاینټونه ترې راځي، په دې بېلګه کې 10.64.0.0/24۔ بله هغه LAN ده چې باید کار ته دوام ورکړي، 172.16.24.0/24 د خپل روټر سره په 172.16.24.1۔ ستونزه دا ده چې د دوی ترمنځ ترافیک د تلوالې لارې له خوا ټاکل کېږي۔

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

له هر بدلون مخکې تایید کړئ چې ځواب به کومه وسیله وکاروي۔ پوښتنه له کیپچر څخه ګړندې ده او په هغه پوښتنه ځواب وایي چې کرنل به یې د پیکټ جوړېدو پر مهال ځواب ووايي۔

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

ځواب په دوو برخو کې ولولئ۔ که dev tun0 ونوموي، هوسټ به ځواب بسته کړي او خدمت وړونکي ته یې وسپاري، او LAN کلاینټ به یې هېڅکله ونه ویني۔ که dev eth0 ونوموي خو کلاینټ بیا هم وخت ختمېدل ومومي، لاره لا دمخه سمه ده او پیکټ وروسته غورځول کېږي، چې دا بله ستونزه او بل حل دی۔

د همدې ګام کیپچر هغه شک حل کوي چې ping یې نشي حل کولے۔ LAN کلاینټ ته رسېدونکی ایکو ځواب ثابتوي چې یوه لاره کار کوي، نه دا چې کوم انټرفیس یې وړی، نو کیپچر په خپل هوسټ کې چل کړئ او وګورئ چې فریمونه له کومه وځي۔ په همدې فرعي شبکه کې پرنټر ځواب ورکول ته دوام ورکوي، ځکه چې د هغه نېغه لاره د تونل د تلوالې لارې څخه ډېره ځانګړې ده۔ لېږدول شوی پورټ د هر بل بهیر په څېر ناکامېږي، ځکه چې انټرفیس جدول ټاکي، نه اړیکه۔

هغه تر ټولو تنګه لاره نصب کړئ چې له تونل مخکې وي

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

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

د دویم add پر ځای replace وکاروئ، ځکه چې بیا نښلېدونکی کلاینټ خپله ننوتنه نصب کړې وي او دویم add د موجودې لارې په تېروتنه ناکامېږي چې د اجازې ستونزې په څېر لوستل کېږي۔ په Windows هوسټ کې معادل route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p دی، چېرې چې -p ننوتنه د بیا پیلېدو په اوږدو کې ساتي، ځکه چې تونل بیا پورته کېدو پر مهال کلاینټ جدول بیا جوړولای شي۔ په عصري Windows هوسټ کې ملاتړ شوی معادل New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore دی، او زوړ route امر د پخوانۍ بڼې په توګه ساتل کېږي۔

یوه جزئیات ټاکي چې دا سمه ده که یوازې باوري: راتلونکی ټوپ باید هغه روټر وي چې په رښتیا د کلاینټونو ته د بېرته تګ لارې مالک دی۔ لاره هغه پت ته اړول چې خپله د تونل له لارې ورته رسېږو، یوه کړۍ جوړوي چې د پاکې ناکامۍ پر ځای د پرله پسې زیان په توګه ښکاري۔ له کرښې مخکې تایید کړئ چې راتلونکی ټوپ په LAN فرعي شبکه کې دی۔

له بیا نښلولو وروسته ځواب وساتئ

په لاس اضافه شوې لاره په غوره حالت کې تر راتلونکې بیا نښلونې پورې پاتې کېږي۔ که کلاینټ پول متحرک وي، په سرور کنفیګورېشن کې یې ټینګ کړئ تر څو هغه مخکښه چې تاسو روټ کړې، هغه مخکښه پاتې شي چې کلاینټونه یې ترلاسه کوي؛ که نه، ننوتنه خالي حد ته اشاره کوي او نښه څو اونۍ وروسته پرته له ښکاره لامل بېرته راځي۔ لاره د کلاینټ په خپل up-سکریپټ کې لیکل بله باوري ګڼه ده، ځکه چې دا د کلاینټ له خوا د جدول له بیا لیکلو وروسته چلېږي۔

د حالت والا فایر وال کولای شي سمه لاره هم مات کړي۔ که کیپچر اوس ښیي چې ځواب د eth0 له لارې وځي او کلاینټ بیا هم وخت ختمېدل ومومي، وګورئ چې هوسټ پیکټ له لېږلو مخکې غورځوي۔ سخت د بېرته لار فلټر او net.ipv4.conf.all.rp_filter چې 1 ته ټاکل شوی، هغه پیکټونه غورځوي چې سرچینه یې هغه انټرفیس ته بېرته نه روټ کېږي چې له هغه راغلې، او دا هماغه نابرابره پېښه ده چې تاسو همدا اوس جوړه کړه او بیا سمه کړه، او conntrack حالت د لېږدول شوو پورټونو لپاره هماغه کیسه کوي۔

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