VPN متصل است اما یک سرویس کار نمیکند: مرحله را جدا کنید
یک دستدادن کامل هیچ چیزی درباره نام، مسیر، اندازه بسته یا شنونده نمیگوید. چهار مرحله را طی کنید و بگذارید نخستین شکست نام عیب را بگوید.
«متصل» کماطلاعترین واقعیت در یک تیکت VPN است. فقط ثبت میکند که دو طرف دستدادن را تمام کردهاند و هیچ چیزی درباره نامی که پرسیده شد، رابطی که بسته از آن خارج شد، اندازهاش، یا اینکه طرف دور آن را پذیرفت یا نه نمیگوید. به همین دلیل یک سرویس میتواند شکست بخورد در حالی که هر برنامه دیگر روی همان لپتاپ کار میکند. مراحل را به ترتیب طی کنید و نخستین مرحلهای که شکست بخورد نام عیب را میگوید.
با نام شروع کنید، نه با تونل
پیش از مسیریابی، نام را حل کنید، چون پاسخ بد هر آزمون بعدی را بیمعنا میکند. نام را با حلکننده سیستم بپرسید و آن پاسخ را با آدرسی که برنامه واقعاً استفاده کرده مقایسه کنید. نام خصوصیای که بهصورت آدرس عمومی برمیگردد یعنی پرسش به حلکنندهای رفته که کاری با پاسخ دادن به آن ندارد. نامی که حل نمیشود همان دسته است، فقط بلندتر.
resolvectl query host.internal
getent hosts host.internal
مرورگرهایی که تنظیم DNS امن خودشان را دارند اینجا شکست میخورند در حالی که بقیه سیستم کار میکند. به همین دلیل شکایتی که فقط به مرورگر مربوط است اول به این مرحله تعلق دارد، پیش از آنکه کسی به مسیری دست بزند. هر دو فرمان را مقایسه کنید نه یکی را، چون getent مسیر NSS را دنبال میکند و پرسش حلکننده نه.
از هسته بپرسید کدام مسیر را انتخاب کرد
جدول مسیریابی یک ترتیب ترجیح است و مسیری که هسته انتخاب میکند همیشه آن چیزی نیست که نمودار نشان میدهد. مستقیماً از آن درباره مقصد مورد نظر بپرسید. پاسخ رابط، گام بعدی و آدرس مبدأیی را که استفاده خواهد شد نام میبرد. بسته میتواند از تونل با آدرس مبدأیی خارج شود که طرف دور آن را رد میکند، و یک ورودی دقیقتر در جدول فیزیکی میتواند آن را بهجای آن از رابط Wi-Fi بیرون بفرستد.
ip route get 10.20.30.40
ip -brief address show
فیلدهای dev، via و src را به همین ترتیب بخوانید، چون هر یک سوءظن متفاوتی را حذف میکند. این مرحله همچنین مالک وضعیتی است که کلاینت نصب کرده، چون قواعد فایروال و مسیرها میتوانند پس از خروج غیرعادی باقی بمانند. به همین دلیل «اینترنت بدون تونل نیست» و «اینترنت نیست مگر کلاینت اجرا شود» یک خانواده عیب هستند، نه دو تا.
اندازه بسته را بیازمایید
پاسخ کوچکی که برمیگردد در حالی که یک انتقال بزرگ گیر میکند نخست به MTU مسیر اشاره میکند. یک کاوش با بیت do-not-fragment تنظیمشده، که از داخل تونل فرستاده شود، این مرحله را از بقیه جدا میکند. بار مفید را بالا ببرید تا کاوش شکست بخورد و آنگاه عددی را دارید که اهمیت دارد.
ping -M do -s 1400 10.20.30.40
موفقیت کاوشهای کوچک در حالی که فهرست یک پوشه یا یک بارگذاری معلق میماند امضای این مرحله است. شکایت شبیه اعتبارنامه یا قاعده فایروال به نظر میرسد و هیچکدام نیست.
این عدد ویژگی مسیر است نه کلاینت، پس مقداری که روی اتصال اداری کار میکند میتواند روی پیوند همراه شکست بخورد. فرمان کاوش را همراه تیکت نگه دارید، چون نفر بعدی به همان اندازهگیری نیاز دارد. اگر بار کوچکتری عبور کند، راهحل یک clamp یا MTU پایینتر تونل است، نه رمزنگار تازه.
طرف دور را بیازمایید
مقصد را با آدرسش بیازمایید، سپس ببینید چه چیزی آنجا گوش میدهد. اتصال ردشده و اتصالی که هرگز پاسخ نمیدهد یافتههای متفاوتی هستند. اولی میگوید چیزی بالاست و آن پورت را سرویس نمیدهد، و دومی میگوید هیچ چیزی برنگشت. هیچکدام بهطور پیشفرض مشکل کلاینت نیست.
curl -sv http://10.20.30.41:8080/health
nc -vz -w 3 10.20.30.41 3389
ss -lnt 'sport = :8080'
هیچ چیزِ قابل دسترسی از طریق تونل نمیتواند سرویسی باشد که فقط روی 127.0.0.1 گوش میدهد، چون شنونده هرگز بسته را نمیبیند. وقتی فایروال میزبان دور زیرشبکه اداری را مجاز میداند و استخر تونل را رد میکند، نتیجه شبیه عیب کلاینت به نظر میرسد و نیست. Remote Desktop یا اشتراک فایل که خراب میشود در حالی که ترافیک وب زنده میماند معمولاً همینجا میافتد، هر طور که کاربر بیانش کند.
شکایت را به یک مرحله نگاشت کنید
بیشتر گزارشها به یکی از پنج شکل فرو میریزند و هر شکل یک مرحله را نام میبرد. سایتی که فقط از طریق تونل کار میکند یک پاسخ نام است یا سیاستی وابسته به آدرس مبدأ. شکست بهروزرسانیها بدون تونل در حالی که مرور کار میکند مشکل نام یا مسیر برای همان کلاینت است.
اینکه همهچیز با شروع کلاینت یک ارائهدهنده متوقف شود وضعیت نصبشده است، یعنی مسئله مسیر و فایروال. یک سرویس دسترسیناپذیر در حالی که بقیه خوب است طرف دور است. گیر کردن انتقالها پس از چند ثانیه اندازه بسته است. پیش از اجرای فرمانها شکل را تطبیق دهید، چون تعیین میکند کدام شواهد اول جمعآوری شود.
مرحلهای را که نخستین شکست را تولید کرد همراه با خروجی فرمان ثبت کنید. تیکتی که میگوید آدرس مبدأ اشتباه بود، با خط مسیر پیوست، ارزش اقدام دارد، اما تیکتی که VPN را خراب گزارش میکند نه.