استخر در اتصال مجدد بعدی کدام نشانی را میدهد؟
نشانیهای استخر از ترتیبی پیروی میکنند که تصادفی نیست: نخست نشانی بهیادمانده، سپس نشانی آزادی که بیشترین زمان بیاستفاده بوده است. پیش از تثبیت یک قاعده آن را بخوانید.
قاعدهای که دیروز مطابقت داشت امروز دیگر مطابقت ندارد، چون کارخواه با نشانی تونل دیگری بازگشت. تخصیصدهنده اما تصادفی نیست، و دانستن ترتیب آن این غافلگیری را به رخدادی قابل پیشبینی تبدیل میکند. او نشانیای را ترجیح میدهد که همان کارخواه پیشتر داشت، به نشانی آزادی که بیشترین زمان بیاستفاده مانده بازمیگردد، و همه چیز را فراموش میکند مگر جایی برای بهیادسپاری به او بدهید. قاعدههایی که بر اجاره تکیه دارند تا روزی که بیصدا متوقف میشوند به مطابقت ادامه میدهند.
ترتیبی که تخصیصدهنده دنبال میکند
با یک نشست برای هر common name، تخصیصدهنده نخست نشانیای را میجوید که همان کارخواه پیشتر استفاده کرده و اکنون آزاد است. اگر آن نشانی رفته باشد، نشانی آزادی را برمیدارد که بیشترین زمان بیفعالیت بوده است. وقتی برای همان نام نشستهای همزمان فعال باشد، ترجیح نشانی پیشین اعمال نمیشود و بهجای آن نخستین نشانی آزاد استفاده میشود، چون نشستها بهعنوان همتاهای جداگانه رفتار میشوند.
| Situation | Address chosen | Practical effect |
|---|---|---|
| Reconnect, old address still free | The remembered address | Rules appear stable for days |
| Old address taken by another client | Least recently used free address | A working rule silently stops matching |
| Concurrent sessions, same name | First free address, per session | One identity can hold several leases |
از این دو پیامد بیدرنگ برمیآید. کارخواهی که سریع دوباره متصل میشود معمولاً نشانی خود را نگه میدارد، و از همین رو کسی سازوکار را تا زمانی که تغییر نکند نمیبیند. و دستگاه دیگری که در آن پنجره کوچک متصل شود میتواند نشانی را در حالی که کوتاهمدت آزاد است بگیرد، و پس از آن کارخواه نخست چیز دیگری میگیرد و هر قاعدهای که بر شماره قدیمی بنا شده نادرست است. هیچیک از این دو رخداد سطری در گزارش نمیسازد که شبیه خرابی باشد.
چرا اجاره پایدار به نظر میرسد و سپس جابهجا میشود
پایداری اینجا ویژگی برآمده از اتصالهای مجددی است که پیش از آنکه کسی دیگر نشانی را طلب کند میرسند. این یک وعده نیست، و تا وقتی کارخواه قطع است اعمال نمیشود. برای تغییر نشانی برنامه بریزید، نه اینکه از آن غافلگیر شوید. استخری که بهسختی از شمار دستگاهها بزرگتر است برخوردها را عادی میکند، چون گزینه جایگزین نشانی با بیشترین زمان بیاستفاده تقریباً چیزی برای انتخاب ندارد.
همزمانی اوج عددی است که باید بر پایه آن اندازهگیری کرد، نه شمار کاربران. کسی که همزمان از دو دستگاه آزمون میکند، یا کارخواهی که پیش از پایان نشست قدیم دوباره متصل میشود، مدتی دو اجاره را اشغال میکند. استخری که تنها بر پایه شمار افراد اندازهگیری شده باشد دقیقاً همان جابهجایی را پدید میآورد که مردم آن را به گردن کارساز میاندازند.
پرونده ماندگاری بهیاد میسپارد، رزرو نمیکند
نشانیای که از راهاندازی مجدد سرویس جان سالم به در میبرد به پرونده ماندگاری نیاز دارد. این پرونده هنگام خاموشی نام کارخواه و نشانی را ذخیره میکند و هنگام آغاز سرویس دوباره میخواند، از همین رو راهاندازی مجدد برنامهریزیشده دیگر همه قاعدههایی را که نوشتهاید بههم نمیریزد.
ifconfig-pool-persist /etc/openvpn/ipp.txt
server 10.8.0.0 255.255.255.0
آنچه نمیکند این است که نشانی را در غیاب کارخواه نگه دارد. در آن فاصله تخصیصدهنده آزاد است شماره را به کس دیگری بدهد، و پرونده آنگاه ترجیحی کهنه را ثبت میکند که اتصال بعدی نمیتواند آن را برآورده کند. با آن مانند نشانهای رفتار کنید که رفتار راهاندازی مجدد را بهتر میکند، نه مانند نشانیدهی ایستا.
استخر را در حالی که در پرونده هستید با هر زیرشبکه مسیریابیشده بسنجید. بازه همپوشان نشانیهایی میدهد که کارساز نمیتواند به آنها مسیریابی کند، و نشانه آن کارخواهی است که متصل میشود، نشانی میگیرد و به جایی نمیرسد.
تثبیت درست یک نشانی
وقتی قاعده دیوار آتش یا رکورد DNS واقعاً به نشانی ثابت نیاز دارد، آن را تعیین کنید نه اینکه امیدوار باشید. مدخل پیکربندی برای هر کارخواه میتواند نشانی و ماسک را مستقیم بفرستد، و آن مدخل بر نام مؤثر کارخواه کلید خورده است.
# client-config-dir entry for "laptop-acme"
ifconfig-push 10.8.0.50 255.255.255.0
نشانیهای ثابت را بیرون از استخر پویا نگه دارید تا تخصیصدهنده هرگز همان شماره را به نشست دیگری ندهد. سپس توپولوژی تونل را بررسی کنید، چون تغییر میدهد که هر کارخواه چند نشانی استخر مصرف میکند: چیدمان قدیمی نقطهبهنقطه برای هر کارخواه یک بلوک کوچک مصرف میکند، در حالی که چیدمان زیرشبکه برای هر یک یک نشانی به کار میبرد. استخری که در یک توپولوژی سخاوتمند به نظر میرسد میتواند در دیگری تهیکننده باشد.
نتیجه را روی کارخواه تأیید کنید نه اینکه به حسابداری کارساز اعتماد کنید. وقتی نشست برگشت، به نشانی رابط و مسیر فرستادهشده نگاه کنید، چون گزارش روی کارساز میتواند نشانی درخواستشده را بگوید در حالی که رابط خودش نشانی دیگری دارد.
نشانی دوردست پرسشی جداگانه است
نشانی در خط remote کارخواه باید پیش از وجود هر تونلی قابل دسترس باشد. گذاشتن نشانی استخر در آنجا، مثلاً نقطه پایانی تونل خود کارساز، یعنی کارخواه میکوشد از راه تونلی که هنوز نساخته به نقطه پایانی برسد، و نتیجه حلقه یا انتظار خاموش است نه میانبر.
از نقطه پایانی عمومی که اپراتور فراهم کرده استفاده کنید، و استخر را برای آنچه برایش طراحی شده نگه دارید: نشانیهای درون تونل. ثبت بازه استخر، تخصیصهای ثابت و مسیر ماندگاری در یک جا شخص بعدی را از برخورد با هر اجاره بهعنوان چیزی دلبخواه بینیاز میکند.