د سایټ تر سایټ VPN ځواب د تونل له لارې نه ځي
هغه ځواب چې تونل پریږدي، د لرې اړخ د لارښوونې پریکړه ده. د کوربه جدول، ټاکونکي او rp_filter وګورئ، بیا لاره یا NAT وټاکئ۔
یوه سهار مې په یوه تونل تېر کړ چې پاک پورته شو او ترافیک یې په یوازې یوه لوري وړل: څانګه کولای شوه د مرکزي دفتر فایل سرور ته ورسیږي، او هر هغه اړیکه چې له مرکزي دفتر څخه څانګې ته پرانیستل کیده په لومړي SYN کې مړه کیده۔ SA ګانې فعالې وې، د تونل شمېرونکي لوړېدل، او لاس ورکول هېڅکله ستونزه نه وه۔ ځواب به هغه ځای ته لارښوونه کېده چې تونل یې نه پوښي، او دا ټاکنه د لرې اړخ ده۔ سایټ تر سایټ VPN یوازې هغه پاکټونه وړي چې کوربه یې دروازې ته سپاري، او هر کوربه دا ټاکنه جلا، په هر لوري، له خپلې لارښوونې جدول څخه کوي۔
دواړه لوري جلا جلا لارښوونه کیږي
IP د خبرې اترې د لوري هېڅ یاد نه ساتي۔ هر هغه کوربه چې پاکټ لېږي خپله تر ټولو اوږده پریفکس پلټنه کوي، یو بل ګام ټاکي او پریکړه هېروي۔ غوښتنه او ځواب دوه بې تړاوه پاکټونه دي چې ناڅاپه یوې اړیکې ته اړه لري، او تونل یو ګام دی چې هر یو یې کارولی شي یا نه۔ په IKE تبادله کې هېڅ شی لرې سرور ته نه ښیي چې ستاسو فرعي شبکه ته څنګه ورسیږي؛ خبرې اترې یوازې پر دې سره یوځای کیږي چې کوم پریفکسونه کولای شي کوډ شي۔
هغه هوکړه دوهمه دروازه ده۔ په strongSwan کې د ترافیک ټاکونکي leftsubnet او rightsubnet دي، او هغه پاکټ چې سرچینه یا منزل یې د هوکړه شوې جوړې نه بهر وي کوډ نه کیږي، هر څه چې لارښوونې جدول ووایي۔ هغه پریفکس چې تونل ته لارښوونه کیږي خو په ټاکونکو کې نیشت، یوه غلې یو اړخیزه ناکامي ده: لاره سمه ښکاري، پاکټ بیا هم خلاص وتل کیږي یا غورځول کیږي، او یوازې د charon ثبت شکایت کوي۔
لرې کوربه ستاسو د تونل په اړه هېڅ نه پوهیږي
د لرې LAN دننه ځواب یو عادي پاکټ دی چې ستاسو پیرودونکي ته استول شوی۔ منزل کوربه هېڅ IPsec سرلیک نه ویني او د VPN دروازې ته د ترجیح ورکولو هېڅ دلیل نه لري؛ ستاسو پریفکس پلټي، د خپلې اصلي لارې څخه ډېر ځانګړی هېڅ نه مومي او هماغه تعقیبوي۔ که اصلي لاره یوې مرکزي اور وژنې ته اشاره وکړي، اور وژنه یا تونل ته د بېرته تلو لاره لري یا نه۔ چې نه وي، تاسو یو غلی غورځېدل، ICMP unreachable، یا هغه ځواب ترلاسه کوئ چې د انټرنیټ خوا ته د انټرفیس له لارې وتل کیږي او مړ کیږي۔
دوهم انټرفیس بس دی چې دا مات کړي، حتی کله چې لاره موجوده وي۔ په بل VLAN کې د مدیریت تړاو لرونکی NAS، د بیک اپ uplink لرونکی سرور، یوه پالیسي قاعده چې یوه سرچینه ساحه دوهم جدول ته لېږي: له دې هر یو کولای شي ځواب ونیسي۔ په Linux کې، ip rule show او ip route show table all هغه قواعد او جدولونه ښیي چې اصلي لیست یې پټوي۔
پریکړه په هغه ماشین کې ولولئ چې ځواب لېږي
له بدلون مخکې له کرنل وپوښتئ، او سرچینه پته ورکړئ، ځکه چې د سرچینې پورې تړلي قواعد ځواب بدلوي۔
ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"وتل هغه انټرفیس او بل ګام نوموي چې وتل کیږي۔ که انټرفیس هغه نه وي چې VPN دروازې ته ګوري، تاسو نیمګړتیا موندلې ده، او پاتې کار دا دی چې وټاکئ لاره چېرته باید وي۔ له دروازې ping دلته لږ څه ثابتوي: هغه دې پتې ته ځواب وایي چې لرې کوربه یې ځای پرځای کولای شي، نه ستاسو د لپ ټاپ پتې ته۔
په Windows کې سیالان د پریکړې لپاره Find-NetRoute -RemoteIPAddress 10.10.5.10 او د جدول لپاره Get-NetRoute دي۔ هغه لاره چې د New-NetRoute په واسطه ورزیاته شي او له اصلي څخه لوړه میټریک ولري غلی بایلي، نو د میټریک ستون ولولئ، نه ننوتنه۔ بیا د پاکټونو په واسطه تایید کړئ: د لرې LAN انټرفیس کې tcpdump -ni any "host 10.10.5.10 and tcp port 445" غوښتنه ښیي، او د تونل خوا کې هماغه فلټر ښیي چې ځواب بېرته راغی که نه۔ غوښتنه ښکاري خو ځواب نشته، مانا دا چې ځواب بل ځای ته لارښوونه شوی یا غورځول شوی؛ په غلط انټرفیس ځواب تاسو ته مجرم درکوي پرته له دې چې لارې ته لاس ووهئ۔
کله چې د سرور دروازه د VPN پای ټکی نه وي
ډېر سایټونه د سرورونو او مرکزونکي تر منځ اور وژنه ږدي۔ هغه اور وژنه ځواب لیږدوي، نو د ستاسو پیرودونکي پریفکس لپاره د VPN دروازې خواته اشاره کوونکې لارې او په دواړو لورو کې د لیږد تګلارې ته اړتیا لري۔ د حالت ساتونکي وسایل یې نور خرابوي: غوښتنه د هغه LAN کوربه څخه اور وژنه تېره کړه چې هغې اجازه ورکړې وه، ځواب اوس له بل لوري راځي، او د اړیکې تعقیب ننوتنه نوره سمه نه ده، نو پاکټ د رد کېدو پرځای ناسم ګڼل کیږي او غورځول کیږي۔ د تګلارې ثبت خالي ښکاري ځکه چې ترافیک ورک کیږي۔
دروازې خپله دوهمه فلټر لري۔ په Linux کې د معکوسې لارې فلټرینګ هغه پاکټونه غورځوي چې سرچینه یې له هغه انټرفیس څخه د لاسرسي وړ نه ده چې دوی پرې راغلي، او دا په ریښتیا د یوې قانوني غیر متقابلې بېرته تلو لارې بڼه ده۔ د strongSwan د لیږد لارښود همدې دلیل لپاره net.ipv4.ip_forward او نرم net.ipv4.conf.all.rp_filter غواړي۔ په هرې دروازې باندې کلکه 1 ارزښت سمه لاره غلی ماتوي، او که پوه شئ چېرته وګورئ nstat -az غورځېدل ښیي۔
| Symptom | Where the reply is most likely lost |
|---|---|
| Gateway ping works, LAN host silent | Source address the far host cannot place in its table |
| SYN arrives, no SYN-ACK, tunnel counters flat | No route to the client prefix on the far host or its gateway |
| Reply counted on the internet-facing interface | Default route or policy rule on the far host |
| Firewall reports invalid state | Asymmetric path through a stateful device |
| Worked until a link failed over | New path is asymmetric, or rp_filter now rejects it |
لارښوونه وکړئ یا وژباړئ، بیا په دواړو لورو کې تایید کړئ
دوه سمونې سره برابرې نه دي۔ د لارې زیاتول د پیرودونکي پته نه لمس وي، نو د سرچینې پر بنسټ قواعد، پلټنې ثبتونه او هغه اپلیکیشنونه چې زنګ وهونکی ثبتوي دوام مومي؛ بیه یې دا ده چې هر هغه ګام چې پریکړه کوي لارې ته اړتیا لري، یعنې د تېروتنې ډېر ځایونه۔ په لرې دروازې ماسکریډ بېرته تلو لاره یو ګام ته راکموي، ځکه ځواب اوس دروازې ته استول کیږي، او پټوي چې کوم پیرودونکی څه وکړل۔
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADEهغه په پوهاوي سره وټاکئ: لکه څنګه چې پیرودونکي د دروازې پتې په څېر ښکاره شي، د سرچینې پر بنسټ ACL نور دوی نه توپیروي، او ترڅو ځواب تونل ته بېرته ولیکل شي conntrack باید نقشه وساتي۔ که ټاکونکي لا هم د پیرودونکي پریفکس بېخي وباسي، NAT هېڅ نه بدلوي، ځکه غوښتنه هېڅکله تونل ته نه ده ننوتلې۔
مخکې لدې چې سم شوی یې وبولئ، څلور شیان په ترتیب سره تایید کړئ: د ځواب لېږونکي کوربه لاره، هر هغه ګام لاره چې هغه لیږدوي، دواړه پریفکسونه پوښونکي ټاکونکي، او یو ثبت چې ښیي ځواب ستاسو د تمې سرچینې سره تونل ته ننوځي۔ بیا ازموینه له بل سایټ څخه تکرار کړئ۔ یو لوري تېریدل نیمګړې پرانیستې ډیزاین دی، او دوهم لوری معمولاً د هغه دلیل څخه توپیر لري چې همدا اوس مو سم کړ۔