ufw allow 443 برای سرویسی پشت VPN هیچ کاری نکرد

ping از یک کارخواه VPN موفق می‌شود، سرویس TCP به پایان زمان می‌رسد و ufw allow 443/tcp هیچ چیز را تغییر نمی‌دهد. وقتی برنامه روی میزبان پشت دروازه اجرا می‌شود نه روی خود دروازه، آن اجازه برای مسیر ترافیک اشتباه نوشته شده است. بسته به دیوار آتش نشانه‌گذاری نشده و به هیچ فرایند محلی تحویل داده نمی‌شود، بنابراین قواعد ورودی هرگز آن را نمی‌بینند. راه‌حل یک قاعدهٔ مسیر است که جریان هدایت‌شده را هدف می‌گیرد و شواهد آن از پیش در گزارش موجود است.

تصمیم بگیرید که مقصد محلی است یا هدایت‌شده

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

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

پیش از افزودن هر قاعده‌ای بلوک را بخوانید

یک تلاش اتصال مجاز را بازتولید کنید و مبدأ، مقصد، پروتکل و درگاه مقصد آن را همان‌گونه که دروازه ثبت کرده است بردارید. این چهار مقدار را با مدخل گزارش و با مکان واقعی سرویس مقایسه کنید. ping موفق قبلی فقط اثبات می‌کند که تبادل خودش مجاز بوده است و دیوار آتش می‌تواند یک TCP SYN به سوی برنامه را کاملاً متفاوت رفتار کند.

sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered

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

تنگ‌ترین قاعدهٔ مسیری را که می‌گنجد بنویسید

در این نمونه کارخواهان از 172.20.8.0/24 روی tun0 می‌رسند، سرویس روی 10.30.0.15 در درگاه 8443 گوش می‌دهد و دروازه از ens5 خارج می‌شود. این مقادیر طوری انتخاب شده‌اند که هیچ شبیه پیش‌فرض VPC ابری 10.0.0.0/16 یا شبکهٔ خانگی 192.168.0.0/16 نباشند و 8443 نمونه را از شنوندهٔ 443 خود دروازه دور نگه می‌دارد.

sudo ufw --dry-run route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443

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

مسیر بازگشت را حالتمند نگه دارید

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

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

sudo ufw route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
sudo ufw status numbered

بررسی کنید UFW چه چیزی را به جای شما نمی‌تواند اجرا کند

یک قاعدهٔ درست هنوز به هدایت هسته و مسیری که به سرویس برسد نیاز دارد. پیش از آنکه دیوار آتش را بار دوم سرزنش کنید هر دو را تأیید کنید.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

سپس بیرون از میزبان را ببینید. روی یک نمونهٔ ابری، سیاست UFW مهمان جای گروه‌های امنیتی، ACLهای زیرشبکه یا پیکربندی هدایت خود ارائه‌دهنده را نمی‌گیرد، بنابراین یک منع محلی شواهدی درباره یک لایه است نه اثبات اینکه هر لایهٔ دیگر سرویس را مجاز می‌داند.

با آزمودن یک اتصال تازه و دیوار آتش فعال به پایان برسید، از یک مبدأ مجاز و از یک مبدأ بی‌ربط. غیرفعال کردن UFW نشانه را برمی‌دارد و شواهد را در همان دستور نابود می‌کند، از این رو باید آخرین آزمایش باشد نه نخستین.