یک سرور TAP یا چند سرور؟ کلاینت‌های OpenVPN روی یک پل

چند کلاینت TAP به یک فرآیند سرور، یک درگاه UDP و یک دستگاه TAP روی میزبان برای هرکدام نیاز ندارند. یک سرور OpenVPN در حالت اترنت می‌تواند کلاینت‌های معتبر بسیاری را بپذیرد و آن‌ها را به یک پل واحد متصل کند، و این روش مستند برای گسترش یک بخش لایهٔ 2 است. طراحی تک‌فرآیندی همان چیزی است که دفترچه راهنما مستند می‌کند و معمولاً پیش‌فرض درست است.

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

دو معماری، نه دو تنظیم

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

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

پس مقایسه دربارهٔ این است که کلاینت‌ها باید به چه چیزی برسند، نه دربارهٔ کارایی. نخست لایه را انتخاب کنید، سپس تصمیم بگیرید چند فرآیند به آن خدمت می‌کند.

یاری‌گر server-bridge چه می‌کند

یاری‌گر server-bridge حالت اترنت چندکلاینتی را پیکربندی می‌کند. شکل استخر آدرس آن دروازه، ماسک شبکه و محدوده‌ای اختصاصی درون زیرشبکهٔ پل‌شده را می‌گیرد، مثلاً دروازه‌ای روی 192.168.50.1 با استخری از 192.168.50.160 تا 192.168.50.199.

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

شکلی با پروکسی DHCP برای استقرارهایی وجود دارد که سروری بیرونی آدرس‌ها را می‌دهد. پیش‌نیازهای خودش را دارد، و آمیختن دو شکل دقیقاً همان تعارضی را می‌سازد که مستندات هشدار می‌دهد. برای زیرشبکهٔ پل‌شده یک تخصیص‌دهنده انتخاب کنید.

جداسازی از تعداد فرآیندها نمی‌آید

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

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

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

چه زمانی چند فرآیند هنوز درست است

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

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

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

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