NAT VPN در before.rules یو‌اف‌دبلیو کجا قرار می‌گیرد و چگونه آن را آزمایش کنیم

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

دستور شل یک فایل بازگردانی نیست

خطی که با iptables -t nat آغاز می‌شود دستوری برای باینری iptables است، در حالی که فایلی که UFW می‌خواند توصیف یک مجموعه قواعد کامل است. تفاوت ظاهری نیست: قالب بازگردانی باید بداند در کدام جدول است، کدام زنجیره‌ها وجود دارند و جدول کجا پایان می‌یابد. دستوری که در آن سند چسبانده شود یا خطای نحوی است یا، بدتر، قاعده‌ای متصل به جدول اشتباه. چارچوب این فایل‌ها را دقیقاً از طریق ابزارهای بازگردانی بارگذاری می‌کند چون اعلانی‌اند نه ترتیبی.

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

قطعه را درون بخش جدول موجود بگذارید

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

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT

مخزن و رابط بالا جای‌نگهدارهایی برای مقادیر شما هستند؛ ساختار بخشی است که ارزش کپی کردن دارد. اگر فایل از قبل بخش *nat دارد، قاعده را درون همان بخش اضافه کنید نه اینکه بخش دومی باز کنید، چون قالب برای هر جدول یک COMMIT انتظار دارد و دو بخش برای یک جدول تعمیری است که در انتظار وقوع است. تعریف‌های زنجیره توزیع را دست‌نخورده نگه دارید، از جمله هر تعریفی که فروشنده برای یکپارچه‌سازی خود افزوده است. راهنمای چارچوب UFW فایل‌های before، user و after را همراه با الزام یک COMMIT منطبق مستند می‌کند.

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

نامزد را بدون اعمال آزمایش کنید

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

sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"

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

ابزاری را انتخاب کنید که با بک‌اند نصب‌شده و خانواده نشانی مطابقت دارد. میزبانی که بک‌اند nft را از طریق لایه سازگاری اجرا می‌کند به فرمان متناظر نیاز دارد، و قواعد IPv6 در فایلی کاملاً دیگر زندگی می‌کنند.

ارسال به جلو، NAT و سیاست دسترسی را جدا نگه دارید

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

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD

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

بارگذاری مجدد، رد و از دست رفتن VPN را بررسی کنید

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

sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

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

NAT در IPv4 چیزی درباره IPv6 نمی‌گوید، پس پوشش مورد نظر برای هر دو خانواده را در همان یادداشتِ قاعده ذکر کنید. هدف یک سیاست مدیریت‌شده منسجم است، و قطعه‌ای که تصادفاً تجزیه شد شاهدی بر آن نیست.