آداپتور OpenVPN در ویندوز مدام قطع و وصل می‌شود؟ دنبال IP تکراری بگردید
آداپتور ویندوز که مدام قطع و وصل می‌شود اغلب تعارض نشانی است، نه باگ درایور. رویدادهای 4198 و 4199 را بخوانید، مالک دوم را پیدا کنید و سپس نشانی‌های یکتا اختصاص دهید.
در ویندوز، آداپتور OpenVPN که نشانی‌ای می‌گیرد، رهایش می‌کند و هر چند ثانیه این کار را تکرار می‌کند معمولاً باگ DHCP نیست. به آداپتور گفته می‌شود از نشانی‌ای استفاده کند که چیز دیگری از قبل به آن پاسخ می‌دهد، پس ویندوز آن را غیرقابل‌استفاده علامت می‌زند و کلاینت از نو شروع می‌کند. گزارش کلاینت ساکت می‌ماند چون تعارض در لایه‌ای پایین‌تر، داخل پشته شبکه خود سیستم‌عامل حل می‌شود.
این تفاوت مهم است، چون هر مرحله عیب‌یابی که به پیکربندی تونل معطوف باشد، نشانی تکراری سمت سرور را از دست می‌دهد.
از گزارش رویدادهای ویندوز شروع کنید، نه از گزارش کلاینت
ویندوز تعارض‌های نشانی را در گزارش سیستم با شناسه‌های رویداد 4198 و 4199 ثبت می‌کند. اولی تعارض کشف‌شده برای یک نشانی را گزارش می‌کند، دومی گزارش می‌کند که یک رابط نتوانسته از نشانی‌ای که با آن پیکربندی شده بود استفاده کند. هیچ‌کدام به OpenVPN اشاره نمی‌کنند و دقیقاً به همین دلیل به‌راحتی نادیده گرفته می‌شوند.
رویدادهای اخیر را بیرون بکشید و مهرهای زمانی آن‌ها را با چرخه تمدید آداپتور مقایسه کنید: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. تعارض هر پانزده ثانیه با کلاینتی می‌خواند که همان نشانی را دوباره در برابر مالکی امتحان می‌کند که همچنان به آن پاسخ می‌دهد. تعارض تکی هنگام اتصال به برخورد موردی اشاره دارد. در هر صورت، پرسش بعدی این است که چه کس دیگری نشانی را دارد.
سه آرایش دو میزبان را روی یک نشانی می‌گذارد
از سرور بپرسید به نظر او چه کسی نشانی را دارد، بعد از شبکه بپرسید چه کسی به آن پاسخ می‌دهد. grep -H ifconfig-push /etc/openvpn/ccd/* هر نشانی تونل تثبیت‌شده و گواهی‌ای که به آن تعلق دارد را فهرست می‌کند. ip -4 neigh show dev tap0 نشان می‌دهد پل در لایه دوم چه آموخته است. مقایسه این دو فهرست بیشتر تکراری‌ها را در کمتر از یک دقیقه پیدا می‌کند.
سه آرایش تقریباً همه را توضیح می‌دهند: یک ورودی client-config-dir یک نشانی را برای دو گواهی تثبیت می‌کند، یک قطعه tap پل‌بندی‌شده به ماشینی نشانی می‌دهد که میزبان دیگری از قبل به‌صورت ایستا دارد، یا یک فایل اجاره کهنه نشانی‌ای برمی‌گرداند که کلاینتی هنوز متصل فکر می‌کند مالک آن است. مورد سوم موذی‌ترین است، چون ifconfig-pool-persist عمداً نشانی‌ها را برای کلاینت‌های شناخته‌شده دوباره به کار می‌برد.
نشانی را یکتا کنید، نه اینکه برای آن مسابقه بدهید
ترتیب بوت فقط تعیین می‌کند امروز چه کسی برنده می‌شود، پس هر اصلاحی را که بر ترتیب راه‌اندازی مجدد استوار است موقتی بدانید. به هر کلاینت خط ifconfig-push خودش را بدهید، یا نشانی‌های ایستا را از بازه‌ای تخصیص دهید که هیچ رابط پل یا سروری به آن دست نمی‌زند. فهرست کلاینت‌ها را هم برای نام‌های مشترک تکراری بررسی کنید، چون duplicate-cn به دو نشست اجازه می‌دهد یک هویت و در نتیجه یک نشانی تثبیت‌شده را شریک شوند. اگر دستگاهی پل‌بندی‌شده واقعاً به نشانی ثابت نیاز دارد، آن را به زیرشبکه خودش ببرید یا از استخر در جایی که سرور ثبت می‌کند رزرو کنید.
فایل persist را فقط وقتی حذف کنید که بدانید چه اجاره‌هایی را نگه می‌دارد، وگرنه اتصال مجدد بعدی دوباره همان نشانی‌ها را پخش می‌کند.
به ترتیب درست راه‌اندازی مجدد کنید و یک مالک برای هر نشانی تأیید کنید
ابتدا تغییر را روی سرور اعمال کنید و بعد کلاینت‌ها را دوباره وصل کنید تا هر مشارکت‌کننده در برابر استخر اصلاح‌شده ثبت شود. اگر اول کلاینت‌ها را راه‌اندازی مجدد کنید، آن‌ها با نشانی‌هایی می‌مانند که سرور هنوز اشغال‌شده می‌داند. پس از راه‌اندازی مجدد، فایل وضعیت را بخوانید و تأیید کنید هر نام مشترک یک بار با یک نشانی ظاهر می‌شود. دو ورودی برای یک نام یعنی یک نشست قدیمی هرگز بسته نشده، نه اینکه استخر خراب است.
اگر کلاینتی هنوز نمی‌تواند نشانی‌اش را نگه دارد، بررسی کنید آیا رابط پلی روی همان میزبان آن را حمل می‌کند. پلی که نشانی‌ای را از دستگاه فروشنده به ارث برده، حتی وقتی سرور VPN آن نشانی را به کلاینت داده است، برای آن به ARP پاسخ می‌دهد.
پیش از بستن تیکت، یک چرخه کامل تمدید را زیر نظر بگیرید
یک خوانش پاک چیزی را ثابت نمی‌کند. حداقل ده دقیقه آداپتور را زیر نظر بگیرید و در میانه یک اتصال مجدد را اجبار کنید: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. نشانی باید از اتصال مجدد جان سالم به در ببرد و در وضعیت ترجیحی بماند.
سپس پرس‌وجوی رویدادها را از مرحله اول دوباره اجرا کنید و تأیید کنید چیز جدیدی برنمی‌گرداند. گزارش ساکت در طول اتصال مجدد مدرکی است بر اینکه تعارض از میان رفته، در حالی که گزارش ساکت پس از یک اتصال تنها یعنی مسابقه هنوز رخ نداده است. آخر از همه، منبعی را که تونل برای آن وجود دارد آزمایش کنید، چون پلی که نشانی‌اش را از دست داده می‌تواند مسیر فروشنده را بشکند در حالی که خود VPN سالم به نظر می‌رسد.
بازه استخر، هر نشانی تثبیت‌شده و میزبانی که مالک آن است را در یادداشت‌های سرور ثبت کنید. آنگاه برخورد بعدی در چند دقیقه دیده می‌شود، نه اینکه یک بعدازظهر کامل برای کشف دوباره لازم باشد.