چگونه یک استخر آدرس کلاینت VPN برنامه‌ریزی کنیم که جا بیفتد

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

از فیلد استخر شروع کنید، پیش از آنکه هیچ کلاینتی وصل شود

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

وقتی فیلد را دارید، بازه‌هایی را که از قبل وجود دارند فهرست کنید: LAN دفتر، هر سایت مسیریابی‌شده، VPC ابری و هر استخر دیگری که هنوز در سرویس است. همپوشانی با حساب پیشوند تعیین می‌شود، نه با اینکه شماره‌های میزبان آشنا به نظر برسند، پس تجمیع را با هر یک از آن بازه‌ها مقایسه کنید. دو بازه که هر دو شبیه 10.x هستند وقتی تجمیع‌هایشان همدیگر را قطع نمی‌کنند بی‌ضررند و وقتی قطع می‌کنند یک حادثه پشتیبانی‌اند.

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

آدرسی را که کلاینت واقعاً گرفت بخوانید

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

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

ip -4 addr show tun0
ip route get 192.168.50.20

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

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

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

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

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

دو کلاینت، سپس یک ابطال

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

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

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

چهار مقدار را همان‌جا بنویسید که تغییر بعدی آن‌ها را پیدا کند

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

یادداشت مالکیت را همراه آن نگه دارید: بازه تونل متعلق به سرور VPN است، و رزروی که در دامنه DHCP در LAN انجام شده برای کلاینتی درون تونل چیزی رزرو نمی‌کند. همان یک خط از شایع‌ترین دوباره‌کاری جلوگیری می‌کند، جایی که کسی رزروی اضافه می‌کند و انتظار دارد آدرس تونل از آن تبعیت کند.