پاسخهای VPN لینوکس ناپدید می‌شوند؟ rp_filter و مسیر را بررسی کنید

درخواست‌ها ماشین را ترک می‌کنند، همتای VPN پاسخ می‌دهد، و پاسخ هرگز به سوکت نمی‌رسد. تونل برپاست، گزارش‌های همتای نشان می‌دهند بسته ارسال می‌شود، و هیچ چیز در برنامه این سکوت را توضیح نمی‌دهد. در لینوکس یکی از مظنون‌های معمول فیلتر مسیر معکوس است: بسته ورودی IPv4 می‌تواند رد شود وقتی اعتبارسنجی مبدأ با مسیری که هسته برای آن مبدأ انتظار دارد نمی‌خواند. طی کردن آن به ترتیب به شما می‌گوید آیا این علت است یا تصادف. همچنین مانع می‌شود برای رفع مسیر گمشده یک کنترل امنیتی را غیرفعال کنید.

اعتبارسنجی مبدأ چه چیزی را تعیین می‌کند

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

واژه مهم معقول است. بسته می‌تواند کاملاً مشروع باشد و باز هم در بررسی شکست بخورد، چون مشروعیت چیزی نیست که آزموده می‌شود.

حالت مؤثر را بخوانید، نه یک فیلد

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

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>

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

پیش از تغییر بررسی، ناسازگاری را پیدا کنید

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

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

بررسی‌های مبدأ را به‌عنوان نخستین واکنش به‌صورت کلی خاموش نکنید. این کار یک تشخیص مشخص را با تغییری گسترده در رفتار عوض می‌کند که بعداً باید به یاد بسپارید.

یک تنظیم گزینشی که می‌توانید از آن دفاع کنید

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

موردی را بگنجانید که هنوز باید رد شود. اگر آن مورد اکنون موفق شود، تنظیم بیش از همان یک مسیری را که می‌خواستید تعمیر کنید تضعیف کرده است.

IPv4 و IPv6 را جدا نگه دارید

یک sysctl آشنا برای هر خانواده نشانی سیاست نیست. IPv6 رفتار و تنظیم‌های خودش را دارد، و یک ماشین می‌تواند در یک خانواده سخت‌گیر و در دیگری آسان‌گیر باشد بدون آنکه کسی تا شکست یک مقصد مشخص متوجه شود. اگر بار کاری از هر دو استفاده می‌کند هر دو را بررسی کنید.

حالت، رابط، خروجی جست‌وجوی مسیر و دلیل تغییر را در یک جا ثبت کنید. نفر بعدی تنظیم را پیدا می‌کند و هیچ توضیحی نمی‌بیند، و یا آن را حذف می‌کند یا جایی کپی می‌کند که به آنجا تعلق ندارد.