SSH روی OpenVPN گیر می‌کند؟ اول MTU مسیر را اندازه بگیرید

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

پیش از دست زدن به نمایه، شکل خرابی را بخوانید

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

سازوکار این است: کشف MTU مسیر، که به بازخورد وابسته است. TCP اندازه قطعه را انتخاب می‌کند و وقتی مسیریابی در راه نمی‌تواند بسته حاصل را بفرستد، باید آن را با پیام ICMP اعلام کند. بستن‌بندی بسته بیرونی را بزرگ‌تر از درونی می‌کند، پس اندازه قابل استفاده درون تونل همیشه زیر پیوند فیزیکی است. اگر آن پیام‌های ICMP را هر جایی پالایش کنید، فرستنده هرگز تصحیح را نمی‌گیرد، قطعه‌های پر می‌فرستد و بسته بیرونی بی‌اطلاع دور ریخته می‌شود.

سقف را از هر دو سو اندازه بگیرید

پیش از تغییر هر یک، MTU تونل را با پیوند فیزیکی بسنجید. تونلی که مقدار فیزیکی را کپی کرده، پیشاپیش گفته است ناهمخوانی کجاست.

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

ip link show tun0
ping -M do -s 1380 10.9.0.1

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

mssfix و fragment کارهای متفاوتی می‌کنند

mssfix اندازه قطعه‌ای را محدود می‌کند که اتصال‌های TCP درون تونل هنگام دست‌دادن اعلام می‌کنند. این اهرم درست برای SSH، HTTPS و کپی پرونده است، و از همین رو توقف غالباً با تنظیم آن از میان می‌رود. به بارهای مفید UDP اصلاً دست نمی‌زند.

تونلی که سرویس UDP هم حمل می‌کند ممکن است پس از اصلاح SSH همچنان شکست بخورد، و این نتیجه هر کسی را که گمان می‌کند یک گزینه همه چیز را می‌پوشاند سردرگم می‌کند.

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

پایین آوردن MTU واسط گزینه‌ی خشن است

کاهش MTU واسط در هر دو سر ابزار خشن است. به هر فرستنده درونی عدد کوچک‌تری می‌گوید که کار می‌کند، و این هزینه را بر همه ترافیک می‌گذارد نه بر جریان‌های TCP که به آن نیاز دارند.

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

با همان انتقالی که متوقف شد دوباره بیازمایید

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

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