NAS از طریق VPN در دسترس نیست: نشانی، مسیر بازگشت یا سرویس؟
یک تونل خصوصی به مسیری به سمت NAS، مسیر پاسخ و سرویس مجاز نیاز دارد. پیش از تغییر اطلاعات ورود، مشخص کنید کدام یک از این سه مورد شکست خورده است.
تونل‌ها بالا می‌آیند، کلاینت‌ها نشانی می‌گیرند و NAS هیچ پاسخی نمی‌دهد. همین یک نشانه سه خرابی بی‌ارتباط را پوشش می‌دهد و ترتیبی که آن‌ها را آزمایش می‌کنید تعیین می‌کند تعمیر چقدر طول بکشد. نشانی‌دهی اول می‌آید، چون یک زیرشبکه هم‌پوشان می‌تواند درخواست شما را به دستگاهی ناشناس بفرستد. مسیر بازگشت دوم می‌آید، چون درخواستی که بدون پاسخ می‌رسد دقیقاً مانند یک سرویس بسته به نظر می‌رسد. سرویس و مجوز آخر می‌آیند و تنها پس از اثبات دو مورد اول.
سه خرابی که همه به شکل در دسترس نبودن خوانده می‌شوند
انتخاب نشانی، مسیریابی بازگشت و مجوزدهی سرویس همان پیام قابل مشاهده را تولید می‌کنند: هیچ اتفاقی نمی‌افتد. شواهد، مسئولان و اصلاح‌های آن‌ها متفاوت است، بنابراین جدا کردنشان کل کار است. یک پینگ ناموفق به‌تنهایی چیز کمی را اثبات می‌کند و یک رد TCP موفق در واقع خبر خوبی است.
| Observation | Most likely conclusion |
|---|---|
| Route to the NAS address leaves the wrong interface | Overlapping or missing private route |
| Request visible on the server, no reply seen | Return path, gateway forwarding or translation |
| TCP connection refused rather than dropped | Reachable host, service not listening or filtered |
| TCP works, login or file access fails | Share permission, account or protocol version |
جدول را به‌عنوان ترتیب آزمون‌ها بخوانید، نه فهرستی از علت‌ها. هر سطر سطر بعدی را محدود می‌کند، چون رد شدن قبلاً اثبات می‌کند که نشانی‌دهی و مسیر بازگشت کار می‌کنند. گذراندن بیست دقیقه داخل قواعد دیوار آتش پیش از بررسی اینکه مسیر کدام واسط را انتخاب کرده، رایج‌ترین راه از دست دادن یک بعدازظهر است. از بالا به پایین کار کنید و در نخستین سطری که مطابقت دارد بایستید.
شرط یک: آیا آن نشانی دستگاه درست است؟
زیرشبکه NAS و محدوده‌ای که VPN به کلاینت‌ها می‌دهد را بنویسید و هر دو را با شبکه‌ای که لپ‌تاپ شما همین حالا در آن است مقایسه کنید. در این مرور NAS روی 10.40.7.25 قرار دارد و استخر VPN برابر 10.40.9.0/24 است، دو محدوده خصوصی جداگانه درون یک طرح سایت؛ خانوارهایی که از 192.168.0.0/24 یا 10.0.0.0/24 استفاده می‌کنند شانس بسیار بیشتری برای برخورد با یکی از آن‌ها دارند.
وقتی شبکه محلی و شبکه NAS هم‌پوشانی دارند، کلاینت آن ترافیک را به دروازه خودش می‌فرستد و ممکن است به دستگاهی بی‌ارتباط برسد که تصادفاً همان نشانی را دارد. پیش از نوشتن اطلاعات ورود در هر چیزی که پاسخ می‌دهد، مسیر را بررسی کنید.
ip -4 route get 10.40.7.25
traceroute -n -m 5 10.40.7.25فرمان اول واسط و دروازه‌ای را نام می‌برد که هسته استفاده می‌کرد و دومی نخستین گام‌هایی را نشان می‌دهد که واقعاً پاسخ می‌دهند. اگر این دو با هم نمی‌خوانند، به جستجو اعتماد کنید، چون مسیری است که بسته طی می‌کند. فهرست گام‌هایی که یک گام پیش از NAS متوقف می‌شود هم یک یافته است، نه شکست. جستجویی که به‌جای تونل به آداپتور فیزیکی می‌رسد، بررسی را در این نقطه پایان می‌دهد.
شرط دو: آیا پاسخ بازمی‌گردد؟
کلاینت به مسیری به سمت NAS نیاز دارد و شبکه NAS به مسیر بازگشتی به سمت استخر VPN نیاز دارد. ارسال از دروازه، قواعد دیوار آتش و ترجمه عمدی نشانی هر یک بر این جفت اثر می‌گذارند. یادداشت‌های strongSwan درباره ارسال گزینه‌های مسیر بازگشت و ترجمه را برای یک زیرشبکه خصوصی پشت دروازه توصیف می‌کنند.
وقتی درخواست می‌رسد و پاسخ از دروازه دیگری خارج می‌شود، هیچ تغییر DNS این ناترازی را درست نمی‌کند. ثبت در هر دو سمت آن را با یک تلاش روشن می‌کند و همچنین نشان می‌دهد آیا ترجمه مبدأیی را که NAS به آن پاسخ داد بازنویسی کرده است یا نه. مدیر مسئول این مرز است: فقط سرویس‌های لازم و محدوده کلاینت‌های VPN را مجاز کنید و بنویسید که مسیریابی انتخاب شده یا ترجمه.
شرط سه: آیا سرویس آنجاست و مجاز است؟
صفحه مدیریت و سرویس اشتراک فایل نقاط پایانی متفاوتی روی همان ماشین هستند و یکی می‌تواند اتصال بپذیرد در حالی که دیگری توسط دیوار آتش میزبان، پیکربندی سرویس یا مجوز اشتراک مسدود شده است. دستگاهی که با رد پاسخ می‌دهد، دو شرط اول را قبلاً اثبات کرده است، که شرط سوم را بسیار محدود می‌کند.
با حسابی آزمایش کنید که واقعاً به فایل‌ها نیاز دارد، نه با حساب مدیر که هنگام نصب استفاده شد، چون حقوق مدیریتی نمی‌تواند مسیر گمشده را تعمیر کند و مسیر نمی‌تواند مجوز اشتراک بدهد. نام‌ها هم اینجا جای دارند: نام NAS که در خانه کشف می‌شود اغلب به multicast محلی وابسته است که یک تونل مسیریابی‌شده آن را حمل نمی‌کند، پس نام میزبان خصوصی مستند سازنده یا خود نشانی را امتحان کنید تا نام‌گذاری را از دسترسی جدا کنید.
از بیرون شبکه NAS آزمایش کنید، سپس آهسته گسترش دهید
آزمونی که در همان LAN انجام شود هر بخش ناقص مسیر دور را پنهان می‌کند، و به همین دلیل نخستین تلاش موفق از راه دور شایسته یادداشتی در سابقه تغییرات است. بررسی‌ها را از کلاینتی اجرا کنید که فقط از طریق تونل به NAS می‌رسد و متن خطای اصلی هر تلاش را نگه دارید.
nc -vz 10.40.7.25 445
smbclient -L 10.40.7.25 -U guestپس از کارکردن مسیر، یک فایل بی‌خطر را منتقل کنید و رفتار خواندن یا نوشتنی را که واقعاً لازم دارید تأیید کنید. اگر انتقال‌های بزرگ متوقف شوند در حالی که کوچک‌ها موفق‌اند، مشکل باقی‌مانده مدیریت اندازه بسته یا پایداری اتصال است، نه نشانی‌دهی.
برای دور زدن یک خرابی توضیح‌نشدنی، درگاه‌های اشتراک فایل یا مدیریت را روی اینترنت منتشر نکنید. مسیر خصوصی را تعمیر کنید، نرم‌افزار NAS را پشتیبانی‌شده نگه دارید و بازیابی هر چیزی را که از طریق آن پشتیبان می‌گیرید، پیش از اتکا به آن پشتیبان آزمایش کنید.