پورټ فوروېرډ په مقابل کې VPN لاسرسی: پاکټ واقعاً چېرته ځي

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

DNAT قاعده منزل بیا لیکي او هماغه ځای درېږي

په Linux جګړې کې د خدمت خپرول یعنې په nat جدول کې د PREROUTING زنځیر کې قاعده، یا په nftables کې د هغې معادل۔ قاعده د عامې پتې او پورټ سره سمون خوري، بیا منزل د اپلیکیشن خصوصي پتې ته بیا لیکي۔ سرچینه پته، سرچینه پورټ او پېلوډ نه بدلیږي، او conntrack نقشه ثبتوي ترڅو ځوابونه د وتلو پر مهال بیا ولیکل شي۔ دا چلند په RFC 3022 کې تشریح شوی د پتې ژباړې دودیز ماډل دی۔

sudo iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp --dport 443 \
  -j DNAT --to-destination 10.20.30.40:443
sudo iptables -t nat -L PREROUTING -n -v
sudo conntrack -L -p tcp --dport 443

د اپلیکیشن اورېدونکی هېڅکله نه پوهیږي چې اړیکه د ژباړې له لارې راغله۔ هغه د پیرودونکي ریښتینې سرچینه پته ویني، چې د لاسرسي لاګونو او سرعت محدودیتونو لپاره ګټوره ده، او خصوصي پتې ته ځواب وایي ځکه conntrack نقشه اړوي۔ په هغه لار کې هېڅ شی نه ډیکریپټ یا بیا انکرېپټ کیږي: TLS لا هم د پیرودونکي او د اپلیکیشن خپل سند ترمنځ روان دی۔

قاعده هغه ناکامي حالتونه هم ټاکي چې وروسته به ورسره مخ شئ۔ که جګړه تېرولی شي خو د اپلیکیشن کوربه پیرودونکي ته د بېرته تلو لار نه لري، ځوابونه په غلط سرچینه وځي او لاس ورکول درېږي۔ که بله قاعده لومړی سمون وخوري، ترتیب پایله ټاکي، او iptables -t nat -L -n -v هغه شمېرونکي ښیي چې ثابتوي کومې قاعدې پاکټ واخیست۔

تونل پاکټ دمخه پټوي، مخکې له دې چې اورېدونکی یې وویني

VPN اپلیکیشن هېڅ نه خپروي۔ پیرودونکی د جګړې عامې پتې ته اډانه شوی بهرنی پاکټ جوړوي، دننه پاکټ په هغه کې انکرېپټ کوي، او جګړه ډیکریپټ کوي او دننه پاکټ خصوصي منزل ته ځای پرځای کوي۔ په WireGuard کې بهرنی انتقال UDP دی، معمولاً په لوړ پورټ؛ OpenVPN چې TCP 443 باندې وي، بهرنی پاکټ د لارې څارونکي هر شي لپاره د TLS په څېر ښکاري۔

د تونل دننه دننه پاکټ خصوصي پتې ساتي: د پیرودونکي تونل پته، فرض کړئ 10.8.0.6، او اپلیکیشن په 10.20.30.40 کې۔ نو اورېدونکی د تونل حوض څخه سرچینه ویني، او هر پیرودونکی هغه جګړه د راتلونکي ټوپ په توګه شریکوي۔ د VPN شاته لاسرسي لاګونه ډېری د کارونکي پرځای جګړه ښیي، همدا لامل دی، که جګړه اصلي سرچینه وساتي۔

پټول د سرلیک ځای لګښت کوي، او دا یوازینی میکانېزم کچه توپیر دی چې د اندازه کېدو وړ پایله لري۔ بهرنی IP سرلیک او UDP او د WireGuard خپل سرلیک د لارې MTU څخه خوري، نو لوی پاکټونه باید ووېشل شي یا دننه TCP سټک خپل MSS محدود کړي۔ هغه لېږد چې په تېرول شوې لاره کار کوي، کېدای شي په تونل کې ودرېږي کله چې منځنی وسیله هغه ICMP وغورځوي چې کوچنی MTU به یې اعلان کړی و۔

ip route get 10.20.30.40
ping -M do -s 1400 10.20.30.40
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

افشا د ننوتلو په ځای ټاکل کیږي، نه په سایفر

دواړه ډیزاینونه په یوه TLS اورېدونکي کې پای ته رسي، نو دواړه یو سند، یو پروتوکول نسخې او یو اپلیکیشن ننوتل په میراث اخلي۔ بدلېږي دا چې څوک اجازه لري لاس ورکول پیل کړي۔ په عامه فوروېرډ کې، هر کوربه چې 203.0.113.10:443 ته رسي TCP لاس ورکول او TLS ClientHello ترلاسه کوي، مخکې له دې چې ستاسو د اپلیکیشن اجازه وکتل شي۔ یوازې د تونل له لارې لاسرسي کې، اورېدونکي ته یوازې هغو پتو څخه رسېدل کېږي چې جګړه تونل ته ځای پرځای کوي، او د اجنبي SYN د جګړې په پالیسۍ مري۔

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

اورېدونکی او پالیسي جلا جلا وګورئ، ځکه هر یو کېدای شي ستاسو له انګېرنې پراختر وي:

sudo ss -ltnp 'sport = :443'
sudo nft list ruleset
openssl s_client -connect 203.0.113.10:443 -servername files.example.com </dev/null

که ss وښیي چې اورېدونکی 0.0.0.0 ته تړل شوی، اپلیکیشن له هرې هغې ځایه رسېدونکی دی چې لارښوونه او د اور وژنې پالیسي اجازه ورکوي، او فوروېرډ یوازې د ننوتلو یوه لار ده۔ خصوصي پتې ته تړل، یا په اور وژنه کې د سرچینې حد محدودول، د VPN غوراوي څخه جلا پرېکړه ده، او هماغه پرېکړه افشا واقعاً کموي۔

لاره اندازه کړئ، نه لیبل

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

curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_total}\n' \
  https://files.example.com/report.pdf
mtr -rwc 20 203.0.113.10
mtr -rwc 20 10.20.30.40

دا شمېرې د اړیکې جوړول د لېږد وخت څخه بېلوي، دا مهم دی ځکه دوه لارې معمولاً د تللو-راتلو ځنډ او MTU کې توپیر لري، نه د سایفر لګښت کې۔ TLS کار په دواړو ډیزاینونو کې په سرونو کې کیږي، او تونل انکپسولیشن، بله لار او شاید بوخت جګړه زیاتوي۔ که د تونل لاره اوږده وي یا جګړه یې بار وي، توپیر لارې ته اړه لري، د انکرېپشن کلمې ته نه۔

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

مخکې له دې چې ډیزاین بشپړ اعلان کړئ، څلور شیان تایید کړئ: اورېدونکی کومې پتې ته تړل شوی، کومه قاعده یا لار پاکټ دننه کوي، د پیرودونکي ریښتینې پتې څخه د بېرته تلو لار کار کوي که نه، او لوی پېلوډونه MTU تېروي که نه۔ د هر یوه لپاره پورته یو کمانډ شته، او هیڅ یوه ته د «خوندي» کلمې یا د بینډویډت چارټ ځواب نه ورکول کیږي۔