زون‌های Shorewall برای دو مسیر بستهٔ OpenVPN
حمل‌ونقل رمزگذاری‌شدهٔ OpenVPN را از ترافیک رمزگشایی‌شدهٔ کلاینت جدا کنید، به تونل زون اختصاصی بدهید و فقط همان یک سرویسی را مجاز کنید که کلاینت نیاز دارد.
دو جریان بسته از یک دروازهٔ Shorewall می‌گذرند که OpenVPN را پایان می‌دهد، و فقط یکی از آن‌ها رمزگذاری شده است. اولی انتقال کلاینت به شنوندهٔ VPN روی رابط روبه‌اینترنت است. دومی درخواست رمزگشایی‌شده‌ای است که از رابط تونل خارج می‌شود و به یک سرور اداری یا سرویسی روی دروازه می‌رود. پیش از ویرایش سیاست هر دو را ترسیم کنید، زیرا قاعده‌ای که اولی را برآورده می‌کند هیچ کاری برای دومی نمی‌کند.
پیش از ویرایش سیاست دو جریان را ترسیم کنید
جریان‌ها را به‌صورت ردیف‌هایی با مبدأ، مقصد، پروتکل و پورت بنویسید. در مسیر بیرونی، مبدأ نشانی عمومی کلاینت و مقصد پورت شنوندهٔ دروازه است؛ Shorewall آن را ترافیک اینترنت به دیوار آتش می‌داند. در مسیر درونی، مبدأ محدودهٔ نشانی تونل و مقصد سرویس تأییدشده است. دو ردیف حتی وقتی یک مدیر هر دو را نگه می‌دارد صاحبان متفاوتی دارند.
| Flow | Zone relationship | What to constrain |
|---|---|---|
| Encrypted OpenVPN transport | Internet to the firewall host | The listener's actual protocol and port |
| Decrypted request to a LAN service | VPN clients to the LAN zone | One approved server and service |
| Decrypted request to the gateway | VPN clients to the firewall host | Only the local services required |
| Request to another VPN client | VPN clients to VPN clients | Denied unless deliberately required |
ردیف را فقط وقتی اضافه کنید که درخواست روی خود دروازه پایان می‌یابد، مانند دسترسی به حل‌کننده یا مدیریت. سرویس روی میزبان از سیاست ورودی میزبان پیروی می‌کند، نه از مسیر ارسال‌شده. آمیختن این دو همان چیزی است که یک قاعدهٔ تنگ تونل را به افشای یک رابط مدیریت می‌کشاند.
زون تونل و دامنهٔ رابط را تعیین کنید
زون مسافر در /etc/shorewall/zones اعلام می‌شود، رابط تونل در /etc/shorewall/interfaces متصل می‌شود و اتصال بیرونی در /etc/shorewall/tunnels توصیف می‌شود. با نحو نسخهٔ نصب‌شده هم‌خوان شوید، زیرا ترتیب ستون‌ها و نام گزینه‌ها میان نسخه‌های اصلی تغییر کرده است. پورت نمونهٔ راهنما دلیلی برای مجاز دانستن پورتی متفاوت از پورتی نیست که سرویس‌دهنده واقعاً روی آن گوش می‌دهد. TCP و UDP فقط به‌خاطر یکسان بودن اعداد قابل تبادل نیستند.
راهنما رابط‌ها را با tun+ گروه‌بندی می‌کند. روی میزبانی با بیش از یک تونل، آن نویسهٔ عام می‌تواند یک VPN دوم با سطح اعتماد متفاوت را در همان زون قرار دهد. دامنه را در برابر رابط‌هایی که واقعاً وجود دارند بازبینی کنید و نام‌گذاری را زیر چرخهٔ عمر مدیر اتصال نگه دارید، نه اینکه نام رابط‌ها را دستی ویرایش کنید.
راهنمای تاریخی نمونه‌های پیکربندی OpenVPN بسیار قدیمی‌تری دارد و توصیه‌های رمزنگاری آن را نباید در یک استقرار کنونی کپی کرد. در عوض الگوی زون و جریان را وام بگیرید. مبنای رمزنگاری را از سیاست نگه‌داری‌شدهٔ OpenVPN روی دروازه بگیرید.
فقط مسیری را مجاز کنید که طبقه‌بندی کرده‌اید
پذیرش گسترده از زون VPN به LAN یک طرح آغازین است، نه سیاستی تمام‌شده. مبدأ مجاز کلاینت، نشانی واقعی سرویس، پروتکل و پورت را بنویسید. سپس قاعده‌های بالای آن و پیش‌فرض زون را بخوانید، زیرا افزودنی تنگ مجوز گسترده‌ای را که از پیش مطابقت دارد لغو نمی‌کند. ترافیک به میزبان دروازه رابطه‌ای جدا از ترافیک ارسال‌شده از طریق آن است.
ترافیک میان کلاینت‌ها تصمیم خودش را می‌خواهد. client-to-client در OpenVPN و routeback در Shorewall هر دو بر اینکه کلاینت‌ها به هم برسند اثر می‌گذارند، و هیچ‌کدام را نباید فقط برای کار کردن یک برنامهٔ LAN فعال کرد. پیش از آزمودن مشخص کنید جداسازی کجا اعمال می‌شود.
مسیر پاسخ را در همان طرح نگه دارید. سرویس یا مسیریاب آن باید بداند چگونه ترافیک را به محدودهٔ تونل برگرداند، یا طراحی باید مبدأ را آگاهانه و در دامنهٔ موردنظر ترجمه کند.
اعتبارسنجی کنید، سپس هر دو مسیر را اثبات کنید
پیش از راه‌اندازی مجدد هر چیزی پیکربندی را اعتبارسنجی کنید و یک نشست مدیریتی مستقل را باز نگه دارید در صورت نادرست بودن سیاست جدید.
shorewall checkپس از یک بررسی پاک، پیکربندی را اعمال کنید و آنچه Shorewall بارگذاری کرده را بازخوانی کنید. این خوانش‌ها سیاست در حال اجرا را توصیف می‌کنند، نه آنچه یک فایل به نظر می‌رسد بگوید.
shorewall show zones
ip route get 192.168.10.20یک درخواست مجاز تازه و یک درخواست آگاهانه ردشده را از همان کلاینت بیازمایید. دست‌دادن موفق OpenVPN فقط تبادل بیرونی را اثبات می‌کند؛ سرویس مجاز و منبع ردشده سیاست درونی موردنظر شما را اثبات می‌کنند. سپس کلاینت را دوباره وصل کنید و تکرار کنید، زیرا نام و نشانی رابط تونل می‌تواند میان نشست‌ها تغییر کند. اگر نتیجه متفاوت بود، دامنهٔ زون را درست کنید نه اینکه قاعده را گسترده‌تر کنید.