آدرس IPv6 محلی پیوند روی VPN کار نمی‌کند: چرا fe80 در پیوند می‌ماند
یک نشانی fe80:: فقط روی یک پیوند معنا دارد. ببینید چرا VPN مسیریابی‌شده نمی‌تواند آن را حمل کند، خرابی چگونه دیده می‌شود و به‌جای آن از کدام نشانی استفاده کنید.
تونل را بالا می‌آورید، با تونل به‌عنوان رابط مبدأ به fe80::1 پینگ می‌کنید و چیزی برنمی‌گردد. این قاعده فایروالی نیست که فراموش کرده باشید. نشانی محلی پیوند فقط روی همان یک پیوندی که در آن ساخته شده معنا دارد و VPN مسیریابی‌شده آن پیوند نیست. fe80::1 روتر دور در بخش LAN دور قرار دارد؛ شما یک گام آن‌سوتر در بخشی دیگر هستید و IPv6 هیچ سازوکاری ندارد که روتر بسته‌های محلی پیوند را اصلاً ارسال کند.
پیشوند fe80 دامنه را توصیف می‌کند، نه بازه را
یونی‌کست محلی پیوند fe80::/10 است و ویژگی تعیین‌کننده عدد نیست، دامنه است. نشانی فقط روی یک پیوند معتبر است و هر رابط آن را از شناسه خود می‌سازد؛ به همین دلیل دو ماشین بی‌ارتباط در دو شبکه بی‌ارتباط می‌توانند هر دو به fe80::1 پاسخ دهند بدون کمترین تعارضی. پیشوند در واقع می‌گوید «روی پیوندی»؛ خود پیوند از بافت می‌آید.
روی یک میزبان، آن بافت همان ناحیه یا شناسه دامنه است که بعد از علامت درصد می‌افزایید: fe80::1%eth0 در لینوکس، fe80::1%3 یا fe80::1%12 در ویندوز و در ابزارهایی که شاخص‌های رابط را نشان می‌دهند. هسته نشانی را همراه با شاخص رابط تفکیک می‌کند و سپس می‌فرستد. اگر ناحیه را حذف کنید، مقصد مبهم می‌شود و پشته راهی برای انتخاب بخش ندارد.
چرا تونل مسیریابی‌شده نمی‌تواند آن را برساند
VPN مسیریابی‌شده یک رابط نقطه‌به‌نقطه است که نشانی‌های خودش را حمل می‌کند، معمولاً یک /64 از فضای IPv6 یکتای محلی یا خصوصی داخل تونل. LAN دور پیوندی جداست که از طریق مسیریابی و ارسال نقطه پایانی تونل به نمایندگی شما به آن می‌رسید. این‌ها دو بخش متمایزند، پس نشانی از یکی مقصد معتبری در دیگری نیست.
قاعده ارسال در استاندارد صریح است و نه ویژگی عجیب کارخواه شما: روترها بسته‌هایی با مبدأ یا مقصد محلی پیوند را ارسال نمی‌کنند. به همین دلیل بسته می‌میرد حتی وقتی جدول مسیریابی درست به نظر می‌رسد. مسیری برای fe80::/64 به سمت تونل اضافه کنید؛ پشته منطبق با استاندارد یا آن را رد می‌کند یا می‌پذیرد و هر بسته منطبق را دور می‌ریزد: دامنه مقصد می‌گوید «فقط این پیوند» و رابط خروجی آن پیوند نیست.
کشف همسایه همان مرز را تقویت می‌کند. میزبان‌ها گام‌های بعدی محلی پیوند را با درخواست همسایه که به چندپخشی دامنه پیوند با محدودیت گام 255 فرستاده می‌شود تفکیک می‌کنند، تا روترها بتوانند هر چیز ارسال‌شده را رد کنند. کارکردن این روی تونل یعنی پروکسی‌کردن کشف برای بخشی دور، که همان پل لایه 2 با کلاه دیگر است.
خرابی دومی آرام‌تر هم هست و کسانی را که به‌هرحال مسیر را زور می‌کنند لغزش می‌دهد: ناحیه. هر ناحیه‌ای که محلی بنویسید نام رابط تونل را می‌آورد، در حالی که نشانی موردنظر به رابط LAN دور بسته شده است. این دو هرگز یکی نمی‌شوند، پس بسته در انتهای دور به رابط درست هدایت نمی‌شود.
خرابی در عمل چگونه دیده می‌شود
خروجی ابزار برای خطای دامنه مانند خطای مسیریابی یا فایروال خوانده می‌شود و دقیقاً به همین دلیل است که آدم‌ها بعدازظهری را در لایه اشتباه می‌گذرانند.
| What you run | What you see | What it means |
|---|---|---|
| ping fe80::1 with no zone | Invalid argument on Linux, or a transmit failure on Windows | The stack cannot pick an interface for an ambiguous destination |
| ping -6 -I tun0 fe80::1 | Destination unreachable, or a silent timeout | The address is not on the tunnel link, so there is nothing on-link to answer |
| ssh user@fe80::1 after the tunnel is up | Hangs, then no route to host | The SYN never left the machine in a deliverable form; the server logs nothing |
| ip -6 neigh show dev tun0 | Empty table | No neighbor entry can exist for a link-local host that is not on this link |
| fe80::/64 inside AllowedIPs or route-ipv6 | Config accepted, traffic still dropped | The tunnel carried the packet; the receiving stack refused to forward it |
ردیف سوم بیشترین وقت را تلف می‌کند، چون کارخواه ssh بدون خروجی شبیه مشکل سرویس شنوا به نظر می‌رسد. اگر راهی برای ورود دارید، طرف دور را ببینید و تأیید کنید sshd به همه نشانی‌ها بسته شده یا فقط به یکی.
از نشانی‌ای استفاده کنید که برای مسیریابی در نظر گرفته شده بود
برای هر چیزی که باید از تونل به آن برسید، از نشانی‌ای استفاده کنید که سرویس دقیقاً برای همان منظور گرفته است: یک نشانی یونی‌کست جهانی، یا یک نشانی یکتای محلی از fc00::/7، همان بازه‌ای که دقیقاً برای این حالت داخلی رزرو شده است. تأیید کنید شنونده واقعاً آن را می‌بندد و مسیر بازگشت و هر قاعده فایروال میزبان را بررسی کنید.
به‌جای حدس زدن به میزبان دور نگاه کنید. ip -6 addr show نشانی‌های موجود را فهرست می‌کند و ss -6 -ltn نشان می‌دهد دیمن به چه چیزی گوش می‌دهد. سرویسی که فقط به fe80:: بسته شده فقط از بخش خودش در دسترس است، که معمولاً پیش‌فرضی است که کسی عمداً انتخاب نکرده و با توافق مدیر می‌توان تغییرش داد.
وقتی سرویس واقعاً قابل بازبستن نیست، پل را به لایه کاربرد ببرید نه لایه شبکه. یک بازپخش‌گر روی میزبان دور که به نشانی مسیریابی‌پذیر گوش می‌دهد و به نشانی محلی پیوند وصل می‌شود، مشکل را بدون گسترش هیچ بخشی حل می‌کند:
socat TCP6-LISTEN:8080,bind=[fd00:1:2::10] TCP6:[fe80::1%eth0]:80اینجا ناحیه در سمت درست است، روی میزبانی که واقعاً eth0 را روی آن پیوند دارد. کارخواه شما با fd00:1:2::10 صحبت می‌کند که به‌طور عادی مسیریابی می‌شود و بازپخش‌گر گام محلی پیوند را محلی انجام می‌دهد. همان ترفند برای رابط وب یک دستگاه یا BMC قدیمی که فقط نشانی محلی پیوند را اعلام می‌کند کار می‌کند.
چه وقت پل واقعاً پاسخ است و چه چیزی را بررسی کنیم
برخی استقرارها واقعاً به یک بخش مشترک نیاز دارند: دستگاهی که فقط کشف محلی پیوند را می‌فهمد، دستگاهی که به چندپخشی وابسته است، آزمایشگاهی که یک LAN تخت را بازتولید می‌کند. این مشکلی در لایه 2 است و پاسخ لایه 2 می‌خواهد، مانند یک دستگاه tap که به رابط دور پل شده یا محصول کارخواهی با حالت پل صریح. هزینه‌اش ترافیک پخش و چندپخشی است که از تونل می‌گذرد، به‌علاوه کشف همسایه که باید سرتاسر کار کند.
با افزودن fe80::/64 به یک پروفایل مسیریابی‌شده آن را تقریب نزنید. این بدترین حالت را می‌سازد: پیکربندی تمام‌شده به نظر می‌رسد، جدول مسیریابی یک ورودی نشان می‌دهد و هر بسته باز هم جایی بین دو پشته که هر دو درست رفتار می‌کنند دور ریخته می‌شود.
با رابط بررسی کنید نه با پینگ. ip -6 addr show tun0 می‌گوید آیا پیوند تونل نشانی محلی پیوند خودش را ساخته و ip -6 route get fe80::1%tun0 می‌گوید هسته واقعاً با مقصد دامنه‌دار چه می‌کند. وقتی هسته می‌گوید مقصد روی آن رابط دسترسی‌ناپذیر است، هیچ تنظیم تونلی آن را عوض نمی‌کند و وقت آن است که ویرایش پروفایل را متوقف کنید.
یک توالی کوتاه که پرسش را روشن می‌کند:
- نشانی را روی میزبان دور بخوانید و توجه کنید fe80:: است یا پیشوندی مسیریابی‌پذیر.
- اگر fe80:: است، سرویس را بازببندید، روی همان میزبان بازپخش کنید یا بخش را پل کنید؛ اگر مسیریابی‌پذیر است، مسیر، فایروال یا نشانی بستن را درست کنید.
- هر بار که دوباره آزمایش می‌کنید ناحیه را بازبینی کنید، چون فرمان کپی‌شده معمولاً رابط اشتباه را نگه می‌دارد.
منابع: RFC 4291، معماری نشانی‌دهی IPv6.