کاسکید SoftEther: اتصال آگاهانه دو هاب مجازی
کاسکید یک هاب محلی را زیر یک هویت پیکربندی‌شده به هابی دور متصل می‌کند. این یک گره خروجی نیست و هر چیزی را که آن هاب‌ها از قبل پل می‌زنند حمل می‌کند.
دو هاب SoftEther که با کاسکید به هم متصل شده‌اند یک دامنه پخش‌شده را شریک می‌شوند، بنابراین یک حلقه یا سرور DHCP دوم دیگر خطای محلی نیست و به خطای مشترک تبدیل می‌شود. این کل مدل ریسک است. خود کاسکید یک رابطه کلاینت پیکربندی‌شده است: هاب مجازی محلی زیر هویتی که آن سرور مجاز می‌کند به هاب یک سرور دور متصل می‌شود. این یک بلوک سازنده برای شبکه مجازی بزرگ‌تر است، هرگز خروجی اینترنت نیست.
1. تصمیم بگیرید پیوند چه باید حمل کند
از نیاز شروع کنید، نه از قابلیت. کاسکید فریم‌های لایه دو را بین هاب‌ها جابه‌جا می‌کند، و این همان چیزی است که وقتی دو سایت باید مانند یک قطعه اترنت به نظر برسند می‌خواهید. اگر نیاز فقط دسترسی مسیریابی‌شده به چند زیرشبکه باشد، مسیر مسیریابی‌شده ساده‌تر است و به شکل‌های قابل‌مشاهده‌تری شکست می‌خورد. انتخاب کاسکید شما را به پخش مشترک، کشف مشترک و یک توپولوژی حلقه متعهد می‌کند.
نیاز را پیش از دست زدن به سرور در یک خط بنویسید: کدام سامانه‌ها باید روی یک سیم به نظر برسند و کدام‌ها فقط به یک مسیر نیاز دارند. هر چیزی که پاسخ «یک مسیر» می‌دهد بیرون از کاسکید است. همین یک جمله بیشتر طرح‌هایی را که به سرویس‌های نشانی تکراری می‌رسند جلوگیری می‌کند.
2. دامنه هویتی را که مجاز می‌کند مشخص کنید
اعتبارنامه‌ای که یک سرور را مدیریت می‌کند و هویتی که کاسکید برای اتصال به کار می‌برد رازهای متفاوتی هستند، و آمیختن آن‌ها میانبری رایج با دنباله دراز است. هاب دور به یک ورودی کاربر یا خط‌مشی نیاز دارد که به این کاسکید اجازه اتصال بدهد. همان ورودی مجوز است؛ ورود موفق چیزی درباره آنچه پشت هاب دور است نمی‌گوید.
ثبت کنید کدام هاب آغاز می‌کند، به کدام هاب دور می‌پیوندد و هویت دور به چه چیزی می‌تواند برسد. پیش از تعهد، دو معماری را مقایسه کنید:
| Requirement | Routed path | Cascaded segment |
|---|---|---|
| Broadcast domain | Separate on each side | Shared across the link |
| Address service | One DHCP server per side | Must not run two on one domain |
| Loop risk | Route loops only | Layer-two loops if segments overlap |
اعتبارنامه‌ها و دستورهای بازیابی دو سر را به‌روز نگه دارید. تغییر گذرواژه یا ویرایش خط‌مشی روی هاب دور کاسکید را می‌شکند بدون آنکه کاربران محلی شما را لمس کند، و خرابی معمولاً به شکل پیوندی که بالاست اما خالی است ظاهر می‌شود.
3. بررسی کنید هاب از قبل چه حمل می‌کند
یک هاب به‌ندرت منزوی است. ممکن است از قبل به یک آداپتور فیزیکی پل بزند، از یک مسیریاب مجازی عبور کند یا جای دیگری کاسکید شود، و هر یک از این اتصال‌ها به رابطه تازه آورده می‌شود. به همین دلیل «فقط دو هاب را وصل کردیم» اغلب به پرسشی تبدیل می‌شود که چرا این دو سایت حالا یک قطعه‌اند.
دو هابی که به یک قطعه فیزیکی پل زده و سپس به هم کاسکید شده‌اند یک حلقه می‌سازند. درخت پوشا اضافه کنید یا نسازید. همان آزمون برای هابی صدق می‌کند که از قبل از راه کاسکیدی دیگر به هدف می‌رسد: پیوند دوم ظرفیت اضافه نمی‌کند، مسیر اضافه می‌کند.
پیوندی اضافه نکنید چون یک مسیر کم است؛ مسیر را درست کنید. نخست توپولوژی را روی کاغذ بکشید، با هر پل و کاسکید، چون نمودار دو دقیقه وقت می‌گیرد و بیشتر حلقه‌ها را پیش از پدید آمدن می‌گیرد.
4. پیش از پیوستن، نشانی‌دهی را سامان دهید
قطعه‌های پیوسته زیرشبکه‌های تکراری می‌آورند، و سرورهای DHCP تکراری نشانه کلاسیک‌اند: کلاینت‌ها اجاره را از هر سروری که اول پاسخ دهد می‌گیرند، پس رفتار تصادفی به نظر می‌رسد و میان راه‌اندازی‌های مجدد جابه‌جا می‌شود. از پیش تصمیم بگیرید کدام سو مالک تخصیص نشانی است و به قطعه دور محدوده‌ای بدهید که با هیچ چیز محلی هم‌پوشانی نداشته باشد. سرویس DHCP دیگر را پیش از آنکه کاسکید آنلاین شود خاموش کنید، نه پس از نخستین شکایت.
DNS پرسشی جداست. کاسکید فریم حمل می‌کند؛ حل‌کننده‌ها را پیکربندی نمی‌کند، و نامی که در سوی محلی حل می‌شود ممکن است از راه پیوند حل نشود. جست‌وجو را جدا از مسیر IP بیازمایید، چون ping کارکننده تنها یکی از دو را اثبات می‌کند.
5. با یک منبع واقعی اثباتش کنید
یک سرویس مجاز در قطعه دور موردنظر انتخاب کنید و تأیید کنید پاسخ از راه کاسکید برمی‌گردد. سپس برای حل نام تکرار کنید. اگر هدف به کشف از راه پخش تکیه دارد، در پیوند پل‌شده رفتار متفاوتی نسبت به یک سیم انتظار داشته باشید و برای آن برنامه‌ریزی کنید نه اینکه به‌عنوان نقص ثبتش کنید.
در پایان توپولوژی را بنویسید: کدام هاب کجا کاسکید می‌شود، کدام هویت مجازش می‌کند، کدام قطعه‌ها پل شده‌اند و مالک تخصیص نشانی در هر کدام کیست. همین یادداشت به نفر بعدی اجازه می‌دهد خط‌مشی را تغییر دهد بدون آنکه قطعه‌ای را که نمی‌دانست وجود دارد از کار بیندازد.