آیا TCP 443 واقعاً کمک می‌کند؟ فقط اگر سرور همان‌جا گوش بدهد
پروفایل TCP یک جایگزین است، نه یک استتار. بررسی کنید که سرور روی آن پورت گوش می‌دهد، سپس هزینه TCP دوبل را در برابر دسترس‌ناپذیری بسنجید.
TCP 443 جایگزینی با یک پیش‌شرط است، نه استتاری که تونل را از هر فیلتری رد کند. وقتی کمک می‌کند که ارائه‌دهنده از قبل یک شنونده TCP روی آن پورت منتشر کرده باشد و مسیر اتصالی را تحمل کند که ساعت‌ها باز می‌ماند. وقتی یکی از این دو نباشد، معمولاً به شکل پایان مهلت شکست میخورد، و پایان مهلت به‌ندرت می‌گوید کدام‌یک. تصمیم برای تغییر سه پرسش می‌خواهد و فقط یکی از آن‌ها درباره شماره پورت است.
شماره پورت یک وعده انتقال نیست
پورت یک نقطه پایانی را نام می‌برد؛ TCP آن را به جریانی مرتب از بایت تبدیل می‌کند؛ OpenVPN تصمیم می‌گیرد چه چیزی درون آن جریان سفر کند. یک وب‌سرور روی همان شماره از چیدمان برنامه‌ای کاملاً دیگری استفاده می‌کند، پس شریک بودن پورت 443 آن دو را برای یک فیلتر شبیه هم می‌کند و نه بیشتر. شماره یک نشانه است که فیلتر می‌خواند، نه ویژگی‌ای که محتوای بسته‌ها را تغییر دهد. یکی دانستن آن دو چون یک پورت را شریک‌اند اشتباهی است که پشت بیشتر این سردرگمی است.
جعبه‌های میانی به‌ندرت تصمیم ساده اجازه یا منع درباره یک پورت می‌گیرند. بسیاری بایت‌های اول را بررسی می‌کنند، بعضی مقصدی را سنجاق می‌کنند و بعضی اتصالاتی را که خیلی طولانی باز می‌مانند بازنشانی می‌کنند. به همین دلیل یک پروفایل می‌تواند از یک شبکه کار کند و از شبکه‌ای دیگر پایان مهلت بدهد، و به همین دلیل جایگزین را باید به‌عنوان گزینه‌ای پشتیبانی‌شده آزمود نه اینکه به آن به‌عنوان وعده اعتماد کرد. وقتی فیلتر ترافیک را بررسی می‌کند، شماره پورت تنها اولین چیزی است که به آن نگاه می‌کند.
پیش از دست زدن به پروفایل، شنونده را تأیید کنید
سرور باید روی پورت برای TCP پیکربندی شده باشد و پروفایل کارخواه باید همان انتقال را بخواهد. بازنویسی یک پروفایل UDP برای درخواست TCP شنونده را نمی‌سازد و پایان مهلت حاصل از آن با دیوار آتشی که پورت را می‌اندازد قابل تمایز نیست. پروفایل TCP خود ارائه‌دهنده را وقتی وجود دارد بارگیری کنید، چون برخی سرویس‌ها برای هر انتقال نقطه پایانی جداگانه و تنظیمات هویتی جداگانه منتشر می‌کنند. ویرایش دستی برای آزمون کنترل‌شده خوب است و راه بدی برای حدس زدن پیکربندی موردنظر یک فراهم‌کننده.
دو طرف این تطابق در پیکربندی دیده می‌شود و گزینه‌های پیوند پروژه OpenVPN هر دو شکل را مستند می‌کند. جفت کمینه چنین است:
# server: accept TCP on this port
proto tcp-server
port 443
# client: request the same transport
proto tcp
remote vpn.example.com 443سه شرط تعیین می‌کند که جایگزین ارزش هزینه‌اش را دارد
شرط اول این است که ارائه‌دهنده اصلاً این انتقال را عرضه کند؛ بدون آن هیچ چیز دیگری مهم نیست. دوم این است که مسیر یک نشست بلندمدت را زنده نگه دارد، زیرا برخی شبکه‌ها اتصالاتی را که باز می‌مانند بازنشانی می‌کنند به‌جای آنکه پورت را یکسره مسدود کنند. سوم این است که جایگزین یک استثنای آگاهانه باشد یا راه‌حلی موقت که نقصی را پنهان می‌کند که آن را برطرف نکرده‌اید.
هر شرط یک بررسی ارزان دارد. شکست در هر یک از آن‌ها از سمت کارخواه یکسان به نظر می‌رسد:
| Condition | How to check it | What a failure decides |
|---|---|---|
| The server offers TCP | The operator's profile list, or a listening-socket check on the server | No client-side edit can help |
| The path keeps long sessions | A test connection left open for an hour | Reconnects will look like server faults |
| The fallback is deliberate | A change record naming the UDP fault | The underlying fault stays invisible |
پیش از مقایسه انتقال‌ها، هر ورود به یک دروازه اسیر را کامل کنید. شبکه‌ای که دستگاه شما را نپذیرفته هر دو انتقال را مسدود می‌کند و آنگاه مقایسه دروازه را می‌سنجد نه تونل را. وارد شوید، تأیید کنید که مرور معمولی کار می‌کند و تنها پس از آن آزمون را آغاز کنید.
هزینه‌ای که می‌پذیرید: TCP درون TCP
TCP قطعه‌های ازدست‌رفته را دوباره می‌فرستد و ترتیب آن‌ها را حفظ می‌کند. وقتی برنامه‌ای که خودش هم از TCP استفاده می‌کند درون تونل TCP اجرا می‌شود، دو لایه بازیابی به یک از دست رفتن واکنش می‌دهند و همین تعامل است که تونل را روی مسیری با افت کند حس می‌کند. نشانه، تأخیر و لرزش است نه شکست تمیز، و همین مقصر دانستن طرف دور را آسان می‌کند. پیش از نتیجه‌گیری، از سمت کارخواه در هر دو انتقال اندازه بگیرید.
UDP از این تودرتویی پرهیز می‌کند و همین دلیل اصلی است که ارائه‌دهندگان آن را ترجیح می‌دهند و TCP را فقط به‌عنوان جایگزین عرضه می‌کنند. یک اتصال پایدار TCP هنوز سودمندتر از یک اتصال UDP دسترس‌ناپذیر است، پس مقایسه میان دو هزینه واقعی است نه میان یک گزینه خوب و یک گزینه بد. هنگام مقایسه، دستگاه و شبکه دسترسی را ثابت نگه دارید، وگرنه نتیجه متغیر اشتباه را توصیف می‌کند.
برخی ویژگی‌های کارخواه فقط برای یک انتقال مستند شده‌اند، پس یک پروفایل جایگزین می‌تواند بی‌صدا رفتاری را که به آن وابسته بودید کنار بگذارد. پیش از آنکه پروفایل TCP را یک تعویض ساده بدانید، نیاز انتقالی آن گزینه را بخوانید.
نقص‌هایی که انتقال دیگر به آن‌ها دست نمی‌زند
یک گواهی منقضی هنوز به بررسی ساعت یا تمدید نیاز دارد و یک حساب ردشده هنوز به اعتبارنامه درست نیاز دارد. بررسی‌های هویت سرور را که ارائه‌دهنده داده نگه دارید، چون شماره پورت آشنا هیچ‌کس را احراز هویت نمی‌کند. پورتی که پاسخ می‌دهد تنها می‌گوید چیزی گوش می‌دهد.
اگر تونل بالا بیاید و مقصدها هنوز شکست بخورند، مشکل باقی‌مانده مسیریابی یا حل نام پس از اتصال است، نه انتقال. همان مسیر را دنبال کنید به‌جای چرخیدن میان پورت‌ها، چون یک بعدازظهر این‌طور ناپدید می‌شود. پروفایل می‌گوید کدام انتقال را بیازمایید؛ هرگز نمی‌گوید چرا مسیر UDP شکست خورد.