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

از فاصله راه‌اندازی مجدد شروع کنید

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

بررسی کنید که راه‌اندازی‌های مجدد نسبت به دستگاه دوم چه زمانی آغاز شد. لپ‌تاپ نو، گوشی یا نمایه‌ای که روی ماشین یدکی کپی شده محرک‌های معمول‌اند، و زمان معمولاً با روزی که کسی آن را راه‌اندازی کرده همخوانی دارد.

فاصله و دلیل را بنویسید. هر دو مدرک‌اند و جمع‌آوری هر دو ارزان است.

بخوانید سرور درباره ورود دوم چه گفت

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

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

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

هویت را در سمت سرور جدا کنید

برای هر دستگاه یک گواهی از طریق CA که برای این سرور امضا می‌کند صادر کنید. با Easy-RSA این یعنی نام کلاینت جداگانه برای هر دستگاه، و نمایه سپس از همان گواهی و کلیدش ساخته می‌شود. نام مشترک به هویت دستگاه تبدیل می‌شود، و این دقیقاً همان چیزی است که سرور کم داشت. آن‌ها را به نام دستگاه نام‌گذاری کنید نه شخص، تا جایگزینی نامی نو بسازد.

کلید مشترک کانال کنترل چیز جدایی است. tls-crypt یا tls-auth کانال کنترل را برای هر کلاینت محافظت می‌کند و قرار است مشترک باشد. هویت کلاینت نیست، و جایگزین کردنش گواهی تکراری را درست نمی‌کند.

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

پس از جداسازی، نشانی‌ها و تنظیمات را هم‌تراز نگه دارید

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

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

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

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

وقتی سخت‌افزار بازنشسته یا گم می‌شود گواهی را ابطال کنید، نه اینکه نمایه را از ماشین قدیمی پاک کنید. ابطال یک CRL تازه می‌سازد و سرور به آن فایل جایی که crl-verify اشاره می‌کند نیاز دارد. با وجود این دستور، CRL گمشده یا ناخوانا باعث می‌شود سرور هر کلاینت را رد کند، پس پس از هر به‌روزرسانی یک حساب شناخته‌شده را آزمایش کنید.

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

مقالات مرتبط