رفع تعارض آدرس IP محلی پس از اتصال به VPN

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

سه خرابی با یک پیام خطا

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

هم‌پوشانی هیچ آدرسی را تکراری نمی‌کند. شبکه محلی شما 192.168.1.0/24 است، شبکه دفتر هم 192.168.1.0/24 است، و اکنون مسیر به دفتر به آدرس‌هایی اشاره می‌کند که چاپگر و NAS شما هم هستند. به معنای ARP هیچ چیزی در تعارض نیست؛ بسته به‌سادگی در یکی از دو شبکه به دستگاه اشتباه می‌رود.

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

آزمون 1: آیا تکراری در قطعه خودتان است؟

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

ip -br addr
ip neigh
ip route show table all | grep -E 'wg|tun|ppp'

در ویندوز همان اطلاعات از ipconfig /all و Get-NetIPAddress می‌آید، و حافظه همسایه‌ها در arp -a است. اگر آدرس مورد اختلاف روی آداپتور فیزیکی باشد و شکایت بدون اجرای VPN ظاهر شود، VPN تماشاگر است و باید عیب‌یابی آن را متوقف کنید.

برای اثبات تکراری به‌جای حدس زدن، آدرس را از دستگاهی که مالک آن نیست بررسی کنید. arping -D کاوش را با آدرس مبدأ صفر می‌فرستد، پس پاسخی از یک MAC غیرمنتظره ثابت می‌کند که میزبان دیگری از قبل به آن آدرس پاسخ می‌دهد.

sudo arping -D -I eth0 -c 3 192.168.1.50

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

آزمون 2: آیا دو شبکه هم‌پوشانی دارند؟

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

ip route get 192.168.1.10
ip -br addr show

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

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

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

آزمون 3: آیا تونل یک آدرس را دو بار داد؟

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

wg show all allowed-ips
wg show wg0 latest-handshakes
wg show wg0 transfer

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

OpenVPN استخر دارد، و برخورد رایج یک پروفایل کلاینت مشترک با خط ثابت --ifconfig است که به ماشین دومی کپی شده است. آنگاه هر دو کلاینت همان آدرس تونل را درخواست می‌کنند و سرور جلسه‌ای را که اول پردازش می‌کند می‌پذیرد. تمام شدن استخر با --duplicate-cn نتیجه مشابهی می‌دهد وقتی چند جلسه از یک گواهی برای یک ورودی رقابت می‌کنند.

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

در منبع تعمیر کنید و سپس هر دو دستگاه را بازبینی کنید

ترتیب مهم است. ابتدا تکراری شبکه محلی را درست کنید، زیرا کلاینتی که نمی‌تواند آدرسی را نگه دارد تونل را هم نمی‌تواند نگه دارد. سپس تأمین را در سمت VPN درست کنید، زیرا ویرایش سمت کلاینت روی تخصیص استخر در اتصال بعدی لغو می‌شود. در پایان با هویت‌های تکراری سروکار داشته باشید: جفت کلیدهای جداگانه در WireGuard، گواهی‌های جداگانه یا حداقل پروفایل‌های جداگانه در OpenVPN.

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

sudo dhclient -r eth0 && sudo dhclient eth0
ipconfig /release && ipconfig /renew

سپس از هر دو سر بررسی کنید، نه یکی. دروازه را تأیید کنید، سپس سرویسی که واقعاً نیاز دارید، سپس دوباره وصل شوید و تکرار کنید. اگر دو دستگاه درگیر بودند، هر دو را بررسی کنید: جابه‌جا کردن یک آدرس دیگری را با ورودی‌های همسایه کهنه یا اجاره قدیمی رها می‌کند که بعداً دوباره ظاهر می‌شود.

چه کاری در مسیر نکنید

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

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