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

کلاینت هنگام شروع چه چیزی را به ارث می‌برد

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

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

پیش از تغییر، منشأ خط را مشخص کنید

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

ps -o pid=,args= -C pppd

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

خط افزونه‌ای که هر کلاینت را دنبال می‌کند

افزونه‌ای که در فایل سیستم بارگذاری می‌شود بدترین مورد است، چون تغییر می‌دهد فرایند جدید PPP چه چیزی را بارگذاری کند، بی‌آنکه مهم باشد کاربر کدام دکمه را زده است. افزونهٔ L2TP نمونهٔ کلاسیک است: برای یک نمایه درست، و برای نمایهٔ PPTP که از همان پیش‌فرض‌ها شروع می‌کند بی‌معنا یا زیان‌بار.

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

پس از جابه‌جایی هر کلاینت را بررسی کنید

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

sudo pppd call office debug dump

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

مقالات مرتبط