WireGuard در فضای نام شبکه: چرا سوکت عقب ماند

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

نشانه: فضای نام درست، بدون بسته

درون فضای نام، تونل سالم به نظر می‌رسد. دستگاه وجود دارد، نشانی‌ها تخصیص یافته‌اند و پیکربندی همتا حاضر است. در بیرون، تبادل UDP مورد انتظار هرگز روی رابطی که زیر نظر داشتید ظاهر نمی‌شود و طرف مقابل گزارش می‌دهد که هیچ دست‌دهی رخ نداده است.

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

این نه ایرادی در جابه‌جایی است و نه پیکربندی نادرست همتا. پیاده‌سازی هسته همین کار را می‌کند و مستندات فضای نام برای WireGuard مستقیماً قاعده ساخت را توضیح می‌دهد.

چرا سوکت زادگاه دارد

یک دستگاه WireGuard یک سوکت UDP برای انتقال رمزنگاری‌شده‌اش دارد و آن سوکت در همان فضای نامی باز می‌شود که دستگاه در آن ساخته می‌شود. جابه‌جایی رابط با فرمان پیوند، دستگاه دیدنی را جابه‌جا می‌کند اما انتقال را همان‌جا که آغاز شده بود رها می‌کند. آن‌گاه دو شیء مالکان متفاوتی دارند.

پیامد آسان از چشم می‌افتد، چون دو نیمه در جاهای مختلف بررسی می‌شوند. مسیر درونی در فضای نامی که برنامه در آن اجرا می‌شود تعیین می‌شود و مسیر بیرونی در جایی تعیین می‌شود که سوکت زندگی می‌کند. بررسی تنها یکی از آن‌ها نتیجه‌ای مطمئن اما نادرست می‌دهد. بررسی هر دو معمولاً پژوهش را در یک گذر پایان می‌دهد.

آن را همان‌جا بسازید که سوکت را می‌خواهید

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

ip netns exec vpn-apps ip link add wg-demo type wireguard
ip netns exec vpn-apps wg show

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

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

دو سوی مسیر را بخوانید

وقتی دستگاه در جای درست است، دو تصمیم را جداگانه بررسی کنید. با جست‌وجوی درونی از بافت برنامه آغاز کنید و سپس مسیر بیرونی را از بافتی که مالک سوکت است بررسی کنید:

ip netns exec vpn-apps ip route get 10.30.0.9
ip netns exec vpn-apps wg show
tcpdump -ni any udp port 51820

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

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