ویرایش یک خط در ipp.txt حس رزرو کردن یک نشانی را می‌دهد، اما این‌گونه نیست. آن فایل که با ifconfig-pool-persist نام‌گذاری می‌شود، ثبت می‌کند که یک نام مشترک بار آخر چه نشانی داشت تا استخر بتواند همان را در صورت مناسب بودن بازگرداند. هیچ چیز در آن اتصال بعدی را به آن شماره مقید نمی‌کند.

بررسی‌های زیر را به ترتیب اجرا کنید. هر کدام یا سازوکار را تأیید می‌کند یا می‌گوید توقف کنید و یک ورودی را درست کنید.

فایل ماندگاری برای چه کاری است

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

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

بررسی کنید که کلاینت درست انتخاب شده باشد

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

تا اینجایید، هم‌زمانی را هم در نظر بگیرید. اگر duplicate-cn مجاز باشد، چند دستگاه می‌توانند هویت یکسان ارائه دهند و یک نشانی ثابت نمی‌تواند برای همه آن‌ها یکتا باشد. تصمیم بگیرید آیا نشانی ثابت ارزش رد کردن نشست‌های هم‌زمان برای آن هویت را دارد، چون این دو نیاز با هم برآورده نمی‌شوند.

بررسی کنید که اعداد با توپولوژی می‌خوانند

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

# /etc/openvpn/ccd/partner-a   (subnet topology)
ifconfig-push 10.44.0.61 255.255.255.0

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

نتیجه را روی یک اتصال تازه بررسی کنید

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

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

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

مقالات مرتبط