وقتی کلاینت دسترسی از راه دور باید نقش دروازه شعبه را ایفا کند
فرستادن یک زیرشبکه شعبه از طریق کلاینت دسترسی از راه دور یک قرارداد مسیریابی است. تأیید کنید که محصول از این نقش پشتیبانی می‌کند، سپس آدرس‌دهی و بازیابی را بر عهده بگیرید.
لپ‌تاپی که به VPN متصل است می‌تواند به ستاد مرکزی برسد. چاپگر و سرور فایل روی همان میز نمی‌توانند، چون هیچ چیز بسته‌های آن‌ها را به آن تونل نمی‌فرستد یا پاسخ‌ها را برنمی‌گرداند. تبدیل کلاینت به دروازه شعبه تصمیمی درباره مسیریابی و مالکیت است پیش از آنکه تصمیمی درباره پیکربندی باشد. نام پروتکل روی جعبه پاسخ نمی‌دهد که آیا آن نقش پشتیبانی می‌شود.
آنچه برچسب پروتکل به شما نمی‌گوید
OpenVPN طرحی از سایت به سایت را مستند می‌کند که در آن یک اتصال‌دهنده کل یک زیرشبکه را می‌فرستد، و Access Server آن را با نقش دروازه و مسیریابی صریح پیاده می‌کند. محصول دیگری که به‌عنوان SSL VPN بازاریابی می‌شود ممکن است فقط کارکردهای کاربر راه دور را ارائه دهد، بدون هیچ روش پشتیبانی‌شده‌ای برای اعلام شبکه‌ای پشت کلاینت. نسخه هم اهمیت دارد، چون قابلیتی در یک انتشار وعده‌ای درباره انتشار دیگر نیست. پیاده‌سازی‌ای را که واقعاً اجرا می‌کنید بخوانید و دستورالعملی را که برای محصول دیگری نوشته شده نشانه بدانید، نه طرح.
پرسشی که باید نخست روشن شود این است که آیا مالک VPN اصلاً از نقش فرستادن پشتیبانی می‌کند. اگر نه، هیچ مقدار مسیریابی سمت کلاینت آن را پشتیبانی‌شده نمی‌کند.
قرارداد دو طرف دارد: شعبه و ستاد مرکزی
در سمت شعبه، یک میزبان مالک فرستادن، فیلتر کردن و بازیابی است. به مسیری سنجیده از هر دستگاه شعبه نیاز دارد، و اتصال بیرونی VPN باید از طریق شبکه زیرین در دسترس بماند حتی وقتی تونل قطع است. در سمت ستاد مرکزی، کسی باید زیرشبکه شعبه را تعریف کند، هویت دروازه را بپذیرد و منابع مشخصی را مجاز کند. هیچ نیمی تنها کار نمی‌کند.
مسیر بازگشت بخشی است که نادیده گرفته می‌شود. نشانی تونل برای کلاینت زیرشبکه پشت آن را اعلام نمی‌کند، بنابراین مسیریاب‌های ستاد به مسیری نیاز دارند که برای آن پیشوند به دروازه VPN اشاره کند.
در طرح مسیریابی‌شده، متمرکزکننده بسته‌های پیشوند شعبه را می‌فرستد و مسیریابی شبکه محلی بالادست می‌داند پاسخ‌ها را چگونه به آن بازگرداند. در طرح ترجمه‌شده، منبعی که ستاد می‌بیند بازنویسی می‌شود، که می‌تواند نیاز به یک مسیر بازگشت را بردارد اما پنهان می‌کند کدام ماشین شعبه ترافیک را فرستاده است. این موازنه جای‌اش در سند طراحی است، چون گزارش‌های برنامه و قواعد دسترسی با ورود ترجمه هویت هر دستگاه را از دست می‌دهند.
مسیریابی‌شده یا ترجمه‌شده: مسیر بازگشت را آگاهانه انتخاب کنید
مسیریابی‌شده را انتخاب کنید وقتی هویت هر دستگاه و سیاست هر میزبان مهم است و می‌توانید مسیر بازگشت را روی هر مسیریاب مرتبط نگه دارید.
ترجمه‌شده را انتخاب کنید وقتی نمی‌توانید مسیر اضافه کنید اما می‌پذیرید که ستاد یک نشانی مبدأ ببیند. طرح‌های ترکیبی وجود دارند و استدلال درباره‌شان سخت‌تر است، پس بنویسید کدام پیشوندها مسیریابی‌شده و کدام ترجمه‌شده‌اند. سپس انتخاب را با یک ضبط در هر دو سر بررسی کنید نه با اعتماد به وضعیت تونل.
یک بررسی سودمند نامتقارن است: منبعی را از دستگاه شعبه بخواهید، سپس تأیید کنید که پاسخ ستاد را به سمت پیشوند شعبه ترک می‌کند. traceroute -n 10.60.4.20 از یک میزبان در ستاد نشان می‌دهد که آیا این مسیر از دروازه VPN می‌گذرد.
آن را مانند زیرساخت اداره کنید، نه مانند ورود
تصمیم بگیرید دروازه چگونه بدون اینکه کسی وارد شده باشد آغاز می‌شود، احراز هویت می‌کند، به‌روزرسانی می‌شود و بازیابی می‌گردد. تمدید اعتبارنامه‌ها، اعلان‌های چندعاملی، رفتار خواب و اینکه وقتی شعبه دسترسی را از دست می‌دهد چه کسی پاسخ می‌دهد، همه پرسش‌های عملیاتی می‌شوند. چند نفر که یک مسیر شبکه را به اشتراک می‌گذارند نباید امتیازهای شخصی کاربر دروازه را به ارث ببرند، بنابراین مجوزدهی منابع، دامنه ثبت رویداد و سیاست خطا به مالکی نام‌دار نیاز دارند. به اشتراک گذاشتن یک حساب برای پرهیز از ثبت هر دستگاه طراحی نیست.
این چیدمان را با یک دروازه سایت پشتیبانی‌شده در همان الزامات پیش از تعهد مقایسه کنید. استفاده دوباره از یک رایانه رومیزی قدیمی کار نگهداری یا بازیابی را برنمی‌دارد، و قیمت دست‌دوم هزینه عملیاتی را توصیف نمی‌کند.
برنامه‌های شعبه مورد نظر، ترافیک بازگشتشان و یک مقصد ردشده را زیر یک طرح تأییدشده اعتبارسنجی کنید. موفقیت مانند یک سرویس شبکه تحت مالکیت با هویت شعبه نام‌دار و سیاستی صریح است، نه مانند پنجره کلاینتی که می‌گوید متصل.