هدایت پورت در برابر دسترسی VPN: بسته واقعاً کجا می‌رود

هدایت پورت مقصد را بازنویسی می‌کند و همان‌جا می‌ایستد؛ VPN ابتدا بسته را بسته‌بندی می‌کند. ببینید هر کدام کدام لایه را تغییر می‌دهد و این برای HTTPS چه معنایی دارد.

دو طراحی، یک برنامه HTTPS، و بسته در هر کدام مسیر متفاوتی می‌پیماید. هدایت پورت تغییر می‌دهد که بسته کجا تحویل داده شود و بقیه را دست‌نخورده می‌گذارد. VPN ابتدا آن بسته را درون بسته دیگری حمل می‌کند، پس شنونده برنامه منبع متفاوتی و بار مفید حداکثری کوچک‌تری می‌بیند. رمزنگاری‌ای که مردم درباره‌اش بحث می‌کنند در هر دو حالت وجود دارد، چون برنامه هنوز HTTPS است؛ آنچه فرق می‌کند این است که چه کسی می‌تواند اتصال باز کند و شبکه میانی چه چیزی را می‌تواند مشاهده کند. همین تمایز بیشتر پرسش‌های عملی را حل می‌کند.

قاعده DNAT مقصد را بازنویسی می‌کند و همان‌جا می‌ایستد

روی یک دروازه Linux، انتشار یک سرویس یعنی قاعده‌ای در زنجیره PREROUTING جدول nat یا معادل آن در 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 نیاز به احراز هویت برنامه را برنمی‌دارد: پذیرش در تونل پاسخ می‌دهد که آیا دستگاهی می‌تواند بسته به این شبکه بفرستد، در حالی که برنامه فایل پاسخ می‌دهد که آیا کاربری می‌تواند سندی بخواند. اشتباه گرفتن این دو همان راهی است که تیم‌ها به VPN‌ای می‌رسند که تمام LAN را می‌دهد و برنامه‌ای با یک گذرواژه مشترک.

شنونده و سیاست را جداگانه بررسی کنید، چون هر یک می‌تواند گسترده‌تر از آن باشد که فرض می‌کنید:

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 جان سالم به در می‌برند. برای هر یک از این‌ها فرمانی در بالا هست و هیچ‌کدام با واژه امن یا نمودار پهنای باند پاسخ داده نمی‌شود.

مقالات مرتبط