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

به هیچ سایت نمی‌توان زنگ زد، پس هر دو باید به بیرون زنگ بزنند

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

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

دو فرمان به پرسش نشانی‌دهی سایت روبه‌رویتان پاسخ می‌دهند. آن‌ها را روی روتر سایت اجرا کنید، نه روی لپ‌تاپی در پشت آن:

ip -4 addr show scope global
ip -6 addr show scope global

چه کسی همتایان را معرفی می‌کند و چه کسی بسته‌ها را حمل می‌کند

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

عبور واژگان خودش را دارد، و واژه‌ها نقش‌ها را توصیف می‌کنند، نه تضمین‌ها. مشخصات ICE نامزدها و بررسی‌های اتصال را توصیف می‌کند، STUN یک راه برای آگاهی از ترجمه نشانی را توصیف می‌کند، و TURN انتقال رله‌شده را برای برنامه‌هایی که آن را پیاده می‌کنند توصیف می‌کند. هیچ‌یک از این سازوکارها در یک دروازه متعارف ظاهر نمی‌شود، چون آن را به نشانی کشف اشاره داده‌اید. عبور را به‌عنوان توانمندی محصول بررسی کنید و تا وقتی آزمون خلافش را نشان نداده فرض کنید رله در کار است.

یک مسیر برای هر سایت، متعلق به یک همتا

هاب به یک تونل برای هر سایت، یک پیشوند LAN متمایز پشت هر یک و یک مسیر برای هر پیشوند که مالکش را نام می‌برد نیاز دارد. در مثال هاب 10.61.0.1 است، سایت A با LAN 10.60.10.0/24 برابر 10.61.0.11 است، و سایت B با LAN 10.60.20.0/24 برابر 10.61.0.12 است. هر مسیر زیر به همتایی که مالک پیشوند است اشاره می‌کند، نه به رابط تونل:

ip route add 10.60.10.0/24 via 10.61.0.11 dev wg0
ip route add 10.60.20.0/24 via 10.61.0.12 dev wg0
sysctl net.ipv4.ip_forward
ip route get 10.60.20.55 from 10.60.10.77

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

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

هر نگاشت را از طریق اپراتور زنده نگه دارید

هر سایت تونل خودش را آغاز می‌کند و هر یک باید نگاشت ترجمه را زنده نگه دارد وگرنه اپراتور آن را فراموش می‌کند. پیام زنده‌نگه‌داری در سمت آغازگر آن نگاشت را میان دست‌دهی‌ها حفظ می‌کند. پیشوندهای مجاز را به نشانی هاب و LAN دوردست محدود کنید تا همتای به‌خطرافتاده نتواند پیشوندی را که مالکش نیست ادعا کند:

[Peer]
PublicKey = <hub public key>
Endpoint = 192.0.2.10:51820
AllowedIPs = 10.61.0.1/32, 10.60.20.0/24
PersistentKeepalive = 25

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

هر دو جهت را ثابت کنید، سپس بازیابی را ثابت کنید

بررسی جهت‌دار است، پس ping از A به B نیمی از طراحی را ثابت می‌کند و هیچ چیزی درباره مسیر بازگشت. مسیر پاسخ را با همان جست‌وجوی مبدأآگاه روی هاب بررسی کنید، سپس آزمون را از سوی دیگر تکرار کنید. دست‌دهی‌های تازه هم به شواهد تعلق دارند، چون تونلی که یک ساعت بیکار بوده ممکن است نگاشت کهنه را بیازماید:

wg show wg0 latest-handshakes
ping -c 3 10.60.20.55
traceroute -n 10.60.20.55

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

مقالات مرتبط