اسکریپت قطع یا قاعده فایروال: کدام نشتی را متوقف می‌کند؟
پایین آوردن رابط‌ها هنگام قطع اتصال خشن است و اغلب بدون دسترسی اجرا می‌شود. آن را با قاعده فایروالی مقایسه کنید که از افت اتصال جان سالم به در می‌برد و شکاف را می‌بندد.
دو طراحی یک چیز را وعده می‌دهند: وقتی تونل می‌افتد، هیچ چیزی به‌صورت باز بیرون نمی‌رود. یکی هنگام برچیدن اسکریپتی اجرا می‌کند و رابط‌ها را قطع می‌کند. دیگری قاعده فایروال را در نیرو نگه می‌دارد و هیچ چیزی از کارخواه VPN نمی‌خواهد. تفاوتشان در این است که چه کسی اختیار اقدام دارد، در فاصله افت چه رخ می‌دهد و ماشین بعداً چگونه دوباره آنلاین می‌شود. مقایسه آن‌ها در این سه نکته از بحث درباره سخت‌گیرانه‌تر بودن یکی سودمندتر است.
همان کار از راه دو سازوکار
کارخواه می‌تواند هنگام بالا آمدن تونل و هنگام برچیدن آن قلاب اجرا کند، به شرطی که نمایه اجازه اجرای اسکریپت بدهد. آن قلاب درون چرخه عمر کارخواه، در لحظه‌ای که اتصال بسته می‌شود، اجرا می‌شود. در مقابل، قاعده فایروال متعلق به سیستم است و اهمیتی نمی‌دهد که کارخواه در حال اجرا، از کار افتاده یا کشته شده باشد.
| Property | Teardown script | Firewall unit |
|---|---|---|
| Runs when the client is killed | No | Yes |
| Needs privilege at teardown time | Usually yes | Configured once, at boot |
| Acts on the whole machine | Often, including recovery paths | Only on the flows it matches |
این جدول تمام استدلال است. اسکریپتی که فقط در بستن مرتب اجرا می‌شود همان حالتی را پوشش می‌دهد که کمترین نگرانی را داشتید؛ حالتی که اهمیت دارد از کار افتادن یا ناپدید شدن شبکه است و هیچ‌کدام برچیدن تمیزی تولید نمی‌کنند.
قلاب برچیدن چه می‌تواند بکند و چه نمی‌تواند
الگوی مستندشده رابط‌های شبکه را می‌پیماید و همه چیز جز loopback را پایین می‌آورد. با پایین بودن دستگاه فیزیکی، هیچ چیز نمی‌تواند به بیرون تونل بگریزد، که دقیقاً همان قصد است.
#!/bin/sh
for dev in /sys/class/net/*; do
name=$(basename "$dev")
[ "$name" = lo ] || ip link set dev "$name" down
doneهمچنین شبکه محلی، هر سرویسی که ماشین میزبانی می‌کند و مسیری را که برای رفع مشکل به کار می‌بردید پایین می‌آورد. در لپ‌تاپ دستگاه بی‌سیم گاهی بعد از آن به کلید دستی نیاز دارد، پس یک قطع کوتاه به جلسه تعمیر تبدیل می‌شود. بدتر آنکه ممکن است به قلاب اجازه هیچ‌یک از این کارها داده نشود: وقتی کارخواه از دسترسی‌ها صرف‌نظر می‌کند، اسکریپت برچیدن با حساب بدون دسترسی اجرا می‌شود و هر تغییر رابط با خطای دسترسی شکست می‌خورد که در همان لحظه‌ای نوشته می‌شود که هیچ‌کس گزارش را نمی‌خواند.
پیش از اعتماد به قلاب بررسی کنید کارخواه چگونه آغاز می‌شود. اسکریپتی که وقتی دستی با root اجرا می‌کنید کار می‌کند هیچ چیزی درباره سرویسی که هنگام راه‌اندازی آغاز می‌شود ثابت نمی‌کند.
قاعده فایروال چه کار متفاوتی می‌کند
قاعده‌ای که فقط ترافیک تونل را مجاز می‌کند وقتی فرایند کارخواه رفته است هم کار می‌کند، زیرا هسته به آن فرایند وابسته نیست. قاعده باریک‌تر هم هست: دقیقاً جریان‌هایی را مسدود می‌کند که با آن‌ها منطبق است و loopback، زیرشبکه محلی و مسیر بازیابی را به حال خود می‌گذارد، از این رو ماشین را بی‌خروجی نمی‌گذارد.
بهای آن این است که قاعده باید به دست کسی نوشته و نگه داشته شود که فایروال میزبان را در اختیار دارد، و باید دستگاه تونلی را نام ببرد که کارخواه واقعاً می‌سازد. این یعنی قاعده و نمایه باید با هم نگه داشته شوند؛ رابطی که نامش عوض شده فایروالی به جا می‌گذارد که همه چیز را مسدود می‌کند و هیچ چیز را توضیح نمی‌دهد.
هیچ‌یک از دو سازوکار دیگری را زائد نمی‌کند. قاعده فایروالی که پس از یک ویرایش هرگز دوباره بارگذاری نمی‌شود به همان اندازه اسکریپتی که هرگز اجرا نمی‌شود ساختگی است.
persist-tun تعیین می‌کند که شکافی وجود دارد یا نه
وقتی دستگاه تونل از قطع اتصال جان سالم به در می‌برد، مسیرهایی هم که به آن اشاره می‌کنند باقی می‌مانند. ترافیک آنگاه به جای تغییر مسیر دور ریخته می‌شود، پس مسیر پیش‌فرض به دروازه فیزیکی برنمی‌گردد. همین رفتار است که نشتی را حتی پیش از دخالت هر قاعده فایروالی نامحتمل می‌کند.
بدون این تنظیم، دستگاه و مسیرها با آن حذف می‌شوند و مسیر پیش‌فرض می‌تواند دوباره به دروازه فیزیکی برسد. اینکه چنین کند به پلتفرم و کارخواه بستگی دارد و دقیقاً به همین دلیل وضعیت باید مشاهده شود نه فرض. تنظیم را بخشی از kill switch بدانید، نه گزینه‌ای برای کارایی.
مسیر اتصال دوباره را زنده نگه دارید، سپس چهار حالت را بیازمایید
مسدودسازی سخت می‌تواند کارخواه را از اتصال دوباره هم بازدارد، زیرا کارخواه هنوز به مسیری به سرور از طریق دروازه فیزیکی نیاز دارد در حالی که همه چیز دیگر رد می‌شود. پیش از بالا آمدن تونل یک مسیر میزبان برای همان یک نشانی نصب کنید و نخست نام را تفکیک کنید، چون DNS ممکن است تا زمانی که به آن نیاز دارید مسدود شده باشد.
ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0سپس حالت‌ها را بررسی کنید نه برچسب را. چهار لحظه را عمداً تجربه کنید: راه‌اندازی سرد بدون تونل، جلسه سالم، افت بی‌درخواست و جلسه پس از بازیابی. در هر لحظه مسیر پیش‌فرض را بخوانید و درخواستی بفرستید که نشانی خروجش دیده شود. برنامه‌ای که وقتی تونل پایین است تسلیم می‌شود چیزی درباره کارخواه ایمیل یا به‌روزرسان نمی‌گوید، پس آخرین بررسی را با یک برنامه پس‌زمینه تکرار کنید. قاعده، نام رابط‌ها و گام‌های بازیابی را بنویسید، چون kill switch ای که هیچ‌کس نمی‌تواند بررسی کند شایعه است.