proto udp یا tcp-client: سرور شما کدام را می‌شنود؟

پروفایلی که ماه گذشته کار می‌کرد اکنون به پایان مهلت می‌رسد و کسی پیشنهاد می‌کند proto udp را با proto tcp-client عوض کنید. گاهی این کار درست است و گاهی کلاینتی می‌سازد که به درگاهی وصل می‌شود که هیچ‌چیز در آن گوش نمی‌دهد، چون سرور هرگز برای نوع انتقال دیگر پیکربندی نشده است. این دستور توضیح می‌دهد طرف شما چگونه صحبت می‌کند؛ نمی‌تواند در طرف مقابل شنونده بسازد. پیش از تغییر هر کدام، پروفایل و سرور را با هم بخوانید.

نوع انتقالی را بخوانید که اتصال انتخاب‌شده به کار می‌برد

یک پروفایل می‌تواند چندین ورودی remote داشته باشد و هر کدام نوع انتقال خودش را نام ببرد. کلاینت آن‌ها را به ترتیب طی می‌کند، پس خطی که اول می‌بینید لزوماً خط اعمال‌شده نیست.

ورودی‌ای را پیدا کنید که واقعاً امتحان می‌شود، سپس نوع انتقالش را بخوانید. ترتیب مهم است، چون کلاینت بی‌صدا به بعدی نمی‌رود. برخی ساخت‌ها ورودی بعدی را فقط پس از پایان مهلت امتحان می‌کنند، پس جایگزین کارآمد پایین فایل چند ثانیه دیرتر از انتظار شما می‌رسد. در گزارش، نقطه پایانی‌ای را که امتحان می‌شود دنبال کنید، نه اینکه فرض کنید خط اول برنده شده است.

اگر فایل یک خط proto نزدیک بالا دارد و چند ورودی remote زیر آن، آن خط پیش‌فرض هر remote است که آن را نادیده نمی‌گیرد. ویرایش محلی پیش‌فرض برای ورودی remote که نوع انتقال خودش را نام می‌برد کاری نمی‌کند.

grep -nE '^(remote|proto)\b' client.ovpn

UDP و TCP تنظیم سرعت نیستند

UDP بسته‌های داده را بدون ساختن جریان مرتب می‌فرستد، پس ترافیک خود تونل درون یک انتقال مطمئن دوم پیچیده نمی‌شود. TCP راهی از میان شبکه‌هایی می‌دهد که UDP را دور می‌ریزند یا مسدود می‌کنند، به بهای بازفرست تودرتویی که می‌تواند پیوند دارای افت را بدتر حس کند.

این تبادلی بر سر دسترس‌پذیری است، نه یک رتبه‌بندی جهانی. انتخاب درست همانی است که شبکه پیش روی کلاینت اجازه می‌دهد. مسیری که UDP را روی درگاه VPN دور می‌ریزد هرگز مذاکره نمی‌کند، هرقدر هم پروفایل خوب نوشته شده باشد. مسیر را بیازمایید، سپس نوع انتقال را انتخاب کنید.

انتخاب بین آن‌ها تنها بر پایه یک سنجه اشتباه است، چون پاسخ به آنچه شبکه پیش روی شما اجازه می‌دهد بستگی دارد. یک هتل یا پروکسی شرکتی ممکن است فقط TCP خروجی روی 443 را مجاز کند و نه چیز دیگر، از این رو ارائه‌دهندگان این‌گونه را عرضه می‌کنند. این همچنان اتصال OpenVPN روی همان درگاه است، نه نشست HTTPS، حتی اگر شماره درگاه آشنا باشد.

tcp-client در واقع چه معنایی دارد

دستور سمت کلاینت طرف آغازکننده اتصال TCP را نام می‌برد. سمت سرور شکل شنیدن خودش را به کار می‌برد، و کپی کردن واژه کلاینت در پیکربندی سرور، شنونده‌ای می‌سازد که انتظار دارد به آن زنگ بزنند، نه شنونده‌ای که می‌پذیرد.

تطابق یعنی دو طرف بر نوع انتقال توافق دارند، نه اینکه رشته یکسانی را شریک باشند.

grep -nE '^proto\b' /etc/openvpn/server/server.conf
ss -lntp | grep openvpn

پیش از آنکه پروفایل را اشتباه بدانید از سرور بپرسید به چه چیزی گوش می‌دهد. شنونده UDP در فهرست سوکت‌های TCP دیده نمی‌شود و برعکس هم درست است، پس نمای مخصوص پروتکل را ببینید نه نمای عمومی.

وقتی پروفایل وارد می‌شود اما هرگز وصل نمی‌شود

پروفایل واردشده‌ای که فوراً به پایان مهلت می‌رسد معمولاً پیش از هر احراز هویتی شکست می‌خورد. بسته به درگاهی بدون شنونده می‌رود، یا شبکه آن را بی‌صدا دور می‌ریزد.

مسیر را به ساده‌ترین شکل بیازمایید: با همان نوع انتقالی که پروفایل ادعا می‌کند، از همان شبکه‌ای که کلاینت ناکام در آن است، به همان میزبان و درگاه وصل شوید.

اگر آزمون UDP چیزی نگیرد و آزمون TCP وصل شود، سرور نوع انتقال دیگر را عرضه می‌کند و پروفایل به‌سادگی کهنه است. اگر هیچ‌کدام پاسخ ندهد، مشکل بالاتر از انتخاب نوع انتقال است و هیچ ویرایشی در پروفایل آن را درست نمی‌کند. تشخیص این دو حالت یک دقیقه می‌برد و یک ساعت اشکال‌زدایی گواهی را که هرگز مربوط نبود ذخیره می‌کند.

نوع انتقال کارآمد را ثبت کنید

وقتی ترکیبی کار کرد، آن را همراه سرور، درگاه و پروتکل بنویسید و یادداشت کنید از کدام شبکه آزموده شده است.

وگرنه نفر بعدی که به پایان مهلت برمی‌خورد همان آزمایش را در جهت دیگر تکرار می‌کند و شاید سروری را که سالم بود تغییر دهد.

اگر ارائه‌دهنده هر دو گونه را منتشر می‌کند، هر دو فایل را نگه دارید و آن‌ها را بر اساس شبکه‌ای که برایش مناسب‌اند برچسب بزنید. دو پروفایل با نام روشن از آمیختن تصادفی انتقال کلاینت با شنونده سروری که هرگز برایش پیکربندی نشده بود جلوگیری می‌کند.