چرا net.ipv4.conf.default.forwarding کاری با tun0 ندارد

شما net.ipv4.conf.default.forwarding=1 را تنظیم کردید، VPN را دوباره راه‌اندازی کردید و تونل هنوز بسته‌هایی را دور می‌ریزد که دروازه باید مسیریابی کند. تنظیم در فایل درست به نظر می‌رسد و رابط هنوز گزارش می‌دهد که ارسال به جلو غیرفعال است. چیزی خراب نشده: مقداری را تغییر داده‌اید که رابط‌های آینده آن را به ارث می‌برند، نه مقداری که تونل فعال استفاده می‌کند.

این را روی میزبان مالک تونل، در namespace شبکه‌ای که تونل واقعاً در آن وجود دارد بررسی کنید. یک container یا namespace شبکه می‌تواند رابط را نگه دارد، در حالی که میزبان اعداد دیگری نشان می‌دهد.

سه مقدار را با هم بخوانید

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

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.default.forwarding
sysctl net.ipv4.conf.tun0.forwarding

یک نتیجهٔ رایج این است که ip_forward = 0، default.forwarding = 1 و tun0.forwarding = 0. دو مقدار اول دربارهٔ نقش میزبان هم‌نظر نیستند و سومی نشان می‌دهد رابط در واقع چه می‌کند. این ترکیب با میزبانی سازگار است که هرگز به‌عنوان مسیریاب پیکربندی نشده و فقط یک مقدار الگو گرفته است. این سه عدد با هم تناقض ندارند؛ آن‌ها به سه پرسش متفاوت پاسخ می‌دهند. نوشتن مقدار الگو هم نقش میزبان را تعیین نمی‌کند.

چرا کلید سراسری همان است که جابه‌جا می‌شود

net.ipv4.ip_forward کنترل سراسری دروازه است. تغییر آن، تنظیمات ارسال به جلو برای هر رابط را به‌عنوان بخشی از همان عملیات به‌روز می‌کند، از این رو یک نوشتن می‌تواند تونل موجود را به ارسال به جلو وادار کند. default.forwarding فقط رابط‌هایی را می‌کارد که بعداً مقداردهی اولیه می‌شوند، پس تونلی که از قبل وجود داشته مقدار زمان تولدش را نگه می‌دارد.

مستندات هسته ip_forward را به دلیلی مرتبط ویژه می‌داند: تغییر آن مجموعه‌ای از پارامترهای دیگر IPv4 را به پیش‌فرض‌های میزبان یا مسیریاب بازنشانی می‌کند. این آن را به ابزاری کند تبدیل می‌کند. تنظیم آن یک بار در چارچوب برپایی نقش دروازه اشکالی ندارد؛ اما تغییر مکرر آن به‌عنوان یک ترفند اشکال‌زدایی می‌تواند بی‌صدا پیکربندی‌ای را بازنویسی کند که برای درست کردنش وقت گذاشته‌اید.

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

تنظیم را در جای درست پایدار کنید

یک sysctl -w موفق یک‌باره ثابت می‌کند که هسته مقدار را می‌پذیرد. اما از راه‌اندازی مجدد جان سالم به در نمی‌برد، و از مدیر شبکه‌ای هم که هنگام اتصال دوباره تصور خودش از پیکربندی رابط را دوباره اعمال می‌کند جان سالم به در نمی‌برد. نقش دروازه را در فایل پیکربندی sysctl یا در مدیر شبکه‌ای که مالک میزبان است بگذارید و سپس سرویسی را که آن را اعمال می‌کند دوباره راه‌اندازی کنید.

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

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

این را با ابزار اشتباه تعمیر نکنید

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

با جریان درست هم آزمایش کنید. درخواستی که روی خود دروازه انجام می‌شود اصلاً ارسال به جلو را تمرین نمی‌دهد؛ این ترافیک محلی است. پرسش این است که آیا بسته‌ای که از یک کلاینت VPN یا میزبان LAN می‌رسد پذیرفته و به جلو مسیریابی می‌شود، پس آزمایش باید از پشت دروازه آغاز شود.

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

اینجا همه‌چیز IPv4 است. ارسال به جلو در IPv6، اعلان‌های مسیریاب و رفتار accept_ra کنترل‌های خودشان را دارند و کپی کردن یک مسیر ipv4 در تنظیم ipv6 فایلی می‌سازد که باورپذیر به نظر می‌رسد و کار مفیدی نمی‌کند. دروازهٔ دوپشته به پیکربندی آگاهانهٔ هر دو مجموعه نیاز دارد.

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