کله چې CGNAT پورټونه بندوي، د VPS له لارې کورني سرور خپرول

ما له بهر څخه پیل وکړ، لکه څنګه چې یو کارن به وکړي: نوم مې په موبایل ډیټا کې د تلیفون په براوزر کې ولیکه او ولیدل چې اړیکه تر وخته پورې ځړېده. نوم حلېده، نو DNS سم و. د کور روټر د پورټ فارورډنګ پاڼه هم بنده لاره وه، ځکه چې د هغې WAN پته 100.64.31.42 ښوده، او دا هغه پته نه ده چې یو چمتو کوونکی مې له انټرنیټ څخه هغې ته وګرځوي. دا شمېره ټوله خرابي تشریح کوي: لینه د carrier-grade NAT شاته ده، نو د تونل زما په خوا کې عامه پته د چمتو کوونکي ده. لاندې هغه لاره ده چې ما له هغې ځړېدلې ټب څخه تر ځواب ورکوونکي خدمت پورې ووهله.

له کارن سره پیل وکړه او دننه لاړ شه

له دې مخکې چې کوم قاعده بدله کړې، ثابته کړه چې زنځیر چېرته درېږي. په لپ ټاپ کې مې dig +short files.example.net وچلاوه او د VPS پته مې بېرته ترلاسه کړه، چې زما په ماشین کې زوړ DNS رد کړ. بیا curl -v --connect-timeout 5 files.example.net:5022 د ردېدو پر ځای وخت ته ورسېد. دا توپیر مهم دی: وخت ته رسېدل معمولاً یعنی پاکټونه په لاره کې غورځول کېږي، خو ردېدل یعنی یو څه ځواب ورکړ او نه یې وویل.

دننه بل ګام پخپله VPS و. ss -ltnp هغه څه ونه ښودل چې په 5022 واوري، چې د DNAT قاعدې له رامنځته کېدو مخکې تمه کېده. په همدې ماشین wg show (یا د OpenVPN لپاره ip -br a show tun0) تایید کړه چې کورنی peer فعال دی او نوی handshake لري. که peer کار ونکړي، هېڅ NAT قاعده به مرسته ونه کړي، او د کور روټر د VPN پاڼې شنه رڼا هېڅ معنا نه لري.

تایید کړه چې کورنۍ لینه واقعاً د CGNAT شاته ده

هغه پته چې روټر یې په خپل WAN انټرفیس کې راپور کوي له هغې سره پرتله کړه چې یو بهرنی خدمت یې ویني. هر څه چې په 100.64.0.0/10 کې دي، یعنې له 100.64.x.x څخه تر 100.127.x.x پورې، د RFC 6598 شریکه پته رینج دی او له انټرنیټ څخه نه شي رسېدلی. همدې پایلې ته رسېږې کله چې روټر د عادي شخصي پتې ادعا وکړي او عامه پلټنه بې اړیکې څه بېرته راوګرځوي. د CGNAT لینه کېدای شي عامه پته هم ولري چې یوازې تر بل lease پورې دوام کوي، نو پورټ فارورډنګ یوه ساعت کار کوي ښکاري او بیا په خاموشۍ مري.

ځینې چمتو کوونکي رښتیا هم ریښتینې عامه پته ورکوي خو په استوګنځي حسابونو کې د 80 او 443 راتلونکي پورټونه بندوي. که ستاسو خدمت یوازې وېب دی او WAN پته رښتیا عامه ده، له relay جوړولو مخکې له ملاتړ څخه وپوښتئ. که نه، لاندې ډیزاین په هر پورټ یو شان تطبیقېږي، او ښه ده چې تجربه د روټر په خوا کې ودروئ: د چمتو کوونکي په شبکه کې ژباړونکی اړیکه پای ته رسوي مخکې له دې چې هغه ستاسو WAN انټرفیس ته ورسېږي.

نوم د VPS پتې ته وګرځوه

DNS ټرافیک نه لېږدوي، نو د خدمت A ریکارډ باید د VPS عامه پته ولري. 192.168.1.20 ته A ریکارډ یوازې د هغو کارنانو لپاره ګټور حل کېږي چې دمخه په VPN کې دي؛ له انټرنیټ څخه هغه پتې ته حل کېږي چې هېڅوک نه شي ګرځولی. د VPS خپل اداري لاسرسي لپاره جلا نوم ساتم، تر څو هېڅکله ګډوډ نه شم چې ریکارډ کوم کوربه ته اشاره کوي.

که هم VPS او هم کورنۍ ماشین HTTP وړاندې کوي، هر یو ته خپل نوم ورکړه او پرېږده VPS فیصله وکړي چې څوک ځواب ورکوي. دواړه په یو نوم کې یوځای کول او دا هیله چې پراکسي سم backend غوره کړي، هماغه لاره ده چې ټوله ماسپښین په غلط کوربه کې د تېروتنې پلټنه کوې.

یو پورټ DNAT، SSH په 22 پاتې شي

مستقیم انتخاب په VPS د منزل NAT دی. د روان کرنل لپاره forwarding فعال کړه او په قاعده کې د کورني سرور د تونل پته وساته، نه د هغې LAN پته:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -p tcp -d 198.51.100.10 --dport 5022 -j DNAT --to-destination 10.8.0.2

SSH خود VPS ته په 22 پرېږده او بل پورټ، لکه 5022، کورنۍ ماشین ته ولېږه. که 22 یوې بندې ماشین ته ولېږې، هغه یوازینۍ لاره له لاسه ورکوئ چې کېدای یې شوای سمه کړي. همدې منطق پراکسي ته هم تطبیقېږي: د VPS اداري پورټ له relay قاعدو بهر وساته.

قاعدې یې ژر چې کار وکړ، تلپاتې کړه. په Debian یا Ubuntu کې apt install iptables-persistent او بیا netfilter-persistent save هغوی /etc/iptables/rules.v4 ته لیکي. په firewalld لرونکي کوربه کې معادل یې په زون کې تلپاتې پورټ فارورډنګ دی، چې له تطبیق مخکې firewall-cmd --reload ته اړتیا لري. هغه قاعدې چې یوازې په حافظه کې ژوند کوي، د چمتو کوونکي په لومړني ساتنې بیاځلي پیل کې ورکېږي، معمولاً په بد وخت کې.

د بېرته راتلو لاره سمه کړه یا له اړتیا یې ځان وساته

DNAT یوازې منزل بیا لیکي. کورنی سرور اړیکه د اصلي کارن پتې څخه ویني، او که د هغې ډیفالټ لاره کور روټر ته اشاره وکړي، ځواب د کور WAN څخه وځي چې هلته د چمتو کوونکي ژباړونکی یې غورځوي. دا ناسم توازن دوهمه خرابي وه چې ما ورسره مخامخ شو، وروسته له دې چې DNAT قاعده بشپړه سمه ښکارېده.

دوه سمونې کار کوي. کورنۍ ماشین ته د پالیسۍ لاره ورکړه تر څو له تونل څخه راغلی ټرافیک د تونل له لارې بېرته لاړ شي:

ip rule add from 10.8.0.2 table 100
ip route add default dev wg0 table 100

یا پرېږده VPS سرچینه بیا ولیکي تر څو ځواب داسې پته ولري چې هغه ته رسېدلی شي، او conntrack یې په وتلو کې واړوي:

iptables -t nat -A POSTROUTING -d 10.8.0.2 -p tcp --dport 5022 -j SNAT --to-source 10.8.0.1

د SNAT نسخه ریښتینې کارن پته له کورني سرور څخه پټوي، نو د اپلیکیشن لاګونه peer په توګه 10.8.0.1 ښیي. اصلي پته د اپلیکیشن په پرت کې ولېږه، یا د هر کارن لاګ له لاسه وتل ومنه، خو دا پریکړه په پام سره وکړه نه دا چې د یوې پېښې په جریان کې یې ومومه.

ټوله لاره له بهر څخه وګوره

له هغې شبکې څخه تایید کړه چې نه VPS ده او نه کور: تلیفون په موبایل ډیټا، یا بل چېرې ارزانه shell. nc -vz files.example.net 5022 باید د بریالۍ اړیکې راپور ورکړي، او openssl s_client -connect files.example.net:443 -servername files.example.net باید د عامه نوم سند وښیي. بیا د چمتو کوونکي امنیتي ګروپ یا کلاډ فایر وال وګوره. هغه DNAT قاعده چې هېڅکله پاکټ نه ویني معمولاً له کوربه یوه پرت پورته بندېږي.

په پای کې فیصله وکړه چې کله تونل ولویږي څه پېږي. DNAT قاعده اړیکې منلو ته دوام ورکوي او هغوی په خاموشۍ مړه تونل ته لېږي، چې بالکل د خراب خدمت په څېر ښکاري. په VPS د روغتیا کتنه چې پورټ رد کړي تر څو چې peer کار نه کوي، څو کرښې لګښت لري او یوه ساعت اټکل خوندي کوي. له دې وروسته قاعدو ته سمون ورکول پرېږده او یوه ورځ یې وګوره مخکې له دې چې باور پرې وکړې.