دو مالک، یک نشانی: IPهای تکراری روی پل TAP

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

پیش از دست زدن به پل، شواهد تعارض را بخوانید

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

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

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

هر ادعا را در قطعه فهرست کنید

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

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

ip -4 addr show | grep -E 'inet |^[0-9]+: '
bridge link show
ip neigh show dev br0

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

پل‌ها را فقط جایی شماره‌گذاری کنید که به هویت نیاز دارند

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

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

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

کاری کنید که اصلاح از راه‌اندازی مجدد جان سالم به در ببرد

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

مالک آن پیکربندی را پیدا کنید: نمایه مدیر شبکه، پرونده مخصوص هر واسط، تعریف کانتینر یا ماشین مجازی، یا قطعه‌ای از cloud-init. آن را همان‌جا تغییر دهید، سپس آگاهانه یک میزبان متأثر را دوباره راه‌اندازی کنید تا تأیید شود که مقدار جدید همان است که برمی‌گردد. راه‌اندازی مجدد تنها آزمونی است که پایداری را اثبات می‌کند.

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

آن را با همه کارخواه‌ها در حالت برخط اثبات کنید

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

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

arping -D -I br0 10.8.0.2
ip neigh show dev br0 | grep 10.8.0.2

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