دست‌دادن OpenVPN در Synology شکست می‌خورد؟ ارسال LAN را بررسی کنید

لپ‌تاپ شما می‌گوید که دست‌دادن TLS شکست خورده است، پس وسوسه می‌شوید گواهی‌نامه‌ها را از نو بسازید. پیش از آن پرسش کسل‌کننده‌تری بپرسید: Synology واقعاً روی کدام پورت Ethernet گوش می‌دهد؟ یک NAS با دو پورت LAN دو نشانی دارد، و بستهٔ VPN Server در DSM شنوندهٔ OpenVPN خود را به یکی از آن‌ها می‌بندد. وقتی روتر 1194 را به نشانی دیگر ارسال می‌کند، هیچ بسته‌ای هرگز به سرویس نمی‌رسد و کلاینت چیزی برای مذاکره ندارد.

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

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

DSM پورت‌های خود را LAN 1 و LAN 2 می‌نامد و هر کدام نشانی و زیرشبکهٔ جداگانه دارند. VPN Server را باز کنید، واسط نام‌برده‌شده در زبانهٔ OpenVPN را بخوانید، سپس Control Panel را باز کنید و نشانی IPv4 را که DSM روی همان واسط دارد یادداشت کنید. این دو مقدار، نه نام میزبان NAS، همان چیزی است که ارسال باید نام ببرد.

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

خود سوکت را از طریق SSH ببینید، چون تنها جایی است که نشان می‌دهد سرویس‌دهنده واقعاً به چه چیزی بسته شده، نه آنچه صفحهٔ تنظیمات قصد دارد.

sudo netstat -anp | grep 1194

ارسال موجود را ویرایش کنید نه اینکه ارسال دیگری بیفزایید

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

external 1194/udp  ->  192.0.2.20:1194/udp

پورت درونی را برابر پورت شنود نگه دارید و پروتکل را یکدست نگه دارید. UDP 1194 شنوندهٔ پیش‌فرض است، در حالی که نمایهٔ TCP به شنوندهٔ خودش در سمت بسته و ارسال متناظر روی روتر نیاز دارد. ارسال TCP به سرویسی که فقط روی UDP گوش می‌دهد سکوت می‌دهد، نه خطا.

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

ثابت کنید که بسته‌ها اصلاً می‌رسند

نخست روی NAS ضبط را آغاز کنید، سپس از کلاینت وصل شوید و نشانی مبدأ را در خروجی بخوانید. ضبطی که پس از شکست آغاز شود چیزی نشان نمی‌دهد و چیزی ثابت نمی‌کند.

sudo tcpdump -i any -n udp port 1194

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

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

وقتی بسته‌ها می‌رسند، ارسال را سرزنش نکنید

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

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

مسیری را که کاربر راه‌دور واقعاً می‌پیماید بیازمایید

کلاینت داخل همان LAN می‌تواند بدون دست زدن به ارسال به NAS برسد، پس دربارهٔ دسترسی راه‌دور چیزی ثابت نمی‌کند. از تلفنی با Wi-Fi خاموش استفاده کنید، یا از کسی بیرون شبکه بپرسید، و در آن تلاش شمارندهٔ روتر را ببینید. اگر تلاش راه‌دور شکست بخورد و تلاش محلی موفق شود، ارسال یا دیوار آتش هنوز در میان است.

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