چرا کشف همسایه IPv6 در یک VPN مسیریابی‌شده شکست می‌خورد
کشف همسایه یک پروتکل پیوند-محلی است، بنابراین یک تونل مسیریابی‌شده آن را پایان می‌دهد. یک پل می‌تواند پیوند را گسترش دهد، اما تنها به عنوان یک تصمیم طراحی با پیامدها.
کشف همسایه IPv6 به یک پیوند تعلق دارد، و تونل مسیریابی‌شده مرز میان دو پیوند است. همان یک جمله تقریباً هر گزارش دربارهٔ میزبان دوری را توضیح می‌دهد که با نشانی پاسخ می‌دهد و با هیچ چیز دیگری یافت نمی‌شود. پیش از بررسی تونل، دامنهٔ نشانی‌ای را که آزمایش می‌کنید بررسی کنید. یک نشانی پیوند-محلی تنها در پیوند خودش معنا دارد، و گروه چندپخشی گرهٔ درخواستی نیز به همان شکل محدود است. هیچ‌یک از آن دو از یک مسیریاب گذر نمی‌کند، و به همین دلیل پینگ به یک نشانی سراسری می‌تواند موفق شود در حالی که کشف برای همان میزبان موفق نمی‌شود.
دامنه پیش از پیکربندی می‌آید
درخواست و اعلام همسایه حد پرش 255 دارند و بر اساس طراحی ارسال نمی‌شوند. مسیریاب میان تونل شما و LAN دور، بسته‌های IPv6 را ارسال می‌کند و پیام‌های همسایه را به نمایندگی از آن بازپخش نمی‌کند. بنابراین حافظهٔ نهان همسایه روی رابط تونل تنها همتا و چیز کمی بیشتر دارد، که رفتار درست است و نه نقصی برای رفع.
یک نشانی پیوند-محلی مانند مدخل fe80:: نیز دارای دامنهٔ ناحیه است، و همان متن می‌تواند در پیوندی دیگر به میزبان دیگری اشاره کند. آزمایش یکی از سوی دیگر تونل چیزی جز مبهم بودن نشانی را اثبات نمی‌کند.
تله، فرض روی-پیوند بودن است
میزبانی که باور دارد پیشوندی روی پیوند است، به جای سپردن بسته به مسیریاب خود، درخواست همسایه می‌فرستد، و این شامل پیشوند /64 می‌شود که به سایتی دور مسیریابی شده است. وقتی چنین پیشوندی به صورت روی-پیوند برسد، میزبان از پیوند محلی دربارهٔ میزبانی می‌پرسد که جای دیگری زندگی می‌کند، و هیچ‌کس پاسخ نمی‌دهد. چیزی کوچک‌تر را به میزبان دور مسیریابی کنید، یا پیشوند را در مسیریابی که به نمایندگی از آن پاسخ می‌دهد پایان دهید.
یک /128 برای یک سرویس، کم‌شگفت‌ترین ترتیب است و ابهام را کاملاً برمی‌دارد. مشخصات کشف همسایه مجموعهٔ پیام‌ها و پرچم روی-پیوند را که این را تعیین می‌کند توصیف می‌کند.
پل‌سازی آگاهانه قواعد را تغییر می‌دهد
وقتی تونل قاب‌های Ethernet را حمل می‌کند، بخش‌های دور و محلی یک پیوند می‌شوند، چندپخشی به هر دو سو می‌رسد، و کشف همسایه مانند یک سوئیچ رفتار می‌کند. پیامدها هم با آن می‌آیند: سیل پخش عمومی و چندپخشی، تشخیص نشانی تکراری در سراسر پل، و اعلام‌های مسیریاب که به بخشی نشت می‌کنند که نباید آن‌ها را ببیند. دامنهٔ خرابی اکنون دو سایت را نیز در بر می‌گیرد. هیچ‌یک از این‌ها دلیلی علیه پل‌سازی نیست، و هر نکته دلیلی است برای پل‌سازی آگاهانه و نه تصادفی.
تغییر یک مشخصات از TUN به TAP برای آشکار شدن کشف، ترتیب نادرست عملیات است. سرور، کارخواه و طرح نشانی‌دهی باید هم‌راستا باشند، و کارخواهان همراه اصلاً رابط TAP ارائه نمی‌دهند، پس چنین طراحی‌ای روی لپ‌تاپ کار می‌کند و روی تلفن شکست می‌خورد. پروکسی‌ها و بازپخش‌کننده‌های همسایه سازوکارهای جداگانه‌ای با الزامات خودشان هستند، و به ترتیب مستندشدهٔ مدیر شبکه تعلق دارند نه به تنظیمات یک برنامه.
با نشانی‌ای که برنامه استفاده می‌کند آزمایش کنید
مسیر را با ip -6 route get تأیید کنید، مدخل همسایه را با ip -6 neigh بررسی کنید، سپس سرویس را روی مسیر مسیریابی‌شده تأیید کنید. DNS و مسیر بازگشت بررسی‌های جداگانه‌ای هستند، و مدخل همسایهٔ سالم هیچ‌یک از آن دو را اثبات نمی‌کند.
اگر برنامه بر مقصدی پیوند-محلی یا مبتنی بر کشف پافشاری کند، این گفت‌وگویی دربارهٔ طراحی است و نه تمرینی در تنظیم دقیق، زیرا هیچ تنظیم کارخواهی سازوکاری محدود به پیوند را از میان یک مسیریاب کارا نمی‌کند.
بنویسید کدام طراحی را دارید
پیش از رخداد ثبت کنید که مسیریابی‌شده است یا پل‌شده، چون دو استقرار به این پرسش‌ها متفاوت پاسخ می‌دهند و مهندس کشیک نباید آن را از یک مشخصات استنتاج کند.
خواندن یک‌بارهٔ مجموعهٔ پیام‌ها وسوسهٔ توضیح یک ویژگی دامنهٔ پیوند به عنوان اشکال VPN را از میان برمی‌دارد، که گران‌ترین تشخیص نادرست در این حوزه است.