NAT ټاکي چې ستاسو VPN سرور په رښتیا کوم د سرچینې پته ویني
ستاسو د لپټاپ پته هیڅکله VPN سرور ته نه رسیږي. NAT هغه په وروستي ټوپ کې بیا لیکي، او د تونل IP وروسته ټاکل کیږي. څنګه دواړه پایونه پرتله کړئ.
تاسو فکر کوئ چې VPN سرور ستاسو د لپټاپ پته له پیکټ څخه لولي او په لاګ کې یې لیکي۔ هغه څه چې لولي هغه دي چې وروستي NAT ټوپ په بهرني سرلیک کې اچولي، او په هغه تلیفون کې چې د هټسپاټ په توګه کارول کیږي دا ډیری وخت هغه پته وي چې له سلګونو نورو ګډونوالو سره شریکه وي۔ ستاسو د ماشین خپله 192.168.x.x په هغه سرلیک کې هیڅکله انټرنیټ نه تیریږي، او د تونل پته سرور هغه وخت ورکوي چې اړیکه لا دمخه جوړه شوې وي۔ نو کله چې د سرور لاګ او په لپټاپ ip addr سره سمون نه خوري، هیواد یې هم غلط نه دی؛ دوی د یوې ناستې مختلفې طبقې بیانوي۔
درې پتې، او په لاګ کې یوازې یوه
ګډوډي له دې څخه راځي چې درې پتې په یوه کې یوځای کیږي۔ هر یو خپل مالک لري، په بل سرلیک کې ژوند کوي او په بله لار سرور ته رسیږي۔
| Address | Who assigns it | Where it sits | Visible to the VPN server |
|---|---|---|---|
Device address, e.g. 192.168.1.24 | Your router via DHCP | Outer header, before translation | No, rewritten in place |
| Translated address and port | Router, ISP CGNAT, or both | Outer header, after translation | Yes, this is the tuple it logs |
Tunnel address, e.g. 10.8.0.6 | The VPN server itself | Inner header, after decapsulation | Yes, but it chose it |
یوازې منځنۍ کرښه د نښلولو په وخت کې نامعلومه ده۔ سرور هغه د ډیمون له مخې په خپل همکارانو جدول، حالت فایل یا جریان لاګ کې لیکي: WireGuard هغه پای ټکی بولي، د OpenVPN حالت فایل هغه Real Address په توګه نښه کوي، او strongSwan هغه د IKE_SA لرې کوربه په توګه راپور کوي۔ هغه ارزښت هرکله تازه کیږي چې له بلې سرچینې پیکټ راشي، نو پرته له دې چې څوک څه بیا پیل کړي بدلیږي۔
تر ټولو لاندې کرښه هغه ده چې خلک په غلطه توګه د هویت ادعا لولي۔ دا په سرور کنفیګریشن کې یوه ځای نښه کوي، نه یو کس، ځکه سرور هغه له خپلې زېرمې څخه غوره کړی۔ دوه کاروونکي کولای شي په مختلفو ورځو کې یوه تونل پته واخلي، او یو کس کولای شي دوه له دوو وسیلو څخه ولري۔
ولې ثبت شوې ټوپل بدلیږي پداسې حال کې چې تونل پورته وي
د پتو ژباړه د ټایمر سره جدول دی، نه دایمي تړاو۔ کورنی روټر د وروستي پیکټ وروسته یو څه وخت خپل UDP نقشه ساتي، د چلونکي دروازه پورټونه د خپل مهال ویش له مخې بیا کاروي، او له Wi-Fi څخه LTE ته تلونکی تلیفون په بشپړ ډول بل سرچینه سره راګرځي۔ دلته د Linux conntrack ډیفالټ ارزښتونه ګټور معیار دي: nf_conntrack_udp_timeout 30 ثانیې دی او د جریان بڼه 120، نو یو ارام تونل کولای شي خپله نقشه د کاروونکي له پام وړ ډیر مخکې له لاسه ورکړي۔
تونل ژوندی پاتې کیږي ځکه چې پروتوکول پته نه، بلکې همکار تصدیقوي۔ WireGuard د لاس ورکولو وروسته بې حالته دی، نو هر تصدیق شوی پیکټ خوندي شوی پای ټکی تازه کوي او بیا تړل د بل پیکټ په سر سم کیږي؛ له همدې امله persistent-keepalive = 25 شته، ترڅو نقشه د بې کارۍ په وخت کې ګرمه وساتي۔ د OpenVPN --float همدا کار کوي او تصدیق شوي کلاینټ ته اجازه ورکوي چې له نوې پتې او پورټ څخه دوام وکړي۔ په 2.4 او 2.5 جوړښتونو کې چې float په ډیفالټ ډول بند دی، بیا تړل ناسته بیا تنظیموي او کلاینټ بیا نښلیږي۔
IPsec هلته په ډیرو خوځنده برخو رسیږي۔ IKEv2 ژباړه د NAT کشف پیلوډونو کې د سرچینې او منزل هشونو په پرتله کولو پیژني، UDP 4500 انکپسولیشن ته ځي، او keepalive د نوي ټوپل تر څنګ تعقیبوي۔ کله چې keepalive بند شي، SA په کاغذ پورته پاتې کیږي او په یوه لوري ترافیک په خاموشۍ ودریږي۔
سرور څه منسوبولای شي، او څه نه شي
هغه افسانه چې د وژلو ارزښت لري دا ده چې ژباړه تاسو له چلونکي پټوي۔ دا لیبل بدلوي، نه مشاهده۔ د چلونکي NAT شاته دروازه 100.64.0.0/10 ځای یا یوه عامه پته ویني چې ډیر ګډونوال یې شریکوي، او بیا هم کولای شي جریان د سند موضوع، WireGuard عامه کیلي، ټاکل شوې تونل پتې، بایټ شمیرونکو او وخت کړکۍ سره وتړي۔ له دې هیڅ یو هم ستاسو LAN پتې ته اړتیا نلري۔
حدونه بل لوري ته هم ځي۔ په لاګ کې شریکه پته دروازې ته اشاره کوي، نه کور ته؛ د یوې ژباړل شوې پتې څخه په مختلفو پورټونو دوه ناستې مختلف وسیلې دي؛ یوه پته په دوو مختلفو ورځو کې کولای شي دوه بې اړیکې ګډونوال وي که پورټ بیا کارول شوی وي۔ هغه سرور چې یوازې د همکارانو کیلي ثبتوي پرته له حساب ډیټابیس څخه نشي کولای یو له پیرودونکي سره وتړي، او هغه سرور چې یوازې پتې ثبتوي نشي کولای د یوه روټر شاته لپټاپ له تلیفون څخه توپیر کړي۔
پر ځای د اټکل کولو دواړه پایونه پرتله کړئ
د دې لپاره چې څه پیښ شوي روښانه کړئ، هماغه اړیکه په دواړو پایونو کې په یوه لحظه کې ونیسئ او پته نه، ټوپل پرتله کړئ۔ په کلاینټ کې، له هرې ژباړې مخکې:
ss -uapn 'dport = :51820'
ip -4 route get 203.0.113.10
wg show wg0 endpointsبیا په روټر یا CGNAT دروازه کې ژباړې ننوتنه او هغه څه ولولئ چې بالاخره سرور ته رسیږي:
conntrack -L -p udp --dport 51820
tcpdump -ni eth0 udp port 51820درې نمونې ډیری ناسمونې تشریح کوي۔ په سرور کې سرچینه پورټ له محلي پورټ څخه توپیر لري پداسې حال کې چې منزل سره سمون خوري: عادي پورټ ژباړه۔ په سرور کې سرچینه پته د ISP بلاک ده چې ستاسو نه ده: لږ تر لږه یوه اضافي NAT طبقه۔ پیکټونه د بې کارۍ وروسته دريږي او په نوي پورټ سره دوام کوي: نقشه پای ته رسیدلې، د روټینګ تېروتنه نه ده۔ که وخت نښې له یوې یا دوو ثانیو څخه ډیرې لرې وي، تاسو دوه مختلف هڅې پرتله کوئ۔
چیرې چې توپیر شیان ماتوي
هغه خنډونه چې د سرور خرابیو په څیر ښکاري معمولا له دې ځایه پیل کیږي۔ ستاسو د کور پتې سره تړل شوی د لاسرسي قاعده د ISP اجارې له بدلون وروسته ناکامه کیږي۔ د ژباړل شوې پتې سره سمون خوړونکی fail2ban قاعده په یو وخت کې د هغې دروازې شاته ټول ګډونوال بندوي۔ د ثابتې لرې پتې سره سایت-تر-سایټ همکار د موبایل لینک له بدلون وروسته کیلي نوي کول بندوي۔ د تونل پروتوکول سم و؛ د بهرني ټوپل په اړه انګیرنه نه وه۔
همدا ګډوډي د سرور په اړخ کې هم ښکاري۔ که VPN بکس پخپله د NAT شاته وي تاسو ته د پورټ فارورډنګ او کار کوونکې فارورډنګ لارې ته اړتیا ده؛ د strongSwan فارورډنګ لارښود د IPsec لپاره هغه قضیه پوښي۔ یوازې په خصوصي پته رسیدونکی سرور هیڅکله هغه ژباړل شوې ټوپل نه ویني چې کلاینټان یې وړاندې کوي، او دا له کلاینټانو د ژباړې څخه بېله ستونزه ده۔
دا څلور څیړنې په ترتیب سره وکړئ او په لومړي ناکام کې ودریږئ:
- په دواړو پایونو کې په یو وخت کې ونیسئ؛ تایید کړئ چې سرچینه پورټ، منزل پورټ او وخت نښې سره سمون خوري۔
- د سرور د همکارانو په لیست کې هغه پته ولولئ چې اوس یې لري، نه هغه چې تاسو تمه درلوده۔
- ننوتنه او د هغې پاتې عمر په conntrack یا NAT جدول کې وګورئ۔
- تایید کړئ چې په کلاینټ کې د تونل انټرفیس پته د LAN پتې سره نه، بلکې د سرور ورکړې پتې سره سمون خوري۔
که دواړه نیول په ټوپل باندې سره موافق وي او تونل بیا هم ناکام شي، ژباړه ستاسو ستونزه نه ده؛ لاس ورکولو او د تونل دننه د روټینګ جدول ته لاړ شئ۔