کلاینتهای VPN و شبکه محلی: چه زمانی از منطقه جداگانه استفاده کنیم
رابط تونل لازم نیست اعتماد شبکه محلی را به ارث ببرد. بین ورودی و ارسال تصمیم بگیرید، منابع را فهرست کنید و مسیر ردشده را پیش از تغییر مناطق اثبات کنید.
قرار دادن رابط تونل در منطقه شبکه محلی کوتاهترین راه به یک VPN کارآمد است و معمولاً پیشفرض نادرست است. این کار به کلاینت راه دور همان اعتمادی را میدهد که شبکه محلی سیمی دارد، در حالی که وظیفه بهندرت چنین چیزی میخواهد. منطقه جداگانه چند قاعده هزینه دارد و مرز را دیدنی میکند. تصمیم این نیست که آیا مناطق بهتر هستند؛ این است که کدام سه شرط به شبکه شما مربوط میشود.
نام منطقه هیچ چیزی را رمزنگاری نمیکند و کاربری را احراز هویت نمیکند. فقط رابطها را برای مدل سیاست دیوار آتش گروهبندی میکند.
عضویت در منطقه در واقع چه چیزی را کنترل میکند
منطقه رابطها یا ترافیک را در مدل دیوار آتش گروهبندی میکند. سپس تنظیمات ورودی، خروجی و ارسال آن نقشهای متفاوتی را اداره میکند. ورودی ترافیک به خود روتر است؛ ارسال ترافیک از طریق آن به میزبان دیگر است. مستندات منطقههای OpenWrt دقیقاً به همین دلیل ورودی، خروجی و ارسال را تنظیمات جداگانه میداند.
اجازه از منطقه VPN به منطقه شبکه محلی بهطور خودکار اجازه معکوس نیست. قواعد ارسال جهتدار هستند و قاعدهای که ترافیک کلاینت به سرور را مجاز میکند، نشستهای سرور به کلاینت را مجاز نمیکند. کلاینتی که میتواند اتصالی به سرور باز کند، کلاینتی نیست که سرور بتواند اتصال بازگشتی به آن باز کند.
همین تمایز دلیل سودمندی منطقه جداگانه است: میتوانید هر جهت و هر نقش را صریح بیان کنید. جهت را کنار هر قاعده بنویسید.
تصمیم یک: ورودی، ارسال یا هر دو
اگر کلاینتهای راه دور به DNS از روتر نیاز دارند، ورودی را فقط برای همان سرویس مجاز کنید. اگر باید به یک سرور فایل برسند، ارسال به آن مقصد را مجاز کنید. بیشتر طرحهای VPN به هر دو نیاز دارند، اما برای سرویسهای متفاوت.
دسترسی گسترده ورودی به همه سرویسهای محلی تقریباً هرگز لازم نیست. مدیریت روتر را تصمیمی جدا از دسترسی برنامهها بدانید. اگر روتر فقط باید به DNS پاسخ دهد، همان اجازه واحد را بنویسید و بقیه را بسته بگذارید.
تصمیم دو: کلاینتهای راه دور به چه منابعی نیاز دارند
پیش از نوشتن قواعد، محدودههای کلاینت، مقصدها و سرویسهایی را که VPN باید فراهم کند فهرست کنید. فهرست مقصد از برچسب اعتماد سودمندتر است، چون از مهاجرت دیوار آتش جان سالم به در میبرد.
رابطهای مدیریت را از دسترسی معمول برنامهها جدا نگه دارید. کلاینت راه دوری که به یک ویکی میرسد، به همین دلیل به صفحه مدیریت روتر یا کنسول هایپروایزر نیاز ندارد.
اگر مقصد مجاز بتواند جلوتر ارسال کند، مرز منطقه همان دیوار آتش است، نه آنچه مقصد بعد از آن انجام میدهد.
تصمیم سه: چگونه مرز را اثبات خواهید کرد
پس از هر تغییر، یک جریان مجاز و یک جریان عمداً ردشده را آزمایش کنید. اثبات اینکه یک وبسایت بارگذاری میشود، اجازه گسترده ناخواستهای را آشکار نمیکند. از محدوده نشانی کلاینت VPN آزمایش کنید، نه از شبکه محلی، و جهتی را که انتظار شکست آن را دارید نیز بگنجانید. هر دو نتیجه را کنار قاعده ثبت کنید.
پیش از تغییر سیاست منطقه راه دور، دسترسی بازیابی دروازه را حفظ کنید. از پیکربندی مدیریتشده پایدار بهجای ویرایشهای زمان اجرا استفاده کنید، وگرنه راهاندازی مجدد بعدی اعتماد قدیمی را بازمیگرداند. یک نسخه از پیکربندی قبلی که بیرون از دستگاه نگه داشته شود، ارزانترین بازگردانیای است که خواهید داشت.
وقتی شبکه بزرگ میشود، عضویت و هدف قواعد را مستند کنید. رابط تازهوصلشده نباید فقط به این دلیل که کسی نام منطقه مناسبی به آن داده است، امتیازها را به ارث ببرد.