سرور OpenVPN با nopool: یک بازه صریح برای استخر اعلام کنید
زیرشبکه را نگه دارید و تخصیص را خود بر عهده بگیرید. استخر خودکار را غیرفعال کنید، کرانه‌های شامل را اعلام کنید و بررسی کنید که یک کارخواه تازه واقعاً چه می‌گیرد.
ابزارهای کمکی سرور یک زیرشبکه را پیکربندی می‌کنند و سپس آن را با استخری پویا به انتخاب خود پر می‌کنند. این پیش‌فرض تا زمانی راحت است که برخی نشانی‌ها باید بیرون از تخصیص بمانند، چه برای تخصیص‌های ثابت کنار گذاشته شوند و چه برای بخشی در آینده نگه داشته شوند. غیرفعال کردن استخر خودکار و اعلام بازه به دست خودتان دو خط و یک تصمیم آگاهانه درباره اینکه کدام نشانی‌ها برای تخصیص نیستند می‌خواهد. باقی کار انضباط عملیاتی است: فهرست‌برداری، اعمال، بررسی، بازگردانی.
این تغییری در سرویسی در حال کار است، پس آن را وظیفه‌ای عملیاتی بدانید: نخست فهرست‌برداری، اعمال از طریق چرخه عمر معمول، بررسی با یک کارخواه تازه و نگه داشتن یک بازگردانی.
از همان زیرشبکه‌ای که دارید شروع کنید
پیکربندی کنونی سرور و نشانی‌هایی را که کارخواهان واقعاً در اختیار دارند بخوانید. تغییر استخر تنها در برابر همین مبنا معنا دارد، و مبنا همیشه همان چیزی نیست که پرونده پیشنهاد می‌کند، زیرا یک محصول مدیریت‌شده یا یک تولیدکننده پیکربندی می‌تواند مالک پرونده‌ای باشد که می‌خوانید.
grep -nE '^(topology|server|ifconfig-pool|max-clients|client-config-dir)' /etc/openvpn/server/lab.conf
ip -4 addr show tun0توپولوژی جاری را تأیید کنید. در توپولوژی زیرشبکه هر کارخواه یک نشانی از استخر می‌گیرد؛ چیدمان‌های قدیمی‌تر net30 برای هر کارخواه بلوکی کوچک تخصیص می‌دهند و حساب‌وکتاب کاملاً متفاوت است. اگر سرور هنوز روی net30 است، این صفحه راهنمای مهاجرت اشتباهی است و شماره‌های استخر معنایی که انتظار دارید نخواهند داشت. پیش از کپی کردن حساب‌وکتاب نشانی از جای دیگر، آن خط را بررسی کنید.
نشانی خود سرور، هر تخصیص ثابت در پوشه پیکربندی کارخواهان، و هر نشانی‌ای که مسیر یا قاعده دسترسی به آن وابسته است را بنویسید. این‌ها نشانی‌هایی هستند که باید بیرون از بازه پویا بمانند. نخست نوشتن آن‌ها همان چیزی است که بازه را به تصمیم تبدیل می‌کند نه حدس. همچنین به بازگردانی چیزی مشخص برای بازگرداندن می‌دهد.
nopool را بیفزایید و بازه را اعلام کنید
کلیدواژه کمکی nopool را می‌پذیرد، که پیکربندی زیرشبکه را نگه می‌دارد و استخر پویای خودکار را غیرفعال می‌کند، همان‌گونه که راهنمای OpenVPN 2.6 توضیح می‌دهد. سپس خط صریح ifconfig-pool بازه شامل مورد نظر شما را تأمین می‌کند و ماسک شبکه‌اش با زیرشبکه می‌خواند. هر دو خط به یک بلوک سرور تعلق دارند، زیرا استخری بدون زیرشبکه‌اش معنایی ندارد. ترتیب میان آن‌ها تنها برای خوانایی مهم است، چون ابزار کمکی هنگام آغاز سرویس این جفت را گسترش می‌دهد.
topology subnet
server 10.70.0.0 255.255.255.0 nopool
ifconfig-pool 10.70.0.50 10.70.0.120 255.255.255.0هر دو کرانه شامل هستند، پس نمونه هفتاد و یک نشانی عرضه می‌کند. نشانی سرور و هر تخصیص ثابت را بیرون از این گستره نگه دارید؛ تخصیص ثابتی که درون بازه پویا بیفتد برخوردی پدید می‌آورد که به ترتیب اتصال وابسته است، و این بدترین نوع برای عیب‌یابی است. اگر تخصیص‌های ثابت احتمال رشد دارند، میان مجموعه رزروشده و بازه حاشیه‌ای بگذارید.
اندازه بازه و هم‌زمانی دو محدودیت جدا هستند. صد نشانی به معنای صد کارخواه هم‌زمان نیست اگر max-clients چیز دیگری بگوید، و استخری بزرگ‌تر از محدودیت هم‌زمانی طبیعی است نه اسراف. مهم این است که دو محدودیت آگاهانه انتخاب شوند نه اینکه از یک پیش‌فرض به ارث برسند.
تخصیص‌های ثابت را بیرون از بازه پویا نگه دارید
ifconfig-push ویژه یک کارخواه سازوکاری متفاوت از تخصیص استخر است و باید پارامترهای مناسب توپولوژی فعال را به کار ببرد. در حالت زیرشبکه یک نشانی و ماسک شبکه است؛ انتقال یک جفت net30 به این دلیل که در نمونه‌ای قدیمی آمده بود، خطایی رایج است.
تاریخ تخصیص یک نشانه است، نه مرجع. پرونده persist به یاد می‌آورد کدام کارخواه کدام نشانی را داشته، بنابراین کارخواهانی که دوباره وصل می‌شوند معمولاً همان را می‌گیرند، و این پرونده نشانی‌ها را رزرو نمی‌کند، آزاد نمی‌کند و جای تخصیص ثابت را نمی‌گیرد. اگر دستگاه مشخصی باید همیشه نشانی مشخصی داشته باشد، به جای تکیه بر پرونده persist از تخصیص ثابت استفاده کنید.
سپس مسیرهایی را که به نشانی‌ها وابسته‌اند بررسی کنید. مسیری که به کارخواهان فرستاده می‌شود، قاعده‌ای در دیوار آتش که زیرشبکه‌ای را می‌پذیرد، یا بررسی پایشی که میزبان مشخصی را انتظار دارد، همه ممکن است بازه قدیمی را فرض کنند. تغییر استخر بدون خواندن آن‌ها خرابی را به جایی می‌برد که بی‌ربط به نظر می‌رسد.
از طریق چرخه عمر اعمال کنید، سپس بررسی کنید
تغییر را همان‌گونه اعمال کنید که سرویس معمولاً پیکربندی می‌گیرد — چه پرونده مستقیم به‌همراه راه‌اندازی دوباره، چه لایه مدیریتی‌ای که پرونده را دوباره تولید می‌کند. ویرایش دستی روی پرونده تولیدشده تا تولید بعدی دوام می‌آورد و نه بیشتر. ثبت کنید کدام سازوکار مالک پرونده است، زیرا گرداننده بعدی باید بداند همان تغییر را کجا انجام دهد. سپس یک بار راه‌اندازی دوباره کنید و پیش از دعوت کارخواه، گزارش را بخوانید.
systemctl restart openvpn-server@lab
journalctl -u openvpn-server@lab -n 30 --no-pager
# on a fresh client
ip -4 addr show tun0کارخواهی را وصل کنید که پیش‌تر وصل نشده بود و تأیید کنید که نشانی درون بازه اعلام‌شده و بیرون از مجموعه رزروشده می‌افتد. سپس مسیر بازگشت را تأیید کنید: کارخواه باید به آنچه سیاست اجازه می‌دهد برسد و نه بیشتر. نشانی‌ای که با نقشه می‌خواند اما مسیر کارآمدی ندارد تغییری موفق نیست.
کارخواهی را دوباره وصل کنید که نشانی‌ای از بازه قدیمی داشت. باید نشانی‌ای از بازه جدید بگیرد و هر وضعیت سطح نشستی که به نشانی قدیمی بسته بود باید از میان رفته باشد. اگر نشانی قدیمی را نگه می‌دارد، چیز دیگری آن را تخصیص می‌دهد و استخر مالکی نیست که فکر می‌کنید.
بازگردانی یک تغییر بازه
سه خط پیشین را در سابقه تغییر خود نگه دارید، نه فقط پرونده پیشین را. بازگرداندن آن‌ها و راه‌اندازی دوباره تخصیص را به رفتار قدیمی برمی‌گرداند و کارخواهانی که پس از آن وصل شوند نشانی‌هایی از آن خواهند گرفت.
دو هشدار به سابقه تعلق دارد. کارخواهانی که هنگام بازگردانی از پیش وصل هستند نشانی‌های کنونی خود را تا وقتی دوباره وصل نشوند نگه می‌دارند، پس بازگردانی در کل ناوگان آنی نیست. و اگر بازه قدیمی با تخصیص ثابتی هم‌پوشانی داشت، بازگرداندن آن هم‌پوشانی را نیز بازمی‌گرداند؛ همان هم‌پوشانی دلیل این تغییر بود و به اصلاحی جز بازگردانی نیاز دارد.
تغییر استخر زمانی تمام است که کارخواه تازه نشانی‌ای درون بازه بگیرد، نشانی رزروشده هرگز داده نشود، و مسیرها و قواعدی که آن نشانی‌ها را مصرف می‌کنند همچنان همان‌گونه که مقصود است رفتار کنند. هر چیز کمتر، کشف اینکه کدام یک از این سه نادرست است را به نفر بعد واگذار می‌کند.