strongSwan vips: درخواست آدرس مجازی از IKEv2
vips یک آدرس داخلی IKEv2 درخواست میکند؛ دروازه تصمیم میگیرد چه چیزی اعطا کند. درخواست را پیکربندی کنید، آن را بارگذاری کنید و سپس بررسی کنید که پاسخدهنده واقعاً چه چیزی تخصیص داده است.
کلاینت IKEv2 شما میتواند از دروازه یک آدرس داخلی بخواهد و دروازه تصمیم میگیرد چه چیزی برگرداند. در strongSwan این درخواست همان تنظیم vips است و حتی وقتی آدرس مشخصی در آن مینویسید، همچنان یک درخواست میماند. راهنمای زیر درخواست را پیکربندی میکند، آن را بارگذاری میکند و آنچه برگشته را میخواند، چون این سه گام به سه روش مختلف شکست میخورند. هیچیک از آنها با محکمتر تایپ کردن کوتاهتر نمیشود.
vips چه میخواهد و چه چیزی را نمیتواند تضمین کند
vips به تعریف اتصال تعلق دارد و از پاسخدهنده یک آدرس مجازی میخواهد. راهنمای strongSwan درباره آدرسهای مجازی صریح میگوید که پاسخ میتواند آدرس دیگری باشد یا هیچ چیز، و این همان جملهای است که مردم وقتی مقداری مینویسند و انتظار دارند ظاهر شود از آن میگذرند. درخواست هنوز ارزش انجام دادن دارد، چون چیزی که بررسی میکنید پاسخ است. با تنظیم مانند دستوری برای پرسیدن رفتار کنید، نه مانند پیکربندی نتیجه.
درخواست 0.0.0.0 یعنی درخواست هر آدرس مجازی IPv4 موجود، که معمولاً وقتی مقدار دقیق اهمیت ندارد درست است. درخواست یک آدرس مشخص یک اشاره به دروازه است، نه یک تقاضا از آن.
قطعه swanctl و جای آن
این تنظیم داخل بلوک اتصال قرار دارد، نه در فایل خودش و نه در پروفایل سیستمعامل. این قطعه جدا شده شکل را نشان میدهد:
connections {
net {
local_addrs = 192.0.2.10
remote_addrs = 203.0.113.5
vips = 10.77.0.31
children {
net { local_ts = dynamic remote_ts = 10.77.0.0/24 }
}
}
}
آن را با فایلی که اتصال به آن تعلق دارد بارگذاری کنید، سپس اتصال را آغاز کنید و نتیجه را بخوانید. قطعهای که در بخش نادرست چسبانده شود خطای تجزیه تولید میکند یا بدتر، اتصالی که بدون درخواستی که فکر میکردید ساختهاید بارگذاری میشود. سه فرمان را به ترتیب اجرا کنید و خروجی را نگه دارید.
swanctl --load-all --file /etc/swanctl/swanctl.conf
swanctl --initiate --child net
swanctl --list-sas
local_ts ترافیک را انتخاب میکند، آدرس نمیسازد
local_ts مجموعه ترافیکی را نام میبرد که SA فرزند از آن محافظت میکند؛ آدرسی روی رابط قرار نمیدهد. پس از مذاکره یک IP مجازی، strongSwan استفاده از انتخابگر دینامیک پیشفرض خود را متوقف میکند و به جای آن از آدرس اعطاشده استفاده میکند. اگر انتخابگر را به یک آدرس تحتاللفظی سنجاق کنید، چیزی را ادعا میکنید که دروازه ممکن است اعطا نکرده باشد، و به همین دلیل خطا به صورت یک SA سالم با ترافیکی که به هیچجا نمیرود ظاهر میشود. انتخابگر ترافیک را توصیف میکند، در حالی که تخصیص از تبادل دیگر میآید.
راه دیگر برای داشتن یک آدرس داخلی پایدار این است که آن را به صورت محلی در اختیار داشته باشید. آدرس را پیش از بالا آمدن تونل روی یک رابط قرار دهید، انتخابگر را به آنچه از قبل وجود دارد نشانه بگیرید و همتا و مسیر را پیرامون آن ترتیب دهید.
در آن طراحی چیزی مذاکره نمیشود، پس چیزی نمیتواند دوباره تخصیص یابد، و این همان معاوضه است: جبرگرایی در ازای اینکه کار آدرسدهی را خودتان انجام دهید. این سازوکاری متفاوت است، نه گونهای از vips، و به همین دلیل نباید این دو در یک اتصال با هم مخلوط شوند. انتخابگر سنجاقشده در کنار آدرس مذاکرهشده اتصالی است که کار میکند تا زمانی که دروازه چیز دیگری توزیع کند.
بررسی کنید که پاسخدهنده واقعاً چه چیزی تخصیص داده است
فهرست SA را برای آدرسی که دروازه اعطا کرده بخوانید، سپس تأیید کنید که آدرس روی رابط وجود دارد. اگر آن دو با هم نمیخوانند، تونل بالا است و ترافیک به جایی که فکر میکنید نمیرود. آدرس اعطاشدهای که هرگز به رابط نمیرسد گیجکنندهترین خطا در این توالی است، چون هر نیمه به تنهایی درست به نظر میرسد.
چهار آدرس را در یادداشتهایتان جدا نگه دارید: آدرس داخلی درخواستشده، آدرس اعطاشده، آدرس LAN دستگاه و خروجی عمومی که یک وبسایت گزارش میکند. آنها به لایههای مختلف تعلق دارند و در جاهای مختلف ظاهر میشوند. راهنمایی که هر چهار مورد را ثبت میکند، راهنمایی است که شخص دیگری میتواند بدون پرسیدن اینکه منظورتان کدام آدرس بود آن را دنبال کند. آنها را پس از هر بار بارگذاری مجدد دوباره بخوانید، چون مقدار اعطاشده تنها چیزی است که تونل زنده را توصیف میکند.
طراحی ثابت را جدا نگه دارید
اگر به یک آدرس داخلی ثابت نیاز دارید، رزرو را روی دروازه ترتیب دهید و درخواست کلاینت را درخواست باقی بگذارید. ترکیب یک انتخابگر سنجاقشده با آدرس مذاکرهشده اتصالی میدهد که کار میکند تا زمانی که دروازه چیز دیگری تخصیص دهد. قاعده رزرو را کنار اتصال بنویسید، چون این همان بخشی است که همکار نمیتواند از فایل پیکربندی استنباط کند. سپس کلاینت جدید قاعده را به ارث میبرد به جای اینکه دوباره آن را کشف کند.
در کلاینت داخلی Mac هیچیک از این نامهای گزینه وجود ندارد. از هر تخصیص یا رزروی که دروازه ارائه میدهد و پروفایلی که اپراتور منتشر میکند استفاده کنید، و هر مقدار سمت کلاینت را تا زمانی که تخصیص را دوباره نخواندهاید یک اشاره بدانید. بازگردانی یعنی حذف خط vips و بارگذاری مجدد، که شما را به آنچه دروازه به طور پیشفرض تخصیص میدهد برمیگرداند.