میزبان iptables فقط با VPN: دستگاه tun را نام ببرید، نه tun+

نوشتن -o tun+ شبیه یک دستور دقیق به نظر می‌رسد و در واقع یک نویسه عام است که همهٔ تونل‌های موجود در هسته را در بر می‌گیرد. یک کلاینت VPN دوم، یک پل کانتینر یا رابطی که از یک نشست از‌کار‌افتاده باقی مانده است، همگی آن را برآورده می‌کنند، و سپس میزبان ترافیکی را مجاز می‌کند که سیاست برای جلوگیری از آن نوشته شده بود. رویهٔ زیر یک نام دستگاه را ثابت می‌کند، استثناها را طوری مرتب می‌کند که تونل واقعاً شکل بگیرد و اگر قواعد بد پیش بروند راه بازگشتی برایتان باقی می‌گذارد. هر گام به‌اندازه‌ای کوتاه است که به‌تنهایی برگشت‌پذیر باشد.

گام 1: قواعدی را که اکنون دارید ثبت کنید

پیش از تغییر یک سیاست پیش‌فرض، وضعیت کنونی را ذخیره کنید تا بازگردانی یک دستور باشد نه یک خاطره. iptables-save > /root/iptables.pre همهٔ جدول‌ها را در فایلی می‌نویسد که می‌توانید بازیابی کنید، و یک ترمینال دوم با نشست root باز، در زمانی که سیاستی که می‌خواهید اعمال کنید اتصالی را که آن را حمل می‌کند قطع می‌کند، وسواس نیست. اگر از راه دور کار می‌کنید، یک flush را هم به‌عنوان کلید مرده زمان‌بندی کنید.

سپس رابط‌ها را فهرست کنید، چون نامی که فرض کرده‌اید نامی است که باید می‌خواندید: ip -br link نشان می‌دهد همین حالا چه چیزی وجود دارد، و تونل تا بالا نیاید ظاهر نمی‌شود. نام دستگاه‌ها را همان‌طور که می‌خوانید یادداشت کنید.

گام 2: به تونل نام خودش را بدهید

OpenVPN در پیکربندی کلاینت dev tun_work را می‌پذیرد و سپس Linux به‌جای تخصیص tun0 رابطی با همان نام دقیق می‌سازد. تا وقتی چیز دیگری آن را طلب نکند، نام در اتصال‌های مجدد پایدار می‌ماند، و همین است که قاعده‌ای را که دستگاه را نام می‌برد معنادار می‌کند.

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

گام 3: سیاست را با استثنای endpoint اول بنویسید

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

# allow the tunnel to be built, then everything the tunnel carries
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o tun_work -j ACCEPT
iptables -A INPUT  -i tun_work -j ACCEPT
iptables -A INPUT  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

نشانی و درگاه تحت‌اللفظی endpoint متعلق به ارائه‌دهندهٔ شماست، نه این صفحه. اگر endpoint یک نام میزبان است، یک بار آن را تجزیه کنید و نتیجه را ثابت کنید، چون یک قاعده نمی‌تواند نامی را جست‌وجو کند و پاسخ چرخشی پس از تغییر بعدی DNS سیاست را بی‌صدا می‌شکند. درگاه را هم بررسی کنید، چون ارائه‌دهندگانی که شما را به TCP 443 منتقل می‌کنند در غیر این صورت به قاعده‌ای نیاز خواهند داشت که کسی آن را ننوشته است. تونلی که فقط با یک پروتکل کار می‌کند معمولاً همین از‌قلم‌افتادگی است نه نقص دیوار آتش.

روی یک روتر همین شکل به زنجیرهٔ FORWARD برای کلاینت‌های پشت آن می‌رود، و ترافیک خود روتر قواعد خودش را می‌خواهد. مجموعه‌قواعدی که فقط بسته‌های هدایت‌شده را پوشش می‌دهد SSH و DNS را روی مسیر قدیمی می‌گذارد، و این‌گونه است که روتر در همان لحظه‌ای که تونل بالا می‌آید غیرقابل‌دسترسی می‌شود.

گام 4: ترتیب را بررسی کنید، نه فقط وجود را

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

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

گام 5: کاری کنید که از بوت و خانوادهٔ نشانی جان سالم به در ببرد

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

سپس IPv6 را جداگانه بررسی کنید، چون یک سیاست رد پیش‌فرض خوب برای IPv4 هیچ چیزی دربارهٔ خانوادهٔ دیگر نمی‌گوید. ip -6 route به شما می‌گوید آیا میزبان مسیری دارد که بتواند ترافیک را دور تونلی ببرد که فقط IPv4 را مدیریت می‌کند، و ip6tables یا nftables قواعد معادل خودش را می‌خواهد. با مقصدی IPv6-only آزمایش کنید، نه با اعتماد به تقارن مجموعه‌قواعد.

گام 6: بررسی کنید و آمادهٔ بازیابی باشید

تونل را بالا بیاورید، تأیید کنید سرویس موردنظر کار می‌کند، سپس چیزی را امتحان کنید که سیاست باید رد کند. اگر پاسخ غافلگیرتان کرد با iptables-restore < /root/iptables.pre بازیابی کنید، و تنها پس از آن ویرایش قواعد را شروع کنید. پایداری به‌همراه مسیر بازیابی آزمایش‌شده همان چیزی است که این را تبدیلی می‌کند که می‌توانید دو بار انجامش دهید.