آیا دو سایت برای VPN سایت به شناسه‌های VLAN یکسان نیاز دارند؟
شناسه‌های VLAN یکسان نمی‌توانند یک VPN سایت مسیریابی‌شده را درست کنند: تونل پیشوندهای IP را حمل می‌کند، پس طرح آدرس و انتخابگرها دسترسی‌پذیری را تعیین می‌کنند، نه برچسب‌های سوئیچ.
یکسان بودن شماره‌های VLAN در دو دفتر به نظر می‌رسد باید به یک تونل سایت به سایت کمک کند، و هیچ چیز را در آنچه تونل حمل می‌کند تغییر نمی‌دهد. یک شناسه VLAN یک دامنه پخش Ethernet را درون یک ساختمان برچسب می‌زند؛ تونل بسته‌های IP را میان دروازه‌ها ارسال می‌کند. دو سایت می‌توانند شماره‌گذاری VLAN کاملاً متفاوتی داشته باشند و همچنان به سمت یکدیگر مسیریابی کنند، و دو سایت می‌توانند شماره‌گذاری VLAN یکسانی داشته باشند و همچنان نتوانند به یکدیگر برسند. متغیری که دسترسی‌پذیری را تعیین می‌کند طرح آدرس است.
افسانه: شناسه‌های VLAN یکسان در دو انتها
این باور از جای معقولی می‌آید. درون یک ساختمان، دو پورت در یک VLAN می‌توانند با هم صحبت کنند و دو پورت در VLANهای متفاوت نمی‌توانند، پس شماره VLAN چیزی به نظر می‌رسد که اتصال می‌دهد. در سراسر یک تونل مسیریابی‌شده هیچ بخش Ethernet مشترکی وجود ندارد که برچسب آن را توصیف کند، و دروازه‌ها هرگز برچسب‌های VLAN را مبادله نمی‌کنند.
آنچه تونل به آن نیاز دارد یک جفت محدوده آدرس بدون همپوشانی و سیاستی است که ترافیک میان آن‌ها را مجاز می‌کند. VLAN را در هر دفتری تغییر دهید و تونل به کار خود ادامه می‌دهد، زیرا هیچ چیز در پیکربندی تونل به آن ارجاع نداده بود. این همان آزمونی است که بحث را حل می‌کند: یک VLAN را دوباره شماره‌گذاری کنید، آدرس‌ها را دست‌نخورده بگذارید و ببینید آیا تونل برپا می‌ماند.
آزمون معکوس به همان اندازه آموزنده است. به هر دو دفتر یک زیرشبکه بدهید و هیچ مقدار یکسان بودن شماره‌های VLAN یک آدرس را بدون ابهام نخواهد کرد.
تونل در واقع چه چیزی حمل می‌کند
IPsec بسته‌های IP را بر پایه سیاستی که با آدرس‌ها، پروتکل‌ها و پورت‌ها بیان می‌شود محافظت می‌کند. معماری IPsec آن انتخابگرها را در لایه IP توصیف می‌کند، که چند لایه بالاتر از هر چیزی است که یک برچسب سوئیچ توصیف می‌کند. وقتی بسته‌ای وارد تونل می‌شود، از قبل VLAN را ترک کرده است؛ برچسب را سوئیچ محلی مصرف کرده است.
طرح‌های مبتنی بر سیاست و مبتنی بر مسیر در نحوه انتخاب تونل تفاوت دارند، نه در آنچه می‌توانند حمل کنند. یک همتای مبتنی بر سیاست انتخابگرهای ترافیک را تطبیق می‌دهد و بسته‌های منطبق را به تونل می‌فرستد. یک همتای مبتنی بر مسیر ترافیک را در یک واسط تونل مسیریابی می‌کند و تصمیم را به جدول مسیریابی می‌سپارد. هر دو هنوز بر سر گستره حفاظت مذاکره می‌کنند، پس مسیری که به تونل اشاره می‌کند آنچه همتاها برای حفاظت توافق کرده‌اند را گسترش نمی‌دهد.
این تمایز یک ناکامی نیمه‌کاره رایج را توضیح می‌دهد: مسیر وجود دارد، بسته‌ها وارد تونل می‌شوند و طرف دور آن‌ها را دور می‌ریزد زیرا انتخابگرهای مذاکره‌شده هرگز آن پیشوند را در بر نمی‌گرفتند. خواندن سیاست‌های نصب‌شده نشان می‌دهد کدام گستره واقعاً به اجرا درآمده است.
ip xfrm policy
ip route show
swanctl --list-sasهمپوشانی که واقعاً می‌شکند
دو دفتر با زیرشبکه‌های متفاوت به‌طور پاک از یک تونل مسیریابی می‌شوند و شماره‌های VLAN آن‌ها بی‌اهمیت است. دو دفتر با زیرشبکه یکسان این‌گونه نیستند، زیرا درخواست یک آدرس مشخص دو معنای ممکن دارد و جدول مسیریابی فقط می‌تواند یکی را انتخاب کند. شماره‌گذاری دوباره یک سایت راه‌حل پاک است و وقتی تغییرات DNS و دیوار آتش شمرده شود معمولاً از گزینه‌های دیگر ارزان‌تر است.
| Office | Local VLAN | Subnet | Result |
|---|---|---|---|
| A | 40 | 10.31.0.0/24 | Routes normally |
| B | 55 | 10.62.0.0/24 | Routes normally |
| B after renumber | 40 | 10.31.0.0/24 | Ambiguous, tunnel cannot help |
وقتی شماره‌گذاری دوباره ممکن نیست، یک طرح ترجمه عمدی می‌تواند دیدگاه‌های آدرس متفاوتی به هر طرف ارائه دهد. این یعنی نگاشت یک‌به‌یک، انتخابگرهای منطبق، ورودی‌های DNS که دیدگاه ترجمه‌شده را بازتاب می‌دهند و مسیریابی برگشتی که از بازنویسی جان سالم به در می‌برد. این طرحی پشتیبانی‌شده با هزینه عملیاتی واقعی است و آن کاری نیست که تغییر یک شناسه VLAN انجام می‌دهد.
یکسان بودن شماره‌های VLAN در دو انتها گاهی تصادفی از یک الگوی مشترک است و برخورد با آن تصادف به‌عنوان علت یک تونل سالم به تغییر اشتباه می‌انجامد وقتی بعداً چیزی می‌شکند.
یک وظیفه برای هر لایه، مکتوب
سوئیچ محلی تعیین می‌کند کدام پورت‌ها یک دامنه پخش را شریک‌اند و شماره‌گذاری VLAN آن حسابداری محلی است که هیچ سایت دیگری نیاز به دانستنش ندارد. دروازه همتا را احراز هویت می‌کند و گستره حفاظت مذاکره‌شده را اعمال می‌کند. جدول مسیریابی تعیین می‌کند بسته رمزگشایی‌شده بعد کجا برود و سیاست دسترسی تعیین می‌کند آیا آن بسته اصلاً باید مجاز می‌بود یا نه.
جدا نگه داشتن این وظایف همان چیزی است که تغییرات را ایمن می‌کند. شماره‌گذاری دوباره VLAN در یک دفتر به سوئیچ محلی، محدوده DHCP و شاید یک ناحیه دیوار آتش دست می‌زند و به تونل دست نمی‌زند. تغییر پیشوند به انتخابگرهای تونل، مسیرهای دو طرف و سیاست دسترسی دست می‌زند و به برچسب‌های سوئیچ دست نمی‌زند.
مسیرهای برگشت، DNS خصوصی و الزامات هویت برنامه دوباره وظایف جداگانه‌ای هستند و هیچ‌کدام با کپی کردن شماره VLAN از سایت دیگر نمی‌آیند. سند طراحی که پیشوندهای قابل دسترس و سرویس‌های مجاز را فهرست می‌کند از نوسازی سوئیچ جان سالم به در می‌برد؛ سندی که شماره‌های VLAN را فهرست می‌کند نه.
پیش از آنکه فرض کنید برچسبی به تونل می‌رسد، تصویر محلی را با ابزارهای پل تأیید کنید.
bridge vlan show
ip -br addr
ip route get 10.62.0.20وقتی گسترش layer-2 نیاز واقعی است
برخی طرح‌ها واقعاً به رفتار Ethernet میان سایت‌ها نیاز دارند: برنامه‌ای قدیمی که به کشف از طریق پخش متکی است، مهاجرتی که باید آدرسی را هنگام جابه‌جایی ماشین نگه دارد، یا پروتکلی که فرض‌های layer-2 را در خود دارد. این موارد به یک لایه رویی یا سرویس پل نیاز دارند که فریم‌ها را حمل کند و آنگاه عضویت VLAN، جلوگیری از حلقه و رسیدگی به خرابی موضوعاتی سرتاسری می‌شوند.
این دامنه خرابی بسیار بزرگ‌تری است و باید انتخابی عمدی باشد نه نتیجه تصادفی تلاش برای راه‌اندازی اشتراک فایل. یک سرور فایل، پایگاه داده یا برنامه وب معمولی به مسیر IP مجاز نیاز دارد و بدون یک دامنه پخش کشیده‌شده در زیر آن شادتر خواهد بود.
قرارداد VPN را به‌صورت پیشوندهای قابل دسترس به‌علاوه سرویس‌های مجاز بنویسید و برچسب VLAN را تنها جایی ثبت کنید که عملیات محلی به آن نیاز دارد. آنگاه هر دفتر می‌تواند سوئیچینگ خود را دوباره شماره‌گذاری کند بدون آنکه هر تغییر را به بازطراحی تونل تبدیل کند.