فرار IPv4 را در برابر راه‌اندازی مجدد دروازه VPN پایدار کنید

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

رسیدن به دروازه با فرار یکی نیست

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

بنویسید بسته کارخواه از کدام رابط می‌رسد و مسیر بعدی از کدام رابط بیرون می‌رود. هر دو به یک فضای نام تعلق دارند و همان فضای نام تنظیمی را نگه می‌دارد که اهمیت دارد.

مقدار را همان‌جا بخوانید که بسته‌ها واقعاً هستند

روی دروازه‌ای که در فضای نام میزبان مسیریابی می‌کند، یک فرمان به پرسش پاسخ می‌دهد: sysctl net.ipv4.ip_forward. وقتی مسیر ورودی و مسیر بعدی در یک فضای نام نام‌دار زندگی می‌کنند، از همان فضای نام بپرسید: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. مقدار میزبان جانشین مقدار فضای نام نیست و یک بودن روی میزبان دلیل هیچ چیزی نیست.

هر زمینه مسیریابی برچسبی ندارد که بتوانید به ip netns بدهید. محیط‌های اجرای کانتینر و سرویس‌ها فضاهای نامی می‌سازند که هرگز با یک نام دوستانه ثبت نمی‌شوند، و برای آن‌ها از ابزارهای بازرسی محیط اجرا استفاده می‌کنید. جای vpn-gw نام واقعی یا سازوکار محیط اجرا را بگذارید که به همان زمینه می‌رسد، و در سطح میزبان از حدس زدن دست بردارید.

به تنظیم یک مالک واحد بدهید

روی یک دروازه میزبان متعارف با systemd، شکل پایدار یک فایل drop-in با نامی است که مدیر انتخاب می‌کند، مانند /etc/sysctl.d/60-vpn-forwarding.conf که net.ipv4.ip_forward = 1 را در خود دارد. فایل را بنویسید، سپس همان فایل مشخص را بارگذاری کنید تا وضعیت زنده هم تغییر کند: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf، و پس از آن یک بازخوانی. نام فایل یک نمونه است نه مسیر رزروشده VPN، و شماره آغازین اهمیت دارد زیرا فایل‌هایی که دیرتر مرتب می‌شوند برنده می‌شوند.

اولویت همان جایی است که پایداری بی‌صدا می‌شکند. هم بارگذار توزیع را بررسی کنید و هم drop-in خودتان را، زیرا procps sysctl --system در پایان /etc/sysctl.conf را هم می‌خواند، در حالی که ترتیب sysctl.d در systemd دنباله‌ای کاملاً متفاوت است. یک تخصیص دیرتر می‌تواند همان کلید را بلافاصله برگرداند و فایل شما را درست و مقدار مؤثر را نادرست بگذارد. برای بردن این بحث فایل مدیر موجود را بازنویسی نکنید؛ مالک را پیدا کنید و همان‌جا تغییر دهید.

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

بدانید کلید چه هزینه‌ای دارد پیش از آنکه بزنیدش

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

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

پایداری را ثابت کنید، سپس بقیه مسیر را بیازمایید

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

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

مسیر drop-in، مالک فضای نام و فرمان بازخوانی را با هم در runbook نگه دارید. هر کس بعدی این را بردارد باید بتواند مقدار را بخواند، ببیند چه کسی مالک آن است و در عرض یک دقیقه تصمیم بگیرد که مشکل پایداری است یا بقیه مسیر.