WireGuard 5G برای شعبه: بگذارید شعبه خودش مرکز را صدا بزند

نشانه گرفتن یک شعبه به سمت مرکز، نیمهٔ آسان این طراحی است وقتی شعبه پشت یک نشانی همراه متغیر می‌نشیند و مرکز نامی پایدار دارد. آن‌گاه مرکز شعبه را از ترافیک تأییدشده می‌آموزد، نه از رکوردی که باید به‌روز نگهش دارید. قرارداد ساده است: همیشه شعبه آغاز می‌کند.

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

کدام طرف نقطهٔ پایانی پایدار را نگه می‌دارد

پیکربندی شعبه نقطهٔ پایانی و کلید عمومی مرکز را نام می‌برد. پیکربندی مرکز کلید عمومی شعبه و پیشوندهای داخلی مجاز آن را نام می‌برد و ممکن است هیچ نقطهٔ پایانی نداشته باشد، چون هویت از کلید می‌آید نه از نشانی مبدأ آخرین بسته. همین نامتقارنی کل سازوکار است و یک طبقهٔ کامل از مسئله‌های کشف را از سمت مرکز برمی‌دارد.

وقتی شعبه بستهٔ تأییدشده‌ای می‌فرستد، مرکز مبدأیی را که بسته از آن رسیده ثبت می‌کند و از همان نگاشت برای پاسخ‌ها استفاده می‌کند. آن‌وقت شماره‌گذاری دوبارهٔ پیوند همراه هیچ هزینه‌ای جز دست‌دادن بعدی ندارد و هر مؤلفه‌ای که دیگر لازم ندارید یکی است که در زمان جابه‌جایی نمی‌تواند از کار بیفتد. این ویژگی ارزش آزمودن در یک تغییر برنامه‌ریزی‌شده را دارد، نه در میان یک رخداد. آن را وقتی انجام دهید که کسی می‌تواند هر دو سر را هم‌زمان ببیند.

به شعبه پیکربندی‌ای بدهید که شماره‌گذاری دوباره را تاب بیاورد

نقطهٔ پایانی و keepalive را در شعبه نگه دارید و مدخل همتا در مرکز را از نشانی سخت‌کدشده خالی نگه دارید. keepalive نگاشت ترجمه‌شده را به‌قدر کافی باز نگه می‌دارد تا مرکز پس از یک دورهٔ بیکاری ترافیک ناخواسته بفرستد.

[Peer]
PublicKey = HUB_PUBLIC_KEY_BASE64
Endpoint = hub.example.net:51820
AllowedIPs = 10.60.0.0/24, 10.60.10.0/24
PersistentKeepalive = 25

بیست و پنج ثانیه مثالی است که برای زنده نگه داشتن نگاشت NAT زیاد نقل می‌شود، نه الزامی برای هر همتا. آن را بر پایهٔ مهلت نگاشتی که واقعاً می‌بینید تنظیم کنید و یادتان باشد تا وقتی واسط بالاست روی پیوندی با محدودیت داده ترافیک تولید می‌کند.

در مرکز، پیشوندهای مجاز همتای شعبه باید هر چیزی را که شعبه خواهد فرستاد بپوشاند. پیشوند غایب در سر دور مثل یک خطای مسیریابی رفتار می‌کند و در هیچ طرف هشداری تولید نمی‌کند، از همین رو ارزش بررسی پیش از نخستین بستهٔ واقعی را دارد. پیش از نخستین اتصال، پیشوندهای مجاز مرکز را با نشانی‌های واسط شعبه مقایسه کنید.

نگاشت و جابه‌جایی را بررسی کنید

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

wg show wg0
wg show wg0 latest-handshakes
ip route show default
ping -c 3 10.60.10.1

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

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

این طراحی چه چیزی را حل نمی‌کند

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

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

چهار چیز را در دفترچهٔ اجرا بنویسید: چه کسی آغاز می‌کند، کدام پیشوندها مجازند، keepalive چقدر است و وقتی پیوند اصلی می‌افتد چه می‌شود. همان سطرها چیزی است که اپراتور آینده در ساعت سه بامداد واقعاً لازم دارد.