نیازهای پورت VPN: سه خط که پیش از مقایسه نوشته می‌شود
مشخص کنید واقعاً کدام پرسش پورت را دارید: مقصد خروجی، انتشار ورودی، یا انتقال خود تونل. سپس فقط همان را از ارائه‌دهنده بپرسید.
فهرست‌های پورت برای سرویس‌های VPN بین صفحه‌های مقایسه کپی می‌شوند بدون جزئیاتی که تعیین می‌کند آیا مهم‌اند یا نه: چه کسی اتصال را آغاز می‌کند. قاعده‌ای که TCP 443 خروجی را مجاز می‌کند هیچ نمی‌گوید که آیا میزبان دیگری می‌تواند به شنونده‌ای روی دستگاه شما برسد. پیش از مقایسهٔ حتی یک طرح، سه نیاز جداگانه بنویسید و مشخص کنید وظیفهٔ شما واقعاً به کدام‌ها نیاز دارد. بیشتر مقایسه‌ها وقتی آن برگه وجود داشته باشد به یک پرسش کوتاه فرو می‌کاهند.
نیاز را پیش از خواندن هر فهرست پورت جدا کنید
سه خط تقریباً همهٔ موارد را پوشش می‌دهد: رسیدن به مقصدی بیرون از تونل، منتشر کردن چیزی تا دیگران بتوانند به درون متصل شوند، و حمل خود تونل. هر خط به دلیلی متفاوت شکست می‌خورد، و سیاست ارائه‌دهنده‌ای که یکی را برآورده می‌کند می‌تواند دو خط دیگر را دست‌نخورده بگذارد. دسته‌بندی وظیفهٔ شما در خط درست پنج دقیقه وقت می‌گیرد و بعداً از یک بحث جلوگیری می‌کند.
| Line | Who starts it | What can block it | Question for the provider |
|---|---|---|---|
| Outbound destination | Your application | Egress filter on the exit node | Is this protocol and port allowed to that destination? |
| Inbound publishing | A remote peer | No mapping, no public address, short lifetime | Which protocol, which external port, and how long does the mapping last? |
| Tunnel transport | Your client to the gateway | The access network drops that protocol | Does the client offer a fallback the local network permits? |
ادعاهای بازاریابی سه خط را عمداً مبهم می‌کنند. اجازهٔ P2P یک سیاست مقصد را توصیف می‌کند، نشانی اختصاصی یک نشانی را توصیف می‌کند، و ادعای نبود محدودیت پورت معمولاً یعنی طرح آن‌ها را فهرست نمی‌کند. هیچ‌یک از این عبارت‌ها به بقیه پاسخ نمی‌دهد.
یک جریان مشخص انتخاب کنید و آن را به شکل جمله بنویسید: آغازگر، انتقال، پورت، خانوادهٔ نشانی، جهت. یک کلاینت پشتیبان‌گیری شبانه که به میزبانی دوردست بارگذاری می‌کند فقط خروجی است. یک سرور بازی روی میز شما که دوستان به آن می‌پیوندند ورودی است. اجرای هر دو از یک تونل یعنی برگه به هر دو خط نیاز دارد، نه سازشی میان آن‌ها.
دسترسی خروجی در سیاست مقصد شکست می‌خورد، نه در تونل
ترافیک خروجی از دروازه‌ای که ترجمه می‌کند وضعیت می‌سازد. نخستین بسته از یک نشانی و پورت داخلی یک ورودی ترجمه می‌سازد و پاسخ‌ها با آن تطبیق می‌یابند، که همان رفتار نگاشت توصیف‌شده در RFC 3022 است. همین سازوکار دلیل آن است که یک زبانهٔ مرورگر معمولاً بدون هیچ درخواست پورتی کار می‌کند.
دو چیز هنوز آن را می‌شکند. گرهٔ خروجی ممکن است مقصدها یا شماره‌های پورتی را که سوءاستفاده‌پذیر می‌داند پالایش کند، و برنامه ممکن است روی پورتی گوش دهد که سیاست خروج هرگز انتظارش را نداشت. دربارهٔ جفت مقصد بپرسید نه قواعد ورودی، و برای TCP و UDP پاسخ‌های متفاوت انتظار داشته باشید.
پیش از بحث اندازه بگیرید. این‌ها را روی دستگاهی اجرا کنید که پشت تونل خواهد بود، یک بار با تونل خاموش و یک بار با آن روشن:
ss -lntup | sort
nc -vz -w 3 203.0.113.10 443
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://example.com
همان فرمان‌ها، همان مقصد، دو وضعیت تونل، به گرداننده مقایسهٔ پیش و پس از آن را می‌دهد که بتواند بر اساسش اقدام کند. نشانی مستندات را با میزبانی که واقعاً لازم دارید جایگزین کنید؛ مهم تکرار مقایسه است، نه این‌که عددی چشمگیر به نظر برسد.
انتشار ورودی به نگاشت، نشانی و طول عمر نیاز دارد
چیزی از بیرون نمی‌تواند اتصالی به شنوندهٔ شما آغاز کند مگر آن‌که چیزی در سمت عمومی بداند آن را کجا تحویل دهد. یک رزرو پورت ایستا که گرداننده نگه می‌دارد، نگاشتی که کلاینت از طریق UPnP، NAT-PMP یا PCP درخواست می‌کند، و یک نشانی عمومی مسیریابی‌شده سه محصول متفاوت با سه محدودیت متفاوت‌اند.
پنج پرسش از هر یک از آن‌ها بپرسید: چه پروتکلی، چه پورت خارجی‌ای، آیا پورت خارجی می‌تواند با پورت محلی متفاوت باشد، کدام خانوادهٔ نشانی را پوشش می‌دهد، و نگاشت پس از اتصال دوباره چقدر دوام می‌آورد. رزروی که به یک نشست فعال گره خورده باشد با پایان آن نشست ناپدید می‌شود، هر چه صفحهٔ طرح بگوید.
نخست نیمهٔ محلی را تأیید کنید، چون شنوندهٔ مرده و مسیر ورودی مسدود از بیرون یکسان به نظر می‌رسند:
ss -lntup | grep -E ':(8080|51820)\b'
python3 -m http.server 8080 --bind 0.0.0.0
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080
وقتی درخواست محلی 200 برمی‌گرداند و درخواست از شبکه‌ای که کنترلش نمی‌کنید هنوز به پایان مهلت می‌رسد، شکاف در سمت عمومی است. آن لحظه، زمان گفتن پروتکل و پورت خارجی به گرداننده است، نه توصیف برنامه با نامش.
انتقال خود تونل پرسشی جداست
پورت‌های حامل کوچک‌ترین بخش مسئله و آسان‌ترین برای جست‌وجو هستند. پیش‌فرض‌ها بر اساس پروتکل تفاوت می‌کنند، و آنچه کلاینت می‌تواند مذاکره کند بیش از هر توصیف طرحی اهمیت دارد.
| Client | Outer transport | Default port | When it helps |
|---|---|---|---|
| OpenVPN | UDP | 1194 | Default mode; needs outbound UDP to pass |
| OpenVPN | TCP | 443 | UDP is dropped and TCP 443 is not |
| WireGuard | UDP | 51820 | Short handshake; there is no TCP mode |
| IKEv2/IPsec | UDP | 500 and 4500 | Mobile clients; 4500 carries NAT traversal |
شبکه‌ای که UDP خروجی را دور می‌ریزد تونل TCP 443 را می‌پذیرد و UDP را رد می‌کند، پس یک حالت جایگزین به برگهٔ نیازها تعلق دارد. تغییر حامل پورت برنامه را درون تونل جابه‌جا نمی‌کند و سیاست مقصد را گسترده نمی‌سازد؛ آن‌ها در خطوط خودشان می‌مانند.
تکه‌تکه‌سازی یک آزمون می‌ارزد وقتی آنجا هستید، چون تونلی که وصل می‌شود و سپس در انتقال‌های بزرگ متوقف می‌شود معمولاً MTU نادرست دارد نه پورت بسته:
ping -M do -s 1400 203.0.113.10 ping -M do -s 1372 203.0.113.10
در ویندوز همان آزمون ping -f -l 1400 203.0.113.10 است. MTU تونل را زیر بزرگ‌ترین اندازه‌ای که عبور می‌کند تنظیم کنید، سپس انتقالی را که شکست خورد دوباره بیازمایید.
سه خط را پیش از پرداخت برای یک طرح بررسی کنید
سه خط را روی یک صفحه بگذارید و هر خانه را به جای وعده با نتیجهٔ اندازه‌گیری‌شده پر کنید. این فرمان‌ها نیمهٔ محلی آن صفحه را در حدود یک دقیقه تولید می‌کنند:
ss -lntup | sort
nc -vz -w 3 203.0.113.10 443
python3 -m http.server 8080 --bind 0.0.0.0
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080
ping -M do -s 1400 203.0.113.10
خروجی را مانند یک سیاههٔ بررسی بخوانید. خروجی وقتی کار می‌کند که مقصد با تونل روشن پاسخ دهد. ورودی فقط وقتی کار می‌کند که میزبانی بیرون از شبکهٔ شما به شنونده روی پورت خارجی برسد. حامل وقتی کار می‌کند که دست‌دادن روی پروتکلی که شبکهٔ دسترسی شما اجازه می‌دهد کامل شود.
دو عادت برگه را صادق نگه می‌دارد. تاریخ و نسخهٔ کلاینت را کنار هر نتیجه ثبت کنید، چون هم سیاست‌های ارائه‌دهنده و هم پیش‌فرض‌های کلاینت جابه‌جا می‌شوند. سپس تنگ‌ترین نگاشتی را بخواهید که به جریان خدمت می‌کند، چون درخواست باز کردن همه‌چیز معمولاً به جای پاسخ فنی یک رد یا پیشنهاد ارتقا به دست می‌آورد.