برنامهریزی IPv6 برای مرکز WireGuard دو سایت: پیشوند، همتاها، مسیرها
یک مرکز IPv6 خصوصی برای دو LAN را بررسی کنید: پیشوندی انتخاب کنید، نشانیهای تونل را رزرو کنید و سپس بگذارید AllowedIPs بیان کند کدام همتا مالک کدام زیرشبکه است.
دو LAN، یک مرکز WireGuard و یک طرح نشانی IPv6 که باید به سه پرسش جداگانه پاسخ دهد: کدام پیشوند، کدام نشانی به هر مسیریاب تعلق دارد و کدام همتا مالک کدام زیرشبکه است. اشتباه در یکی از آنها تونلی میسازد که دستدادن انجام میدهد و هیچچیز را مسیریابی نمیکند. طرح زیر یک طراحی خصوصی دو سایتی را به همین ترتیب پیش میبرد. عمداً دسترسی اینترنت از طریق IPv6 را فراهم نمیکند.
تصمیم بگیرید پیشوند برای چه کاری است
یک پیشوند محلی یکتا از fd00::/8 انتخاب طبیعی است وقتی هدف دسترسی خصوصی بین سایتها باشد. مستقل از اینکه کدام ارائهدهنده هر مکان را سرویس میدهد پایدار میماند و در جدول مسیریابی جهانی اعلام نمیشود، بنابراین نمیتواند شمارهگذاری داخلی شما را به اینترنت نشت دهد.
همین ویژگی محدودیت هم هست. یک ULA هیچ مسیر بازگشت عمومی نمیدهد، چون هیچ بالادستی نمیداند آن را به دروازه شما مسیریابی کند. اگر نیاز شامل خروج اینترنت از طریق IPv6 باشد، به این نیاز دارید تخصیصی از سوی ارائهدهندهای که آن را به شما مسیریابی میکند، و این یک تصمیم طراحی جداگانه با اندازه پیشوند خودش است.
فرض نکنید هر استقرار به /48 نیاز دارد. RFC 6177 از یک اندازه اجباری واحد برای سایت انتهایی فاصله گرفت، و اندازه درست از تعداد شبکههایی که اداره خواهید کرد پیروی میکند. ULA را با رویه RFC 4193 تولید کنید، نه با ابداع پیشوندی که سازمان دیگری هم ممکن است استفاده کند. نتیجه را پیش از پیکربندی هر دستگاهی در طرح نشانی بنویسید، چون پیشوندی که کسی ثبت نکرده باشد پیشوندی است که کسی دوباره استفاده میکند.
پیشوند را به نقشها تقسیم کنید
مثال زیر از fd7c:2e91:4a00::/48 استفاده میکند و جدول بر اساس جایی که هر بلوک نوشته میشود سازمان یافته، نه بر اساس سایت. مقادیر را نمونه بگیرید و پیش از هر استقراری مقادیر خودتان را تولید کنید.
| Where it is written | What appears there | Block used | What it establishes |
|---|---|---|---|
| Hub wg0.conf, interface address | A single host address on the tunnel | fd7c:2e91:4a00:ff00::1/128 | The hub's own tunnel identity |
| Hub wg0.conf, Site A peer | Two ranges in one AllowedIPs line | ::2/128 and :10::/64 | That A owns its tunnel address and its LAN |
| Hub wg0.conf, Site B peer | Two ranges in one AllowedIPs line | ::3/128 and :20::/64 | That B owns its tunnel address and its LAN |
| Site A wg0.conf, interface address | A single host address on the tunnel | fd7c:2e91:4a00:ff00::2/128 | A's identity as the hub sees it |
| Site B wg0.conf, interface address | A single host address on the tunnel | fd7c:2e91:4a00:ff00::3/128 | B's identity as the hub sees it |
بلوکهای LAN برابر /64 هستند چون SLAAC معمولی شناسه واسط 64 بیتی انتظار دارد. تقسیم یک LAN به بلوک کوچکتر آن فرض را در بیشتر میزبانها میشکند و هزینه عملیاتی در یک طرح خصوصی ارزش صرفهجویی نشانی را ندارد. هر دو بلوک LAN از میانه /48 میآیند و بازه پایین را برای سایتهای بعدی آزاد میگذارند.
نشانیهای تونل یک سبد اداری هستند، نه شبکه روی پیوند. هر واسط یک /128 از آن میگیرد، بنابراین هیچ میزبانی زیرشبکه مشترک روی تونل را فرض نمیکند و کشف همسایه در جایی که لازم نیست اجرا نمیشود. نقشها را جدا نگه دارید و آنها را در طرح نشانی سازمان ثبت کنید تا سایت بعدی بلوکی را دوباره استفاده نکند.
به هر مسیریاب یک نشانی تونل بدهید
به هر مسیریاب یک /128 اختصاص دهید و کلیدها و نقاط پایانی موجود مرکز فعال را نگه دارید. سه مقدار زیر فقط در بخش میزبان تفاوت دارند.
Hub: Address = fd7c:2e91:4a00:ff00::1/128
Site A: Address = fd7c:2e91:4a00:ff00::2/128
Site B: Address = fd7c:2e91:4a00:ff00::3/128
این /128 تنها نشانی اختصاصیافته به آن واسط را توصیف میکند. درباره اینکه همتا چند مقصد را میتواند مسیریابی کند چیزی نمیگوید، چون دسترسیپذیری در AllowedIPs بیان میشود نه در پیشوند واسط.
هر مسیریاب سایت هم به نشانیای در بلوک LAN خودش و راهی برای توزیع آن نیاز دارد، معمولاً اعلانهای مسیریاب برای SLAAC. WireGuard آن اعلانها را به جای شما نمیفرستد و دو LAN را پل نمیزند. مسیریاب سایت در هر دو جهت یک مسیریاب است.
مالکیت زیرشبکه را در AllowedIPs بگذارید
ورودی همتای مرکز برای سایت A مالک نشانی تونل A و LAN سایت A است و همین جفت کل بیانیه مالکیت است. هیچ چیز دیگری در آن بخش همتا لازم نیست سایت را توصیف کند.
AllowedIPs = fd7c:2e91:4a00:ff00::2/128, fd7c:2e91:4a00:10::/64
ورودی همتا برای سایت B مالک جفت متناظر است و تقارن در اینجا از اختصار مهمتر است. دو خط را با هم بخوانید تا تقسیم مالکیت در یک نگاه دیده شود.
AllowedIPs = fd7c:2e91:4a00:ff00::3/128, fd7c:2e91:4a00:20::/64
اینها دو بخش همتای جداگانهاند، نه دو فهرست که برای یک همتا رقابت میکنند. WireGuard از AllowedIPs در هر دو جهت استفاده میکند: همتا را برای مقصد خروجی انتخاب میکند و بسته ورودیای را که منبعش با محدودهای که به همتای رمزگشاییکننده اختصاص یافته مطابقت ندارد رد میکند. دادن کل /48 به هر دو همتا آن بررسی دوم را غیرفعال میکرد و مبهم میساخت کدام سایت مالک کدام بلوک است. همین تمایز است که نشانی منبع نادرست را به جای پذیرش خاموش، آشکار میکند.
هر سایت فقط به مقصدهایی نیاز دارد که از طریق همتای مرکزش قابل دسترسیاند: سایت A نشانی مرکز، نشانی تونل سایت B و LAN آن را فهرست میکند و سایت B مجموعه متقابل را فهرست میکند. فهرستها عمداً نامتقارناند، چون هر مسیریاب طرف متفاوتی از توپولوژی را میبیند. هر دو را از طرح نشانی بنویسید نه از پیکربندی سایت دیگر، چون اینگونه است که یک محدوده کهنه از شمارهگذاری دوباره جان سالم به در میبرد.
با wg-quick این محدودهها مسیر هم میسازند. با systemd-networkd یا راهاندازی دستی، مسیرهای معادل را خودتان اضافه کنید؛ وگرنه تونل بستههایی را حمل میکند که کرنل هرگز به داخل آن نمیفرستد.
ارسال را کامل کنید و هر دو جهت را آزمایش کنید
ارسال IPv6 را روی مرکز و هر دو مسیریاب سایت فعال کنید و سرویسهای لازم بین سایتها را در سیاست ارسال مجاز کنید. پیامهای ICMPv6 Packet Too Big را قابل استفاده نگه دارید، چون دور ریختن آنها کشف MTU مسیر را میشکند و توقفهای انتقال بزرگ ایجاد میکند که شبیه نقص برنامه به نظر میرسد. مرکزی که بدون مجوز دیوار آتش ارسال میکند بسته را بین مسیریابی و تونل دور میریزد. این حالت خرابی ارزش دانستن دارد، چون تونل بالا میماند و فقط برخی جریانها از بین میروند.
sysctl net.ipv6.conf.all.forwarding
ip -6 route
ping -6 -c 3 fd7c:2e91:4a00:20::1
از میزبانی در سایت A به میزبانی در سایت B و سپس در جهت مخالف آزمایش کنید. ping به نشانی تونل مرکز فقط اولین گام را تمرین میدهد و حتی وقتی مسیرهای LAN اشتباه باشند موفق میشود. جریان میزبانبهمیزبان همان چیزی است که طرح را اثبات میکند.
اتصال بیرونی WireGuard میتواند روی IPv4 اجرا شود در حالی که ترافیک داخلی IPv6 است، و این استقلال در زمان مهاجرت مفید است. اگر بعداً خروج جهانی IPv6 اضافه شود، تخصیص ارائهدهنده، انتخاب نشانی مبدأ و مسیریابی بازگشت را به عنوان گام طراحی جدید بازبینی کنید؛ طرح خصوصی بالا برای ترافیک سایتبهسایت معتبر میماند.