Transmission در لینوکس: اعمال خروج بر اساس مالک فرایند
درگاه همتاها تمام ماجرا نیست. قاعده دیوار آتش را به حساب کاربری مشتری محدود کنید، هر دو خانواده نشانی را پوشش دهید و با فروافتادن تونل آزمایش کنید.
مسدود کردن درگاه ورودی Transmission یک سیاست VPN نیست. یک مشتری تورنت اتصال‌های خروجی به همتاها و ردیاب‌ها باز می‌کند، نام‌ها را حل می‌کند و ممکن است یک شنونده کنترل از راه دور ارائه دهد، و هر یک از این‌ها می‌تواند از رابطی خارج شود که قصدش را نداشتید. پنج بررسی را به ترتیب انجام دهید و قاعده دیوار آتش، نه تنظیمات مشتری، را مرز بدانید. دو بررسی آخر همان‌هایی هستند که مردم از آن‌ها می‌گذرند، و همان‌ها تعیین می‌کنند که آیا تضمین هنگام فروافتادن تونل برقرار می‌ماند.
فرایندی را که مالک انتقال است نام ببرید
برنامه رومیزی و سرویس سیستمی زیر حساب‌های متفاوتی اجرا می‌شوند، و قاعده‌ای مبتنی بر مالک، حساب را دنبال می‌کند نه نام برنامه را. پیش از نوشتن هر قاعده‌ای مشخص کنید کدام یک در حال اجراست. حساب سرویس اختصاصی به سیاست موضوعی دقیق می‌دهد، در حالی که کاربر رومیزی هویت خود را با مرورگرها، ویرایشگرها و هر چیز دیگری در نشست شریک می‌شود. UID را تأیید کنید نه اینکه فرض کنید نام حساب بسته همان نامی است که استفاده می‌شود.
systemctl status transmission-daemon
ps -o user=,pid=,cmd= -C transmission-daemonاگر حساب هنوز وجود ندارد، آن را برای این منظور بسازید و چیز دیگری برای اجرا به آن ندهید. حساب و UID را در توضیح قاعده بنویسید، زیرا قاعده‌ای بدون موضوع، قاعده‌ای است که هیچ‌کس نمی‌تواند آن را با ایمنی ویرایش کند.
فیلدهای شنود را از مسیر جدا کنید
Transmission 4.x نشانی‌های شنود همتاها را جدا از rpc-bind-address مستند می‌کند، و این تفاوت مهم است. تنظیم RPC تنها شنونده کنترل از راه دور را کنترل می‌کند، پس تغییر آن مسیری برای ترافیک همتاها انتخاب نمی‌کند. خواندن این دو تنظیم به‌عنوان یکی، رایج‌ترین دلیل نشت پیکربندی ظاهراً دقیقی است. همان مستندات یک حالت بازگشتی را توصیف می‌کند زمانی که نشانی شنود همتاها نامعتبر است، یعنی نشانی در دسترس‌نبوده یک حالت بازگشتی مستند است، نه رد تضمین‌شده.
grep -E '"(peer-port|rpc-bind-address|bind-address-ipv4)"' /var/lib/transmission-daemon/.config/transmission-daemon/settings.jsonاز کنترل‌های مشتری برای همان چیزی که هستند استفاده کنید، و تضمین را در دیوار آتش بگذارید. تنظیم شنود هنوز می‌تواند ارزشمند باشد، اما ثابت نمی‌کند که تماس با ردیاب‌ها، کشف محلی یا جست‌وجوی واگذارشده همه از تونل خارج می‌شوند. وقتی این دو اختلاف دارند، دیوار آتش تعیین می‌کند.
تطبیق مالک را در زنجیره درست بنویسید
راهنمای Netfilter درباره تطبیق مالک توضیح می‌دهد بسته‌های تولیدشده محلی چگونه به کاربر یا گروهی که مالک پرونده سوکت است نسبت داده می‌شوند. این نسبت‌دادن به ترافیک ارسال‌شده گسترش نمی‌یابد، و تطبیق گروه‌های اضافی به یک گزینه صریح نیاز دارد. راهنمای افزونه‌ای را که واقعاً استفاده می‌کنید بخوانید، نه نخستین مثالی که می‌یابید.
iptables -A OUTPUT -m owner --uid-owner transmission -o tun0 -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner transmission -j REJECT
ip6tables -A OUTPUT -m owner --uid-owner transmission -o tun0 -j ACCEPT
ip6tables -A OUTPUT -m owner --uid-owner transmission -j REJECTترتیب به اندازه تطبیق مهم است. یک پذیرش گسترده در بالای زنجیره، یک رد دقیق در پایین را بی‌اثر می‌کند، پس کل زنجیره را بررسی کنید نه اینکه قاعده‌ای بیفزایید و امیدوار باشید. اگر میزبان IPv6 اجرا می‌کند هر دو خانواده نشانی را بگنجانید، زیرا سیاست فقط v4 راهی را باز می‌گذارد که هیچ‌کس مراقب آن نیست. قاعده‌ها را در بازراه‌اندازی‌های مشتری و تونل نصب‌شده نگه دارید.
تصمیم بگیرید وقتی tun0 ناپدید می‌شود چه رخ می‌دهد
سیاست شکست جان مطلب تمرین است. اگر تونل ناپدید شود و همان قلاب قاعده‌ها را بردارد، مشتری آزاد است از رابط فیزیکی استفاده کند تا چیز دیگری آن را متوقف کند. طراحی ایمن قاعده‌ها را نگه می‌دارد و می‌گذارد رد کنند، و همین است که مرز را از سلامت تونل مستقل می‌کند. قلاب برچینی که قاعده‌ها را هم پاک می‌کند، دقیقاً نقطه مقابل یک سیاست شکست است.
ip link show tun0
iptables -S OUTPUTآن را عمداً بیازمایید: تونل را متوقف کنید، انتقالی را آغاز کنید که رهاکردنش ایمن است و ببینید چیزی بیرون می‌رود یا نه. سپس تونل را برگردانید و تأیید کنید که مسیر موردنظر دوباره کار می‌کند.
مسیرهایی را که قاعده نمی‌بیند پوشش دهید
حل نام ممکن است بر عهده یک فرایند حل‌کننده جداگانه باشد، و یک فضای نام یا دروازه اختصاصی می‌تواند مرز دیگری فراهم کند اگر مسیرهای اشتراک و راه‌اندازی آن برای این کار طراحی شده باشند. تصمیم بگیرید کدام مؤلفه مالک DNS است و آیا همان قاعده خروج را دنبال می‌کند. سپس به RPC نگاه کنید: اگر rpc-whitelist در حال استفاده است، شبکه مدیریت تأییدشده بخشی از قرارداد است، و یک بازه گسترده RFC1918 نیست.
ss -tunp | grep -i transmissionشمارنده‌های رابط می‌توانند یک مشاهده را تقویت کنند، اما نمی‌توانند ثابت کنند کدام فرایند بایت‌ها را تولید کرده است. انتقالی انجام دهید که اجازه دارید رهایش کنید: نخست روی مسیر کارکننده، سپس بدون تونل هنگام آغاز، و بعد از میان قطع، اتصال دوباره و رابطی که تازه ساخته شده. هم تلاش تازه و هم اتصالی را که از پیش باز بود بیازمایید، زیرا ممکن است قاعده روی سوکت قدیمی اعمال نشده باشد. تاریخ، حساب و نتیجه را همراه آزمایش ثبت کنید.
چسباندن مثالی که کل زنجیره را پاک می‌کند، یک سوراخ را با چند سوراخ عوض می‌کند، پس قاعده بیفزایید نه اینکه پاکشان کنید. وقتی هر پنج بررسی گذشت، تضمین صریح است: ترافیک مشتری از تونل بیرون می‌رود یا اصلاً بیرون نمی‌رود، و قاعده‌ای که آن را اعمال می‌کند از شکست خود تونل جان سالم به در می‌برد.