قاعده SNAT در OpenVPN را پیش از خراب کردن nginx محدود کنید

دو خرابی همیشه از یک نوع میزبان می‌رسند. در اولی، کلاینت‌ها احراز هویت می‌کنند و سپس به چیزی فراتر از تونل دست نمی‌یابند. در دومی، VPN بالا می‌آید و وب‌سایت خود سرور از پاسخ دادن بازمی‌ماند، که نگران‌کننده‌تر است چون شبیه آسیب جانبی به نظر می‌رسد. روی VPS مبتنی بر کانتینر هر دو معمولاً به همان فهرست کوتاه بررسی‌ها برمی‌گردند، و ترتیب مهم است: اول دستگاه، دوم ترجمه، سوم دامنه.

تأیید کنید که کانتینر می‌تواند دستگاه tun بسازد

اگر رابط تونل نتواند وجود داشته باشد هیچ چیز دیگری مهم نیست. بررسی کنید که /dev/net/tun وجود دارد و ساخت یک دستگاه آزمایشی موفق می‌شود، چون بسیاری از ارائه‌دهندگان به‌طور پیش‌فرض tun را درون کانتینرها غیرفعال می‌کنند. هیچ تلاشی در firewall جبران دستگاهی را که هرگز ساخته نشده نیست.

اگر دستگاه نیست، فقط میزبان یا ارائه‌دهنده می‌تواند آن را فعال کند. یک طرح دیگر غالباً از یک رشته پشتیبانی باز که یک هفته طول می‌کشد ارزان‌تر است. این را پیش از خواندن حتی یک خط از گزارش OpenVPN تأیید کنید. وگرنه شب را صرف تنظیم قواعدی می‌کنید که هرگز بسته‌ای نخواهند دید.

تصمیم بگیرید MASQUERADE روی این رابط چه می‌کند

روی یک ماشین مجازی معمولی قاعده خروج معمول است POSTROUTING MASQUERADE از رابط اصلی. در کانتینر OpenVZ دستگاه قابل مشاهده غالباً venet0 است، یک رابط مجازی تحت مدیریت میزبان و نه کارت شبکه مسیریابی‌شده، و MASQUERADE همیشه آنجا آن‌گونه که آموزش‌ها فرض می‌کنند رفتار نمی‌کند.

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

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

بدون قواعد ارسال، ترجمه همچنان رخ می‌دهد و هسته همچنان از ارسال خودداری می‌کند. این ترکیب وضعیت گیج‌کننده‌ای می‌سازد که شمارنده‌های قاعده NAT بالا می‌رود در حالی که کلاینت چیزی دریافت نمی‌کند. دو خط FORWARD هم باید پیش از هر قاعده drop گسترده در همان زنجیره قرار بگیرند. ترتیب بخشی از پیکربندی است، نه جزئیات پیاده‌سازی.

قاعده را به یک pool و یک رابط محدود کنید

نشانه دوم علت دیگری دارد: یک قاعده POSTROUTING بدون محدودیت مبدأ و بدون محدودیت خروجی. چنین قاعده‌ای هر بسته‌ای را که میزبان را ترک می‌کند بازنویسی می‌کند.

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

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

قواعد را ماندگار کنید و بفهمید چه کس دیگری مالک آن‌هاست

قواعدی که دستی اضافه شده‌اند در راه‌اندازی مجدد ناپدید می‌شوند، پس آن‌ها را با iptables-save ذخیره کنید یا جایی که نصب است از طریق netfilter-persistent مدیریت کنید. تأیید کنید که بازیابی پیش از شروع OpenVPN اجرا می‌شود. سپس یک بار عمداً راه‌اندازی مجدد کنید به‌جای آنکه شکاف را در میانه یک حادثه کشف کنید.

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

با شمارنده‌ها و یک جریان ثبت‌شده بررسی کنید

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

روی سرور، شمارنده‌های بسته روی قواعد NAT و FORWARD را با iptables -t nat -L -v -n بخوانید و یک جریان را در یک ضبط مشاهده کنید. اگر آدرس کلاینت در ضبط ظاهر شود و پاسخی نیاید، شکاف در مسیر بازگشت یا در فیلترکردن ارائه‌دهنده است نه در پروفایل کلاینت. مبدأ ثبت‌شده را با آدرسی که قاعده به آن ترجمه می‌کند مقایسه کنید، چون عدم تطابق یعنی قاعده دیگری اول مطابقت کرده است. یک جریان مشاهده‌شده بیش از یک صفحه خواندن پیکربندی را روشن می‌کند.

pool، آدرس ترجمه‌شده و نام رابط را در سابقه تغییرات کنار هم نگه دارید. قاعده‌ای که برای یک pool درست است بعدی را غلط ترجمه می‌کند.