مسیر را اضافه می‌کنید، تونل بالا می‌آید، و با این حال ping به سمت دیگر با افت کامل می‌میرد، نه با «network unreachable». این تفاوت مهم است، چون نگاه را از جدول مسیریابی به خود نشانی برمی‌گرداند. مقصد 169.254 از نوع link-local است و دامنه‌اش بر اساس طراحی در نخستین hop پایان می‌یابد، نه به دلیل پیکربندی نادرست.

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

نشانی بدون مسیر نیست، مسیریابی‌ناپذیر است

نشانی‌های IPv4 از نوع link-local خود را زمانی تخصیص می‌دهند که چیز بهتری پاسخ ندهد؛ ریشه نشانی‌دهی خصوصی خودکار در Windows و معادلش در سامانه‌های دیگر همین است. این بازه همزمان روی هر پیوند استفاده می‌شود و دقیقاً به همین دلیل کار می‌کند: دو میزبان در یک بخش می‌توانند بدون هیچ هماهنگی گفتگو کنند.

به سبب همین ویژگی، مسیریاب نباید این بسته‌ها را میان شبکه‌ها ارسال کند. دریافت بسته‌ای که به مقصد link-local نشانه‌گذاری شده و فرستادن آن از رابطی دیگر ابهام می‌سازد، زیرا «محلی» فرستنده و «محلی» گیرنده دو جای متفاوت‌اند. هیچ جستجویی نمی‌تواند تعیین کند فرستنده کدام را می‌خواسته. ارسال در اینجا گزینه سیاستی نیست که مدیر آن را فعال کند؛ کلاس نشانی آن را کنار می‌گذارد.

پس دروازه‌ای که 169.254.1.10 را از طریق تونل قابل دسترس ثبت می‌کند، از هسته چیزی می‌خواهد که قالب نشانی ممنوع کرده است. بسته بسیار پیش از رسیدن به میزبان دور دور ریخته می‌شود و هیچ دقتی در مسیر این نتیجه را تغییر نمی‌دهد.

چرا تونل مشکل دامنه را آشکار می‌کند

رابط TUN بسته‌های IP را میان دو همتا جابه‌جا می‌کند و بخش اشتراکی پشت خود ندارد. نه پخشی هست، نه ARP برای طرف دیگر، و نه کشف همسایگی که مقصد link-local را به نشانی لایه پیوند تبدیل کند.

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

در Windows نشانه دومی هم هست که بی‌ربط به نظر می‌رسد و همان ریشه را دارد: کارت شبکه‌ای که تنها نشانی link-local دارد دروازه قابل استفاده ندارد، پس شناسایی شبکه نمی‌تواند اتصال را دسته‌بندی کند و نمایه دیوار آتش روی public می‌افتد. تونل علت نیست؛ نشانی علت است.

با سه پرسش تصمیم بگیرید

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

QuestionIf yesIf no
Can the far-side host be given a routable address?Change the host or fix DHCP and route normallyContinue to the next question
Does the device accept a static address at all?Assign one from the site's real prefixBridging is the only remaining option
Can you accept broadcast crossing the tunnel?A bridge is viable for a small segmentReplace the device or accept no remote access

بیشتر موارد در پرسش نخست متوقف می‌شوند. میزبانی با نشانی link-local معمولاً یعنی DHCP پاسخ نداده، کابل یا VLAN نادرست است، یا کسی نشانی را دستی نوشته است. تعمیر آن ارزان‌تر از هر کار تونل است و مشکل را برای همه کلاینت‌های آینده برمی‌دارد، نه فقط این یکی.

پیش از هر فرضی سمت سرور را بررسی کنید. ip addr show و ip route را روی میزبان و arp -n یا route print -4 را روی کلاینت اجرا کنید تا ببینید پیشوند واقعاً هست یا فقط یک ورودی کهنه چنین می‌گوید.

پل وقتی پاسخ درست است چه هزینه‌ای دارد

پل‌کردن یک کارت فیزیکی با کارت TAP کلاینت دور را بخشی از دامنه پخشی محلی می‌کند. آن‌گاه پخش و کشف همسایگی کار می‌کنند و نشانی link-local دوباره معنا می‌یابد، چون کلاینت واقعاً در آن پیوند محلی است.

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

وقتی پل می‌سازید هر دو نیمه لازم است: پل روی سرور و مسیری در نمایه کلاینت که بگوید کدام مقصدها در آن سوی دیگرند. پل تنها کلاینت را در حدس رها می‌کند و مسیر تنها کلاس نشانی را درست نمی‌کند.

مقالات مرتبط