پورت مبدأ کلاینت در برابر شنوندهٔ سرور در یک جریان VPN
دو شمارهٔ پورت را در یک تونل مقایسه کنید: شنوندهٔ ثابت سرور و مبدأ زودگذر کلاینت، و اینکه ترجمهٔ روتر چگونه میان آن‌ها قرار می‌گیرد.
در یک گفت‌وگو دو شماره ظاهر می‌شود و هیچ‌کدام اشتباه نیست. گزارش سرور شنونده‌ای را نشان می‌دهد که سرویس را ارائه می‌کند، لپ‌تاپ سوکتی را نشان می‌دهد که داده‌نگار را فرستاده، و روتری در میانه ممکن است دومی را هنگام خروج بازنویسی کند. مقایسهٔ دو سر گفت‌وگو سودمندتر از مقایسهٔ خود رقم‌هاست. مقایسهٔ زیر شنونده، سوکت کلاینت و مبدأ ترجمه‌شده را جدا نگه می‌دارد، زیرا به پرسش‌های متفاوتی پاسخ می‌دهند.
دو شماره که دو سر مقابل را توصیف می‌کنند
پورت پیکربندی‌شدهٔ سرور همان مقصدی است که کلاینت به آن زنگ می‌زند. سیاست آن را ثابت می‌کند، در پروفایل دیده می‌شود و باید در سمت سرور باز باشد. پورت مبدأ کلاینت به‌صورت محلی و معمولاً از بازهٔ زودگذر انتخاب می‌شود و وجود دارد تا پاسخ جایی برای فرود داشته باشد. ممکن است در هر اتصال دوباره تغییر کند و هیچ چیز در طراحی به پایدار ماندنش وابسته نیست.
روتری در میانه ممکن است آن مبدأ را در نگاشت 'NAT' خودش بازنویسی کند. به همین دلیل شماره‌ای که در سرور دیده می‌شود غالباً هیچ نسبتی با شماره‌ای که لپ‌تاپ انتخاب کرده ندارد.
کجا شمارهٔ مبدأ در مسیر خروج تغییر می‌کند
مثالی ساختگی با IPv4 بزنید: کلاینتی پشت روتری که ترجمه می‌کند، سروری با یک شنوندهٔ 'UDP' و یک داده‌نگار که از هر دو می‌گذرد. جدول هر سر را و آنچه بر آن می‌رود نام می‌برد، به‌جای بازپخش بسته در سه نقطهٔ مشاهده.
| Endpoint | What stays fixed | What changes on reconnect | Who owns it |
|---|---|---|---|
| Server listener | The service port and the address the profile names | Nothing; the listener does not follow the client | The server operator |
| Client socket | The destination it dials | The local source port, chosen per socket | The client, or its operating system |
| Translated source | Usually the public address of the router | The port, and sometimes the address after a network switch | The NAT device or the upstream carrier |
مقصد در هر ردیف ثابت است و تنها هویت مبدأ تغییر می‌کند. الزامات UDP NAT نشانی و پورت داخلی را از نگاشت بیرونی جدا می‌کنند و این دقیقاً تفاوت ردیف دوم و سوم است. روتر می‌تواند پورت مبدأ کلاینت را حفظ کند یا پورت دیگری برگزیند؛ حفظ آن چیزی نیست که برنامه باید فرض کند.
سه سر را از خود میزبان‌ها بخوانید
فهرست‌های زیر از سه ماشین متفاوت می‌آیند و با هم تمام گفت‌وگو را نشان می‌دهند. اولی را روی سرور، دومی را روی کلاینت و سومی را هرجا نگاشت وجود دارد اجرا کنید. یک خط گزارش هرگز هر سه را نشان نمی‌دهد.
ss -lunp 'sport = :1194'
ss -unp | grep 1194
conntrack -L -p udp | grep 1194فهرست نخست ثابت می‌کند که سرور به پورت سرویس بسته شده است و نشان می‌دهد کدام فرایند آن را در اختیار دارد. دومی سوکت محلی کلاینت و مقصدی را که به آن زنگ زده نشان می‌دهد. سومی نگاشتی را نشان می‌دهد که روتر ساخته است و تنها جایی است که مبدأ ترجمه‌شده پدیدار می‌شود. به همین ترتیب بخوانیدشان تا دو شماره دیگر متناقض به نظر نرسند.
اتصال دوباره چه چیزی را تغییر می‌دهد و چه چیزی را نه
برخی روترها پورت مبدأ کلاینت را وقتی آزاد است نگه می‌دارند و برخی هر بار پورت دیگری تخصیص می‌دهند. هر دو رفتار طبیعی است و برنامه‌ای که اولی را الزام کند روی دومی می‌شکند. تغییر نگاشت پس از اتصال دوباره یا تغییر شبکه عیب سرور نیست: کلاینت سوکت تازه‌ای باز می‌کند، روتر آنچه دارد می‌دهد و سرور مبدأ تازه‌ای روی همان شنونده می‌بیند. عیب آن است که انتظار داشته باشیم سرور ترافیک نشانی‌شده به یک پورت دلخواه کلاینت را بپذیرد.
کلاینت‌های OpenVPN جامعه این رفتار را از طریق nobind می‌گیرند که به سیستم‌عامل اجازه می‌دهد پورت محلی را برگزیند؛ پورت راه دور هنوز از پروفایل می‌آید. بستن صریح یک انتخاب آگاهانه است، نه الزام پروتکل. سرور همچنان یک سر ارائه می‌دهد در حالی که کلاینت‌ها هویت‌های محلی خودشان را برمی‌گزینند.
لایه‌ها را در گزارش جدا برچسب بزنید
درون تونل گفت‌وگوی دومی با پورت‌های خودش هست. درخواست HTTPS که تونل حمل می‌کند مقصد TCP 443 دارد، در حالی که اتصال رمزگذاری‌شدهٔ بیرونی از UDP 1194 استفاده می‌کند، پس تغییر پورت مبدأ بیرونی هیچ چیز را در سرویس درونی تغییر نمی‌دهد.
حتی در لایهٔ بیرونی، پروتکل مهم است. UDP 1194 و TCP 1194 دو سر متفاوت‌اند و شنوندهٔ 'TCP' هرگز داده‌نگار UDP دریافت نمی‌کند فقط به این دلیل که شماره یکی است. هنگام مستندسازی یک استقرار، شنوندهٔ سرور، سوکت کلاینت و مبدأ ترجمه‌شده را سه چیز متمایز برچسب بزنید و به هر کدام پروتکل انتقال را بیفزایید.
سپس بگذارید سیاست از نقش‌ها پیروی کند. سرور پروتکل انتقال موردنظر را روی شنوندهٔ خود باز می‌کند و همچنان همتا را احراز هویت می‌کند؛ دیوار آتش کلاینت پاسخ‌های تبادل خروجی خودش را می‌پذیرد بدون آنکه سرویس ورودی منتشر کند. فیلتر بی‌حالت به جهت بازگشت صریح نیاز دارد و همین دلیل عملی اهمیت این تمایز فراتر از نمودارهای مرتب است.