VPN مسیریابی‌شده یا LAN پل‌شده برای پیوند میان شعبه و آزمایشگاه

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

دو راه برای اتصال، یک بده‌بستان روشن

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

پیوند پل‌شده یک دامنه لایه 2 را روی هر دو سایت گسترش می‌دهد. پروتکل‌های کشف کار می‌کنند، دستگاه‌ها به‌طور خودکار ظاهر می‌شوند و هر پخش، هر درخواست ARP و هر بسته multicast اکنون نامزد عبور از تونل است، یعنی حجم زیادی ترافیک که پروتکل‌هایی حمل می‌کنند که برای یک قطعه محلی ساخته شده‌اند نه برای WAN با MTU متفاوت و زمان رفت‌وبرگشت متغیر.

آنچه مسیریابی به شما می‌دهد

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

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

sysctl -w net.ipv4.ip_forward=1
ip route add 10.20.0.0/24 via 192.168.50.1
ip route get 10.20.0.40

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

پل زدن چه هزینه‌ای دارد

پل زدن باید قاب‌های لایه 2 را از تونل عبور دهد، که یعنی کپسوله‌سازی مانند GRE یا VXLAN روی IPsec به‌جای یک تونل ساده مبتنی بر سیاست. وقتی این وجود داشته باشد، دو سایت یک دامنه خرابی را شریک می‌شوند. Spanning tree تونل را به‌عنوان یک پیوند می‌بیند، ترافیک پخش پهنای باند تونل را مصرف می‌کند و هر دستگاهی که قطعه‌ای با تأخیر کم را فرض کند به گونه‌هایی بدرفتاری می‌کند که نسبت دادنش از هر دو سر سخت است.

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

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

نام‌ها بدون پخش

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

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

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

طراحی مسیریابی‌شده را آزمون‌پذیر کنید

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

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

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