iptables: بگذارید کلاینت‌های VPN فقط به یک میزبان برسند

دو تیکت پشتیبانی که بی‌ربط به نظر می‌رسند در نهایت یک علت دارند. در اولی، مدیر می‌خواهد سرور فقط اتصال‌های تونل را بپذیرد؛ در دومی، کاربران VPN باید به یک میزبان داخلی برسند و نه بیشتر. هر دو سیاست به FORWARD تعلق دارند و هر دو معمولاً در INPUT امتحان می‌شوند. نتیجه شبیه دیوار آتش است و مثل یک جانگهدار رفتار می‌کند.

کدام زنجیره به پرسش شما پاسخ می‌دهد

بسته‌هایی که کلاینت VPN به میزبانی در LAN یا به سمت اینترنت می‌فرستد، توسط کرنل ارسال می‌شوند و در FORWARD ارزیابی می‌شوند. INPUT و OUTPUT فقط ترافیکی را می‌بینند که روی خود سرور پایان می‌یابد یا از آن آغاز می‌شود. بنابراین رد کردن هر چیزی که از tun0 نمی‌آید، شنونده‌های خود سرور را محافظت می‌کند و نشست SSH شما را هم قطع می‌کند مگر اینکه جریان‌های برقرارشده ابتدا مجاز شوند. این کار چیزی را درباره اینکه کلاینت‌ها کجا می‌توانند بروند تغییر نمی‌دهد.

اول پرسش را نام ببرید: چه کسی می‌تواند به سرور برسد، یا کلاینت‌ها کجا می‌توانند بروند. بیشتر شبکه‌ها به هر دو پاسخ نیاز دارند، در زنجیره‌های متفاوت.

اول وضعیت، سپس مجوز، سپس رد

فهرست مجاز فقط وقتی کار می‌کند که مجوز مشخص بالای رد عمومی بنشیند و ترافیک بازگشتی بالای هر دو مجاز شود. قاعده‌ها را در موقعیت‌های صریح درج کنید و سپس زنجیره را با iptables -S FORWARD چاپ کنید تا ترتیب دیده شود نه فرض.

POOL=10.99.0.0/24
iptables -I FORWARD 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD 2 -s "$POOL" -d 172.31.20.15 -p tcp -m multiport --dports 443,3389 -j ACCEPT
iptables -I FORWARD 3 -s "$POOL" -j REJECT

دو جزئیات تعیین می‌کند که آیا این در برخورد با ترافیک واقعی دوام می‌آورد. بدون قاعده وضعیت، پاسخ‌ها به اتصال‌هایی که همین حالا مجاز کردید، خودشان در برابر رد ارزیابی و دور ریخته می‌شوند. یک قاعده LOG بدون محدودیت می‌تواند بار اول که اسکنی به آن برسد یک پارتیشن کوچک را پر کند، پس پیش از ادامه ثبت، -m limit --limit 10/min را اضافه کنید. REJECT فوراً خطا برمی‌گرداند که هنگام تنظیم فهرست دوستانه‌تر است؛ DROP بی‌صدا دور می‌ریزد، بنابراین هر اشتباه به شکل پایان زمان ظاهر می‌شود. یکی را آگاهانه انتخاب کنید و انتخاب را در سابقه تغییر بنویسید.

ارسال و NAT باید از قبل کار کنند

فیلتر کردن نمی‌تواند اثبات کند مسیری وجود دارد. ابتدا تأیید کنید که کرنل اصلاً ارسال می‌کند و این تنظیم را پایدار کنید نه یک فرمان یکباره پوسته. فیلتر آخرین لایه است، نه اولین.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s "$POOL" -o eth0 -j MASQUERADE

جای ماسکاراد بستگی دارد به اینکه کلاینت‌ها از کجا خارج می‌شوند. اگر از طریق تونل به شبکه‌ای دور می‌روند، قاعده NAT روی همان رابط می‌نشیند نه رابط WAN. سپس شمارنده‌ها را ببینید: اگر شمارنده POSTROUTING هرگز حرکت نمی‌کند در حالی که شمار پذیرش FORWARD بالا می‌رود، مسیر بازگشت خراب است و فیلتر سالم است. این خواندن یک بعدازظهر بازنویسی قاعده‌هایی را که هرگز مشکل نبودند ذخیره می‌کند.

بلوک ایمیل یک زنجیره بالاتر تعلق دارد

مسدود کردن پورت 25 در INPUT فقط ایمیلی را متوقف می‌کند که به سرور VPN آدرس داده شده است. کلاینت به‌خطرافتاده‌ای که از طریق تونل ایمیل می‌فرستد ارسال می‌شود، پس بلوک باید در FORWARD کنار 465 و 587 بنشیند. اگر یک برنامه به‌طور مشروع ایمیل را بازپخش می‌کند، مقصد و پورت آن را بالای آن قاعده بگذارید.

iptables -I FORWARD 2 -s "$POOL" -p tcp -m multiport --dports 25,465,587 -j REJECT

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

آن را بازخوانی کنید و سپس از یک کلاینت اثباتش کنید

مجموعه قاعده را همان‌طور که کرنل گزارش می‌کند بخوانید، نه آن‌طور که اسکریپت شما نوشته است. با iptables -S FORWARD شروع کنید، سپس جدول NAT با iptables -t nat -L POSTROUTING -n -v، سپس ورودی conntrack برای جریانی که بررسی می‌کنید. تا وقتی کار ادامه دارد یک فرمان بازگشت یا پاک‌سازی زمان‌بندی‌شده نگه دارید. هر فراخوانی به -w نیاز دارد، وگرنه دو مدیر روی قفل xtables برخورد می‌کنند. هیچ‌کدام از این‌ها در پنجره تغییر اختیاری نیست.

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