دو گروه مشتری، یک سرور: کجا سیاست اعمال شود
زیرشبکه‌ها گروه‌ها را برچسب می‌زنند و آن‌ها را جدا نمی‌کنند. تصمیم بگیرید کدام مسیر ارسال مالک قاعده است، سپس ماتریسی را بنویسید که پیاده‌سازی باید اعمال کند.
قرار دادن دو گروه مشتری روی زیرشبکه‌های مختلف شبیه جداسازی به نظر می‌رسد و چنین نیست. نشانی‌ها توصیف می‌کنند بسته ظاهراً از کجا می‌آید، در حالی که اجازه تصمیمی است که هر چیزی که آن را ارسال می‌کند می‌گیرد. این پرسش را پیکربندی پاسخ می‌دهد نه ماسک، پس پیش از نوشتن هر قاعده تصمیم بگیرید کدام مؤلفه ترافیک همتایان را ارسال می‌کند.
زیرشبکه یک برچسب است، نه قاعده
اختصاص یک استخر به هر گروه به شما نشانی‌های خوانا می‌دهد و هیچ چیز دیگر. مشتری‌ای که مسیر اضافی را می‌پذیرد دسترسی‌پذیری به دست آورده، و دسترسی‌پذیری مجوز نیست. اجازه گفتگو در تصمیم ارسال قرار دارد که بسته به نحوه پیکربندی سرور ممکن است در دیمن یا در هسته باشد.
مالکیت نشانی چیزی است که پیشوند را به‌عنوان گزینشگر گروه قابل استفاده می‌کند. هر هویت احرازهویشده باید به نشانی یا محدوده‌ای قابل پیش‌بینی نگاشت شود، و این نگاشت به‌محض اینکه چند دستگاه یک اعتبارنامه و یک تخصیص را شریک شوند از کار می‌افتد. پیش از تکیه بر پیشوند مبدأ، هویت و هم‌روندی را حل کنید، زیرا سیاستی که حدس می‌زند کدام ماشین تماس می‌گیرد در بدترین لحظه به ماشین اشتباه مجوز می‌دهد.
مسیری را انتخاب کنید که ترافیک همتایان را حمل می‌کند
وقتی دیمن بسته‌های همتایان را درون فرایند خود ارسال می‌کند، آن بسته‌ها هرگز به قلاب ارسال میزبان نمی‌رسند، بنابراین قاعده هسته نمی‌تواند آن‌ها را ببیند. آن ارسال داخلی را غیرفعال کنید و هسته نقطه ارسال می‌شود، جایی که قواعد ارسال عادی اعمال می‌شوند.
# peer forwarding inside the daemon: enforce with per-group policy instead of FORWARD rules
client-to-client
# kernel forwarding path: remove the line above, then filter in the forward chainکانال‌های داده بارگذاری‌شده و سرورهای مدیریت‌شده توسط محصول مدل‌های اعمال خود را منتشر می‌کنند، پس تأیید کنید کدام‌یک را اجرا می‌کنید به‌جای اینکه رفتار جامعه را فرض کنید. شکستی که ارزش پرهیز دارد قاعده‌ای است که در بازبینی درست به نظر می‌رسد و هرگز در زمان اجرا پرسیده نمی‌شود.
پیش از نوشتن قواعد، ماتریس را بنویسید
ماتریس کوتاه از مجموعه قواعد آسان‌تر بازبینی می‌شود و همان قراردادی است که پیاده‌سازی باید برآورده کند: همتایان یک گروه مجاز، همتایان میان گروه‌ها ممنوع، هر دو گروه مجاز به یک سرویس مشترک نام‌دار، هر چیز دیگر ممنوع. این چهار خط را پیش از باز کردن ویرایشگر دیوار آتش بنویسید. بازبینی‌کننده‌ای که نحو قواعد را نمی‌خواند باز هم می‌تواند ماتریس را بررسی کند. آنگاه پیاده‌سازی فقط باید با خطوط مطابقت داشته باشد.
| Source | Destination | Decision |
|---|---|---|
| Group A address | Another Group A address | Allow |
| Group A address | A Group B address | Deny |
| Either group | The shared internal service | Allow |
| Either group | Anything not listed | Deny |
هنگام نوشتن، سه رده مقصد را جدا نگه دارید. سرویس روی میزبان VPN ورودی محلی است، مشتری دیگر ترانزیت همتایان است، و ماشین پشت دروازه مسیر ارسال متفاوتی است. یک قاعده سخاوتمندانه می‌تواند هر سه را تصادفی اعطا کند، و این‌گونه سیاست گروهی به شبکه‌ای مسطح با گام‌های اضافی تبدیل می‌شود. رده را کنار هر ردیف بنویسید تا قصد پس از ویرایش بعدی زنده بماند.
قواعد را جایی بگذارید که دوام بیاورند
تصمیم‌ها را در همان جایی اضافه کنید که بقیه دیوار آتش نگهداری می‌شود، پیش از هر قاعده مجازکننده‌ای که در غیر این صورت آن‌ها را می‌بلعد. ترتیب قواعد بخشی از سیاست است، و قاعده درستی که پس از یک پذیرش گسترده قرار گیرد هیچ چیز را اعمال نمی‌کند. شماره قواعد را پیش و پس از تغییر یادداشت کنید. سیاستی که در ویرایشگر وجود دارد اما در مجموعه قواعد در حال اجرا نیست یک نقشه است، نه یک کنترل.
تصمیم بگیرید وقتی سیاست تغییر می‌کند با جریان‌هایی که از قبل وجود دارند چه می‌شود، زیرا نشستی که پیش از تغییر باز شده ممکن است پس از آن ادامه یابد. اگر عضو خارج‌شده باید فوراً دسترسی را از دست بدهد، مجموعه قواعد به راهی برای پایان دادن به آن وضعیت نیاز دارد به‌جای انتظار برای بسته شدن خودبه‌خود اتصال.
قواعد را از طریق سازوکاری که مالک بقیه دیوار آتش است پایدار کنید و ماتریس را کنار آن‌ها ثبت کنید. سیاست ثبت‌نشده در حادثه بعدی از حافظه بازاستخراج می‌شود، معمولاً به دست کسی که عجله دارد.
از هر دو سو اثباتش کنید
دسترسی‌پذیری درون یک گروه، شکست میان گروه‌ها و سرویس مشترک را از یک مشتری در هر گروه آزمایش کنید. یک آزمایش از یک مشتری نیمی از ماتریس را اثبات می‌کند، و نیمی که جا می‌اندازد معمولاً همان نیم اشتباه است. جهت رد را دو بار تکرار کنید، زیرا نشست کاشه‌شده می‌تواند خطای اعمال را پنهان کند. ثبت کنید کدام جفت را آزمایش کردید تا نفر بعدی آن را تکرار نکند.
اگر تونل IPv6 را حمل می‌کند همان بررسی را روی آن تکرار کنید، و احراز هویت معمول برنامه‌ها را سر جایش نگه دارید. پیشوند مبدأ حساب نیست، پس عبور از سیاست شبکه به این معنا نیست که سرویس باید به فراخواننده اعتماد کند.