NFS روی TCP درون تونل UDP با OpenVPN: دو حامل

حمل یک گفت‌وگوی NFS که از TCP استفاده می‌کند درون تونلی که UDP را حمل می‌کند کاملاً سازگار است و مردم را گیج می‌کند، چون هم‌زمان نام دو حامل را می‌برد. TCP گفت‌وگوی سرویس فایل میان کلاینت و سرور NFS است. UDP حامل رمزگذاری‌شده میان دو سر تونل VPN است. هیچ‌کدام درباره دیگری چیزی نمی‌گوید.

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

دو لایه، دو تنظیم

گزینه نصب proto=tcp توضیح می‌دهد که کلاینت NFS چگونه با سرور NFS گفت‌وگو می‌کند. تنظیم proto udp در پروفایل VPN توضیح می‌دهد که دو سر تونل چگونه بسته‌های کپسوله‌شده را مبادله می‌کنند. تغییر یک گزینه نصب تونل را تغییر نمی‌دهد، و تغییر حامل تونل آنچه را کلاینت NFS مذاکره کرده تغییر نمی‌دهد. گزینه‌های مؤثر نصب را با nfsstat -m بررسی کنید نه با خط fstab، و حامل VPN را از پروفایلی که واقعاً استفاده می‌شود تأیید کنید.

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

مرور کردن به معنای خواندن انبوه نیست

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

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

MTU یک فرضیه است، نه تشخیص

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

یک پایان زمان به‌تنهایی هیچ چیزی درباره اینکه UDP باید عوض شود نمی‌گوید. این نشانه‌ای است با چند صاحب ممکن.

هر بار یک متغیر را تغییر دهید

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

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

لایه‌ای را بخوانید که شکست خورده است

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

نتیجه را در دو جمله بنویسید، یکی برای هر لایه. این برای نفر بعدی کافی است تا آزمون را بدون دوباره استنتاج کردن اینکه کدام حامل کدام است بازتولید کند.