Планиране на IPv6 за WireGuard хъб с два обекта: префикс, партньори, маршрути

Две LAN, един WireGuard хъб и план за IPv6 адреси, който трябва да отговори на три отделни въпроса: кой префикс, кой адрес принадлежи на всеки рутер и кой партньор притежава коя подмрежа. Ако едно от тях е грешно, получавате тунел, който прави ръкостискане и не маршрутизира нищо. Планът по-долу преминава през частен дизайн за два обекта в този ред. Той умишлено не предоставя интернет достъп през IPv6.

Решете за какво служи префиксът

Уникално локален префикс от fd00::/8 е естественият избор, когато целта е частна достижимост между обекти. Той остава стабилен независимо кой доставчик обслужва всяко място и не се обявява в глобалната таблица за маршрутизация, така че не може да изтече вътрешната ви номерация в интернет.

Същото свойство е и ограничението. ULA не дава публичен обратен път, защото никой upstream не знае да го маршрутизира към вашия шлюз. Ако изискването включва изход в интернет през IPv6, имате нужда от разпределение от доставчик, който го маршрутизира към вас, и това е отделно проектно решение със собствен размер на префикса.

Не приемайте, че всяко внедряване се нуждае от /48. RFC 6177 се отдалечи от единен задължителен размер за краен сайт и правилният размер следва броя мрежи, които ще управлявате. Генерирайте ULA с процедурата RFC 4193, вместо да измисляте префикс, който друга организация също може да използва. Запишете резултата в плана за адреси, преди да е конфигурирано каквото и да е устройство, защото префикс, който никой не е записал, е префикс, който някой ще използва повторно.

Разделете префикса на роли

Примерът по-долу използва fd7c:2e91:4a00::/48 и таблицата е организирана по това къде се записва всеки блок, а не по обект. Приемайте стойностите като пример и генерирайте свои, преди да внедрите нещо.

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, а обект 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, преразгледайте разпределението от доставчика, избора на адрес на източника и обратната маршрутизация като нова стъпка в проектирането; частният план по-горе остава валиден за трафик между обекти.