پورت VPN ساکت است؟ شنونده، نشانی اتصال یا فایروال میزبان
سرویس متوقف و افتادن بسته توسط فایروال دو تعمیر متفاوت می‌خواهند. نخست سوکت محلی را بررسی کنید، سپس یک تلاش خارجی مجاز را با گزارش تطبیق دهید.
VPN روی پورت خود هیچ پاسخی نمی‌دهد، و دو علت ممکن دو تعمیر متضاد می‌خواهند: یا هیچ فرایندی سوکت را باز نکرده، یا سوکت وجود دارد و چیزی میان دو ماشین بسته‌ها را متوقف می‌کند. یک فرمان نیمهٔ اول این پرسش را روشن می‌کند، از همین رو پیش از دست‌زدن به هر قاعدهٔ فایروال می‌آید. ترتیب زیر در هر گام یک توضیح را حذف می‌کند، نه اینکه گمان دیگری بیفزاید. حدس‌زدن میان این دو همان چیزی است که عیب‌یابی ده‌دقیقه‌ای را به یک شب کامل تبدیل می‌کند.
فرض کنید می‌توانید به سرور وارد شوید و کلاینت یک پروفایل واقعی است نه یک اسکنر. هر دو فرض مهم‌اند، چون یک کاوشگر عمومی نمی‌تواند به پرسشی ویژهٔ پروتکل پاسخ دهد.
آیا سوکت اصلاً وجود دارد
با آنچه سرویس دربارهٔ خودش می‌گوید آغاز کنید: اینکه بالا آمده یا نه و، مفیدتر، نخستین خطای راه‌اندازی‌اش چه بوده است. خطای تجزیه، کلید گمشده یا خطای اتصال باعث می‌شود شنونده هرگز پدید نیاید، و فرایند می‌تواند آن‌قدر بی‌صدا خارج شود که خط وضعیت مبهم خوانده شود. واحدی که خود را فعال گزارش می‌کند به‌تنهایی دلیل نیست، چون ممکن است فرایند اصلی زنده باشد در حالی که مؤلفه‌ای که باید پورت را متصل می‌کرد پیش‌تر تسلیم شده است.
systemctl status openvpn-server@server --no-pager
journalctl -u openvpn-server@server -n 30 --no-pager
ss -lunpفهرست سوکت‌ها همان واقعیتی است که بقیهٔ عیب‌یابی بر آن استوار است. ستون نشانی محلی را بخوانید نه فقط پورت را، چون همان ستون جایی است که اتصال‌های loopback و اتصال به رابط اشتباه دیده می‌شوند. شنونده‌ای که روی 127.0.0.1 وجود دارد بی‌عیب کار می‌کند و همچنان برای لپ‌تاپ شما نامرئی است.
سوکت روی کدام نشانی و کدام خانواده پاسخ می‌دهد
دو اشتباه از دید کلاینت یکسان به نظر می‌رسند و بیشتر گزارش‌های "دسترسی‌ناپذیر" را توضیح می‌دهند. سروری که به نشانی loopback متصل است هرگز ترافیک ماشین دیگری را نمی‌پذیرد، و سروری که فقط به یک نشانی IPv4 متصل است هرگز به کلاینتی که نشانی IPv6 همان میزبان را شماره می‌گیرد پاسخ نمی‌دهد. پیش از هر فرضی دربارهٔ سیاست، نشانی در جدول سوکت‌ها را با نشانی‌ای که کلاینت واقعاً شماره می‌گیرد، حرف به حرف مقایسه کنید.
محدودکردن فهرست به یک پورت آن را خوانا نگه می‌دارد وقتی میزبان چند سرویس اجرا می‌کند. فیلتر sport پورت را همراه با ترابری‌ای که آزمایش می‌کنید می‌گیرد:
ss -lun 'sport = :51820'
ss -ltnp 'sport = :1194'ستون پروتکل کل پاسخ را عوض می‌کند
جدول سوکت‌ها هم بر پورت و هم بر پروتکل کلید می‌خورد، و این دو ورودی مستقل‌اند. سرویسی که روی 1194 به TCP پاسخ می‌دهد هیچ چیزی دربارهٔ اینکه چیزی روی UDP 1194 گوش می‌دهد نمی‌گوید، و کلاینت همیشه فقط یکی از این دو را به کار می‌برد. تأیید کنید که پیکربندی سرور کدام ترابری را برمی‌گزیند و پروفایل کلاینت کدام را می‌فرستد، سپس همان سطر را جست‌وجو کنید.
UDP پیچ دوم دارد: کاوشگر تأییدنشده خطایی نیست که سرویس موظف به پاسخ دادنش باشد. اسکنی که پورت را ساکت گزارش می‌کند، احتیاط سرویس را سنجیده است نه دسترس‌پذیری‌اش، پس با کلاینت و پروفایل واقعی آزمایش کنید.
یک تلاش، سه جای نگاه
از یک کلاینت تأییدشده دقیقاً یک تلاش انجام دهید و زمان را تا ثانیه بنویسید. سپس سه منبع را برای همان بازه بخوانید: قاعدهٔ شبکه یا کنسول ارائه‌دهنده، شمارنده‌ها یا گزارش فایروال میزبان، و گزارش خود سرویس. انجام یک‌بارهٔ این کار همان چیزی است که سه روایت را قابل مقایسه می‌کند و کمتر از تکرار تلاشی تمام می‌شود که کسی مهر زمانی‌اش را ثبت نکرده است.
دو پیامد در دو جهت متضاد اشاره می‌کنند. اگر هیچ بسته‌ای به میزبان نرسیده باشد، مسیر آن را می‌اندازد و شنونده بی‌ربط است. اگر بسته به سوکت رسیده و سرویس آن را رد کرده باشد، مسیر درست است و پاسخ در پروتکل، رمزنگاری یا داده‌های ورود است. بازکردن پورت برای سرویسی که پیش‌تر اتصالی را پذیرفته، عیب‌یابی بعدی را سخت‌تر می‌کند نه آسان‌تر.
پیش از تغییر قاعده، مرحله را نام بگذارید
مذاکره‌ای که آغاز می‌شود و احراز هویتی که شکست می‌خورد یک خرابی است، و تونلی که برقرار می‌شود در حالی که ارسال بسته می‌گیرد خرابی‌ای کاملاً دیگر. نام‌گذاری مرحله نخست، تعمیر را باریک نگه می‌دارد: مشکل داده‌های ورود با قاعدهٔ فایروال حل نمی‌شود، و مشکل مسیر داده با راه‌اندازی دوباره حل نمی‌شود.
باریک‌ترین عیب‌یابی‌ای را به کار ببرید که به پرسش پاسخ می‌دهد. مشاهدهٔ موقت بسته روی یک پورت، زیر کنترل یک مدیر، ابزار معقولی است؛ خاموش‌کردن کل فایروال نیست، چون نتیجه دیگر قابل نسبت‌دادن نمی‌شود. مستندات ss فیلترهای بالا را پوشش می‌دهد و گام نخست ارزان‌تری از هر ضبط است. ثبت کنید کدام‌یک از دو شاخه را اثبات کردید، و رخداد بعدی از پاسخی دانسته آغاز می‌شود.