bypass-dhcp در واقع چه چیزی به طرح مسیر OpenVPN اضافه می‌کند

پروفایلی که redirect-gateway def1 bypass-dhcp دارد، جایگزینی مسیر پیش‌فرض IPv4 را با یک استثنای باریک ترکیب می‌کند. مردم کلمه آخر را می‌خوانند و انتظار راه‌حل عمومی برای اتصال‌های موبایل دارند، بعد یک بعدازظهر را صرف نظریه‌ای درباره DHCP می‌کنند که این پرچم هرگز از آن پشتیبانی نکرده است. هر بخش یک کار می‌کند و استثنا بسیار کوچک‌تر از شهرتش است.

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

دو پرچم، دو کار بی‌ارتباط

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

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

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

استثنا در واقع به چه چیزی محدود است

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

0.0.0.0/1        via 10.8.0.1      dev tun0
128.0.0.0/1      via 10.8.0.1      dev tun0
192.168.1.1/32   via 192.168.1.254 dev wlan0

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

بررسی کنید کلاینت واقعاً چه نصب کرده است

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

مسیر تا نقطه پایانی VPN را هم‌زمان قابل استفاده نگه دارید. آن استثنای نقطه پایانی الزامی متفاوت از استثنای DHCP است و بدون آن تونل می‌تواند ترابری را که آن را زنده نگه می‌دارد بگیرد.

برای مقصد یک برنامه، جست‌وجوی مؤثر را در بافتی که شکست می‌خورد بررسی کنید. مسیرهای محلی مشخص‌تر، مسیریابی سیاستی و استثناهای هر برنامه همه پاسخ را تغییر می‌دهند، پس وجود دو نیمه‌مسیر پیش‌فرض فهرست همه جریان‌ها نیست.

بقیه مسیر در این پرچم نیست

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

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

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