سایت‌های پل‌شده هنوز به تصمیم خروج اینترنت محلی نیاز دارند

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

پل قاب‌ها را حمل می‌کند، نه تصمیم‌ها

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

دو روتر روی آن زیرشبکه مشترک بگذارید و هر دو دروازه محتمل می‌شوند، چه یکی نزدیک کلاینتی باشد که از آن استفاده می‌کند و چه نباشد.

کلاینت چگونه دروازه خود را انتخاب می‌کند

تصمیم IPv4 که در RFC 1122 توصیف شده ساده است. مقصدی درون زیرشبکه متصل کلاینت مستقیما و با ARP به دست می‌آید و مقصدی بیرون آن به دروازه پیش‌فرض پیکربندی‌شده می‌رود. به همین دلیل ترافیک همان زیرشبکه بین سایت‌ها می‌تواند بدون هیچ دخالت روتر از پل عبور کند و به همین دلیل ترافیک اینترنت کاملا به آدرس دروازه‌ای که کلاینت دریافت کرده وابسته است. این دو رفتار مستقل‌اند و اشتراک فایلی که کار می‌کند فقط اولی را اثبات می‌کند.

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

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

بگذارید DHCP خروج مورد نظر را بیان کند

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

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

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

چهار چیز را جداگانه آزمایش کنید

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

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

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