آدرس‌های ثابت کلاینت OpenVPN پشت OPNsense

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

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

اجاره چسبنده یک آدرس ثابت نیست

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

جایگزین پویا، یعنی وصل کردن VPN به DNS با اسکریپت client-connect و به‌روزرسانی‌های پویا، کار می‌کند و به یک resolver نیاز دارد که به‌روزرسانی‌ها را بپذیرد، به‌همراه یک اسکریپت در هر اتصال. روی یک دستگاه به بسته‌هایی محدود هستید که فروشنده عرضه می‌کند، و معمولاً همان‌جا آن طرح متوقف می‌شود.

حساب /30 که هیچ‌کس از آن لذت نمی‌برد

در توپولوژی پیش‌فرض net30، هر کلاینت /30 خودش را می‌گیرد: نخستین آدرس قابل استفاده به سمت سرور می‌رود، دومی به کلاینت. بنابراین بازنویسی‌ها باید بیرون از شبکه تونل پویای سرور باشند، که یعنی نخست آن شبکه را پهن‌تر کنیم. سروری روی 10.8.0.0/24 می‌تواند به 10.8.0.0/23 برود و نیمی از محدوده قدیمی را برای کلاینت‌های پویا و نیم دیگر را برای بازنویسی‌ها بگذارد. شبکه /24 اصلی را به‌عنوان یک شبکه محلی IPv4 اضافی اضافه کنید تا ترافیک هر دو نیمه به داخل تونل مسیریابی شود.

هر آدرس بازنویسی باید روی مرز /30 بیفتد، پس آخرین اکتت مضربی از چهار است. یک /30 روی 10.8.1.0 به کلاینت 10.8.1.2 می‌دهد، و همان آدرسی است که رکورد DNS حمل می‌کند. انتخاب 10.8.1.3 به‌جای آن کلاینتی می‌سازد که وصل می‌شود و نمی‌تواند ترافیک را عبور دهد، چون آدرس به زیرشبکه‌ای تعلق دارد که توپولوژی هرگز به آن اختصاص نداده است.

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

شبکه‌های محلی و ناحیه‌ای که کلاینت‌ها پرس‌وجو می‌کنند

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

رکوردها را در ناحیه‌ای منتشر کنید که کلاینت‌های دور واقعاً پرس‌وجو می‌کنند. رکورد در ناحیه‌ای که فقط resolver محلی (LAN) آن را سرو می‌کند برای کلاینتی که resolver ارسال‌شده‌اش جای دیگری را نشان می‌دهد نامرئی است، و افزودن رکوردهای بیشتر به ناحیه اشتباه هرگز آن را درست نمی‌کند. پیش از افزودن هر چیزی، گزینه DNS ارسال‌شده و دامنه جست‌وجو را تأیید کنید.

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

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

گواهی‌ای که با نام مشترک دیگری دوباره صادر شود دیگر با بازنویسی خود نمی‌خواند و کلاینت را به pool پویا برمی‌گرداند. بعد از هر تغییر هویت این را انتظار داشته باشید.