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

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

دستگاه و آدرس‌هایش

دستگاه تونل یا توسط مدیری که پروفایل را می‌شناسد ساخته می‌شود، یا توسط دیمنی که کسی دستی راه انداخته است. هر دو ترتیب به‌تنهایی کار می‌کنند؛ ترکیبشان نه. اگر NetworkManager مالک پروفایل است، بگذارید مالک دستگاه هم باشد، و یک OpenVPN بدون مدیریت را علیه همان نام تونل راه نیندازید.

ثبت کنید چه کسی دستگاه را هنگام پایان نشست حذف می‌کند. دستگاهی که از نشستش عمر بیشتری می‌کند، رایج‌ترین منبع آدرس‌های کهنه و سردرگمی پس از آن‌هاست.

مسیرها و قواعد سیاست

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

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

DNS همیشه مالک جداگانه دارد

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

افسانه اینجاست که نوشتن یک name server در پروفایل تغییر می‌دهد که پرس‌وجوها کجا می‌روند. این تغییر می‌دهد که به resolver چه گفته می‌شود، نه اینکه resolver از کدام سوکت در بالادست استفاده می‌کند. به‌جای اعتماد به فایل، با یک پرس‌وجو و یک جست‌وجوی مسیر آزمایش کنید.

وضعیت فایروال، و اینکه چه کسی آن را بازمی‌گرداند

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

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

چرخهٔ عمر: بوت، اتصال دوباره، برچیدن

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

برای مشاهده، ip monitor link address route تغییرات کرنل را همان‌طور که رخ می‌دهند نشان می‌دهد، اما رویدادها را گزارش می‌کند نه نیت را: یک مسیر حذف‌شده چیزی دربارهٔ اینکه کدام فرایند آن را حذف کرده نمی‌گوید. آن را با نقشهٔ مالکیت جفت کنید، و یک خاموشی گیج‌کننده به فهرست کوتاهی از نامزدها تبدیل می‌شود.

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

مقالات مرتبط