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

کلاینت چه گزارش می‌دهد و واقعاً چه رخ داد

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

پورت و نشانی مقید دو واقعیتی هستند که تعیین می‌کنند آیا بسته اصلاً می‌رسد.

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

نشانی‌ای را که بسته روی آن گوش می‌دهد بیابید

DSM پورت‌های Ethernet را شماره‌گذاری می‌کند و هر یک نشانی خودش را دارد. صفحهٔ VPN Server واسطی را نام می‌برد که سرویس OpenVPN استفاده می‌کند و پنل شبکه نشانی پیکربندی‌شده روی آن واسط را نشان می‌دهد. آن‌ها را به همین ترتیب بخوانید، از سرویس به بیرون، تا آنچه گوش می‌دهد را توصیف کنید نه آنچه گمان می‌کنید باید استفاده کند.

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

sudo ss -lunp | grep 1194

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

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

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

اگر DSM آن نشانی را از طریق DHCP می‌گیرد، ابتدا یک رزرو بسازید. تغییر اجاره به‌آرامی ارسال به جلویی را که دیروز کار می‌کرد می‌شکند.

sudo tcpdump -i any -n udp port 1194

پیش از آنکه کلاینت تلاش کند متصل شود ضبط را آغاز کنید و نشانی مبدأ را در هر آنچه ظاهر می‌شود بخوانید. هیچ چیز یعنی چیزی در مسیر آن را دور انداخته است: ارسال به جلو، دیوار آتش DSM یا واسطی که به آن نشانه رفته بود، و تا وقتی این وضع ادامه دارد گواهی‌ها نمی‌توانند علت باشند. چیزی که از نشانی عمومی کلاینت بدون پاسخ می‌رسد یعنی NAS درخواست را دریافت کرد و تصمیم گرفت پاسخ ندهد. این‌ها یافته‌های متفاوتی هستند و فقط دومی شما را به تنظیمات خود بسته بازمی‌گرداند.

تنها آنگاه به گواهی‌ها و ترابری نگاه کنید

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

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

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

مقالات مرتبط