OpenVPN redirect-gateway: هر پرچم با مسیرها چه می‌کند

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

هر پرچم با مسیر پیش‌فرض چه می‌کند

بدون هیچ پرچمی، این گزینه مسیر پیش‌فرض معمول را حذف می‌کند و تونل را جای آن می‌گذارد، پس دروازه قدیمی تا وقتی اتصال برپاست از جدول ناپدید می‌شود. def1 را اضافه کنید و آن پیش‌فرض در فهرست می‌ماند، و دو مسیر باریک‌تر کار را انجام می‌دهند. bypass-dhcp را اضافه کنید و مسیر DHCP هم باقی می‌ماند، که در شبکه‌ای مهم است که کارخواه هنوز باید به کارساز محلی DHCP برسد. فهرست پرچم‌ها در صفحه راهنمای OpenVPN 2.6 به‌قدری کوتاه است که یک بار خوانده شود، و هر مدخل تغییر می‌دهد کدام مسیرها در جدول می‌مانند.

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

def1 با ویژگی بدون دست زدن به پیش‌فرض شما برنده می‌شود

دو مسیر نیمه‌پیش‌فرض با هم فضای IPv4 را می‌پوشانند، 0.0.0.0/1 و 128.0.0.0/1. هر یک از 0.0.0.0/0 مشخص‌تر است، پس جست‌وجو آن‌ها را ترجیح می‌دهد در حالی که پیش‌فرض واقعی برای هر چیزی که کم‌مشخص‌ترین تطبیق را می‌خواهد در جدول می‌ماند.

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

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

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

نقطه پایانی تونل را در دسترس نگه دارید

کارخواه به مسیری به انتهای دور تونل نیاز دارد که خودش از تونل نگذرد. OpenVPN آن مسیر میزبان را پیش از تغییر هر چیز دیگری نصب می‌کند، و ویرایش دستی مسیر یا کارخواه دوم VPN می‌تواند آن را بردارد. نشانه بعدی اتصالی است که می‌گوید متصل است و سپس چیزی عبور نمی‌دهد.

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

ip route get 198.51.100.20

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

ترافیک IPv6 همچنان از جدول خودش استفاده می‌کند

تغییرمسیر IPv4، IPv6 را به حال خود می‌گذارد، و دو خانواده با پرچم‌های متفاوت تغییر می‌کنند. روی میزبان دوپشته‌ای با پیش‌فرض v6 سالم، ترافیک v4 می‌تواند کاملاً داخل تونل بماند در حالی که هر مقصد توانمند به v6 از پیوند فیزیکی خارج می‌شود. میزبانی که در یک جدول درست به نظر می‌رسد در جدول دیگر نشت می‌کند.

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

ip -6 route show default
ip -6 route get 2001:db8::10

ثابت کنید یک برنامه از کدام واسط استفاده می‌کند

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

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

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

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