محدود کردن دروازه OpenVPN به یک شبکه محلی با قواعد UFW

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

نخست توپولوژی و مجوز را بنویسید

نمونه از سرور Community OpenVPN با دستگاه TUN در فضای کاربر به نام tun0، مجموعه مشتریان 10.77.0.0/24 و یک زیرشبکه متصل 192.168.60.0/24 روی lan0 استفاده میکند. ارسال IPv4 از قبل کار میکند و شبکه محلی از قبل مسیر بازگشت به مجموعه دارد، پس هیچ چیز اینجا به ترجمه میان آن دو وابسته نیست.

UFW صاحب دیوار آتش روی این میزبان است و هیچ مجموعه قاعدهای در کانتینر یا جدول جداگانه nftables نمیتواند مسیر پذیرش زودتری نصب کند. میانبُر تخلیه جریان که فیلتر را دور بزند زنجیرههای نگهبان را تزیینی میکند، پس تأیید کنید که هیچکدام فعال نیست. ارسال client-to-client خود OpenVPN را غیرفعال بگذارید، چون ترافیک همتا به همتا که هرگز از فیلتر سیستمعامل عبور نمیکند را نمیتوان با آن محدود کرد. شنونده بیرونی و قواعد مدیریت همانطور میمانند، چون این تغییر ترافیک رمزگشاییشده تونل را اداره میکند نه اینکه دیوار آتش را جایگزین کند.

نگهبانها را پیش از پذیرشهای زودهنگام UFW بگذارید

اجازه مسیر و سپس رد کردن برای یک مرز سخت کافی نیست. قواعد before پیشفرض ترافیک برقرارشده و برخی ICMP را پیش از مراجعه به هر قاعده کاربر میپذیرند، پس جریانی که هفته گذشته مجاز شد میتواند فقط به این دلیل که هنوز وضعیت دارد بیرون از محدودیت مقصد جدید بماند. از فایلهای UFW نسخه پشتیبان بگیرید و پیش از ویرایش یک کنسول خارج از باند باز نگه دارید.

در بخش *filter فایل /etc/ufw/before.rules، دو زنجیره را کنار اعلانهای موجود و پیش از هر خط قاعده اعلان کنید.

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

بیدرنگ پس از اعلانها و پیش از اجازههای ورود و ارسال، به آنها بپرید و تعریف کنید چه چیزی را میپذیرند.

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

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

بخوانید هر نگهبان چه چیزی را میپذیرد و رد میکند

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

بسته همتا به همتا وارد tun0 میشود و از آن خارج میشود، پس پیش از آنکه حتی به بررسی مقصد برسد در آزمون رابط شبکه محلی رد میشود. اتصالهای تازه از شبکه محلی به سمت مشتریان هم در آزمون جهت پاسخ رد میشوند، که مسیر فراخوانی معکوس را بهطور پیشفرض میبندد.

هدف RETURN سیاست عادی UFW را در جریان نگه میدارد. این زنجیرهها فیلتر میکنند و مجوز مسیری که بعداً اضافه میکنید هنوز تعیین میکند بسته بازمانده پذیرفته میشود یا نه. همین جداسازی است که بعداً اجازه میدهد زیرشبکه مجاز را در یک جا تغییر دهید. اگر نگهبانها بستهها را مستقیماً میپذیرفتند، هر قاعده آینده باید دو بار اضافه میشد.

زیرشبکه را مجاز کنید و درهای کناری را ببندید

نخست مجوز مسیر را پیشنمایش کنید، سپس پرچم پیشنمایش را بردارید تا اعمال شود: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. پس از آن ترتیب قواعد کاربر را مرور کنید، چون رد شدن زودتر هنوز بر اجازه دیرتر پیروز میشود. مجوز برای کل زیرشبکه هم شکل نادرستی است وقتی فقط پورت HTTPS یک میزبان باید قابل دسترسی باشد.

توجه کنید کنار گذاشتن ورودی چه میکند: مشتریان تونل به هیچ سرویسی روی خود دروازه نمیرسند، از جمله شنونده DNS که به نشانی شبکه محلی آن بسته شده است. میزبانی DNS در آنجا به یک استثنای آگاهانه پیش از کنار گذاشتن و یک قرارداد مجوز بازنگریشده نیاز دارد. اگر UFW IPv6 را مدیریت میکند، کنار گذاشتنهای متناظر را نیز برای tun0 در before6.rules اضافه کنید، چون فهرست مقصدهای IPv4 هیچ چیزی درباره بستههای IPv6 نمیگوید.

سیاست بارگذاریشده را بررسی کنید، نه پیشنمایش را

بارگذاری مجدد را پیشنمایش کنید، آن را در پنجره نگهداری اعمال کنید و مجموعه قواعد زنده را بخوانید.

sudo ufw --dry-run reload
sudo ufw show raw

تأیید کنید نگهبانهای تونل پیش از اجازههای پیشفرض وضعیت و ICMP ظاهر میشوند. ufw status ساده قواعد before ویرایششده با دست را نشان نمیدهد، و به همین دلیل اپراتورها نتیجه میگیرند قاعدهای نیست در حالی که در واقع بارگذاری شده است. فهرست خام را از بالا به پایین بخوانید نه اینکه دنبال تکهای بگردید. اگر نگهبانها پس از یک اجازه وضعیت ظاهر شوند، مرز آن کاری را که فایل میگوید انجام نمیدهد.

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

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