پورت 1194 از قبل در حال استفاده است: مالک این سوکت OpenVPN کیست؟

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

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

خطای دقیق اتصال را بخوانید

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

systemctl status openvpn-server@lab --no-pager
journalctl -u openvpn-server@lab -n 20 --no-pager

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

سوکت را فهرست کنید، نه پورت را

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

ss -lunp | grep -F ':1194'
ss -ltnp | grep -F ':1194'
ss -lunp 'sport = :1194'

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

پیدا کنید کدام فرایند مالک آن است

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

sudo ss -lunp 'sport = :1194'
sudo fuser -v -n udp 1194

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

یک مالک، یا دو نمونهٔ طراحی‌شده

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

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

سه میان‌بر ارزش نام بردن دارند چون در هر بحثی دربارهٔ این خطا دیده می‌شوند. هر PID تصادفی را که شبیه مقصر است نکشید. اشتراک‌گذاری سوکت را برای خاموش کردن پیام فعال نکنید. نمایهٔ سرور را به پیکربندی نامقید سبک مشتری تغییر ندهید چون این خطای اتصال را ناپدید می‌کند؛ سرور به شکلی غیرقابل دسترس می‌شود که تشخیصش از تعارض اصلی دشوارتر است.

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

پیش از هر چیز اتصال را بررسی کنید

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

ss -lunp 'sport = :1194'
systemctl is-active openvpn-server@lab
journalctl -u openvpn-server@lab -f

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