چرا نویسهٔ عام در دستور مسیر OpenVPN کار نمی‌کند

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

مسیر چه چیزی نصب می‌کند و چه چیزی را هرگز نمی‌خواند

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

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

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

وقتی مقصد واقعاً یک پیشوند است

اگر هدف یک شبکهٔ خصوصی شناخته‌شده است، پیشوند را بنویسید. برای نمونه‌ای از فضای مستندات، یک میزبان تنها و یک زیرشبکه چنین به نظر می‌رسند:

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

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

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

وقتی واحد کار یک نام میزبان است

انتخاب بر اساس دامنه چیزی می‌خواهد که دامنه را بخواند، یعنی مؤلفه‌ای در لایهٔ کاربرد. پاسخ معمول یک پروکسی HTTP است که در آن سوی تونل زندگی می‌کند و کلاینت انتخاب می‌کند کدام درخواست‌ها را به آن بفرستد.

یک پروندهٔ پیکربندی پروکسی می‌تواند آن انتخاب را بیان کند. قواعد نمونهٔ زیر یک دامنه و زیردامنه‌هایش را به پروکسی و بقیهٔ چیزها را مستقیم می‌فرستند:

function FindProxyForURL(url, host) {
    var h = host.toLowerCase();
    if (h === "corp.example" || dnsDomainIs(h, ".corp.example")) {
        return "PROXY 10.60.0.12:3128";
    }
    return "DIRECT";
}

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

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

گزینهٔ پروکسی چه چیزی را پوشش نمی‌دهد

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

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

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

آزمودن هر دو مسیر، نه فقط مسیر خوش‌بینانه

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

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