چرا یک کلاینت VPN در شبکه محلی دفتر هر پاسخی را از دست می‌دهد

لپ‌تاپی روی /24 دفتر از طریق Ethernet نشسته و هم‌زمان به سرور OpenVPN می‌پیوندد که در همان /24 زندگی می‌کند. همکاری نشانی تونل را پینگ می‌کند؛ درخواست آشکارا می‌رسد و چیزی برنمی‌گردد. گزارش تونل پاک است و وب‌گردی هنوز کار می‌کند، پس تونل مظنون اشتباه است. اعتبارسنجی مبدأ IPv4 در ماشین گیرنده بسته را پیش از آنکه چیزی آن را بخواند دور می‌اندازد.

دورانداختن پیش از آن رخ می‌دهد که چیزی بسته را بخواند

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

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

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

پیش از دست زدن به هر sysctl حالت برقرار را اثبات کنید

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

tcpdump -ni tun0 icmp and host 192.168.80.25
ip route get 192.168.80.25
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.tun0.rp_filter

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

خط پایه را پیش از هر تغییری بنویسید: هر دو مقدار، دستگاهی که جست‌وجو برگزید و شمارنده‌ای که می‌پایید. همین ثبت است که بعداً به شما می‌گوید تغییر همان کاری را کرد که گمان می‌کنید.

هر حالت rp_filter در واقع چه می‌پذیرد

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

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

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

کوچک‌ترین تغییری را برگزینید که ابهام را برمی‌دارد

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

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

هر راهی که برگزینید، آن را در یک drop-in مربوط به sysctl ثبت کنید نه در فرمان زنده. کلیدهای all و default را با هم تنظیم کنید تا اتصال دوباره نتواند بی‌صدا حالت سخت را بازگرداند.

# /etc/sysctl.d/99-rp-filter.conf
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2
sysctl --system

حالت سست چه چیزی را وا می‌گذارد، و کجا

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

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

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