چگونه دسترسی بین دو دفتر متصل با VPN را محدود کنیم

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

به همین ترتیب کار کنید و مسیر تونل را گسترده نکنید تا زمانی که گام‌های سیاست زیر بگذرند.

پیش از دست زدن به دروازه، ماتریس را بنویسید

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

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

جایی که بسته‌ها رمزگشایی می‌شوند اعمال کنید

قواعدی که IKE و ESP را مجاز می‌کنند فقط تونل بیرونی را می‌سازند. ترافیک درونی آشکارا روی واسط تونل می‌رسد و همان‌جاست که فهرست مجاز جای دارد: زنجیره ارسال روی دستگاه رمزگشا، حذف پیش‌فرض، یک قاعده به ازای هر ردیف ماتریس. در دروازه‌های Linux این یعنی ارسال فعال و قواعد فیلتر روی دستگاه تونل، نه روی پیوند فیزیکی، چنان‌که راهنمای ارسال strongSwan توضیح می‌دهد.

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

iptables -A FORWARD -i tun0 -s 10.20.0.0/24 -d 10.10.5.10 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i tun0 -j DROP

NAT و زیرشبکه‌های هم‌پوشان قواعد را تغییر می‌دهند

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

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

یک رد را اثبات کنید، نه فقط یک موفقیت

آزمودن تنها برنامه مجاز چیز کمی را اثبات می‌کند، زیرا یک قاعده سهل‌گیرانه در جایی بالادست همان نتیجه را می‌دهد.

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

فهرست را زنده نگه دارید

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

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