نشانی‌های پایدار OpenVPN باید از هویت پیروی کنند، نه از IP مبدأ

طرح‌های نشانی که می‌گویند «این لپ‌تاپ 10.90.0.10 می‌گیرد» در واقع بیانیه‌هایی دربارهٔ هویت‌اند: کدام دستگاه احراز هویت‌شده می‌تواند آن نشانی را داشته باشد. IP عمومی کنونی آن دستگاه تقریباً هیچ ربطی به این ندارد، زیرا NAT و رومینگ آن را تغییر می‌دهند بدون اینکه تغییر دهند کاربر چه کسی است. ساختن طرح بر پایهٔ نشانی مبدأ قواعدی پدید می‌آورد که در نخستین شبکهٔ هتل می‌شکنند. ساختن آن بر پایهٔ هویت احراز هویت‌شده طرحی پدید می‌آورد که از سفر جان سالم به در می‌برد.

از آنچه سرور می‌تواند بررسی کند آغاز کنید، سپس تصمیم بگیرید نشانی برای چه چیزی است.

کلید هویت را پیش از نشانی انتخاب کنید

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

با duplicate-cn، چند نشست هم‌زمان می‌توانند نام مشترک یکسانی را ارائه دهند، بنابراین یک نشانی سنجاق‌شده نمی‌تواند آن‌ها را جداگانه شناسایی کند. این ویژگی مدل هویت است، نه چیزی که طرح نشانی بهتر بتواند درست کند.

نشانی‌ها را بیرون از محدودهٔ پویا رزرو کنید

در شبکه‌ای با توپولوژی زیرشبکه مانند 10.90.0.0/24، نشانی‌های پایین را برای اعضای نام‌دار نگه دارید و استخر پویا را در محدوده‌ای جدا قرار دهید. تخصیص یک عضو سنجاق‌شده چنین است ifconfig-push 10.90.0.10 255.255.255.0 در فایلی که سرور برای آن هویت انتخاب می‌کند. آرگومان دوم زیر net30 معنای دیگری دارد، پس مثال نسبت به توپولوژی بی‌طرف نیست. پیش از کپی کردن، توپولوژی را بخوانید.

ماندگاری استخر اجاره‌های اخیر را ثبت می‌کند و تمایل دارد همان نشانی را برگرداند، که یک تسهیل است نه رزرو. نگذارید فایل ماندگاری به سند مالکیت تبدیل شود، زیرا با تاریخچهٔ اتصال تغییر می‌کند نه با سیاست.

اولویت تخصیص تعیین می‌کند چه کسی برنده می‌شود

راهنما ترتیبی را مستند می‌کند: تخصیص صریحی که در زمان client-connect تولید می‌شود می‌تواند پیش از ورودی client-config-dir اثر کند، که خودش پیش از تخصیص معمول استخر می‌آید. این ترتیب بیشتر گزارش‌های «نشانی سنجاق‌شده اعمال نشد» را توضیح می‌دهد. همچنین یعنی تخصیص‌دهندهٔ پویایی که پیکربندی هر نشست را می‌نویسد می‌تواند بی‌صدا فایل ایستایی را که معتبر می‌پنداشتید زیر پا بگذارد.

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

تخصیص‌دهندهٔ پویا به همان مدل نیاز دارد

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

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

تصمیم بگیرید نشانی سیاست است یا تسهیل

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

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