Planificación de IPv6 para un concentrador WireGuard de dúas sedes: prefixo, pares, rutas

Dúas LAN, un concentrador WireGuard e un plan de enderezos IPv6 que debe responder tres preguntas distintas: que prefixo, que enderezo pertence a cada encamiñador e que par é dono de que subrede. Un erro en calquera delas produce un túnel que fai o aperto de man e non encamiña nada. O plan seguinte percorre un deseño privado de dúas sedes nesa orde. Deliberadamente non proporciona acceso a Internet por IPv6.

Decida para que serve o prefixo

Un prefixo local único de fd00::/8 é a elección natural cando o obxectivo é a conectividade privada entre sedes. Permanece estable independentemente de que provedor atende cada localización e non se anuncia na táboa de encamiñamento global, así que non pode filtrar a súa numeración interna a Internet.

A mesma propiedade é a limitación. Unha ULA non ofrece ningunha ruta de retorno pública, porque ningún provedor superior sabe encamiñala cara á súa pasarela. Se o requisito inclúe saída a Internet por IPv6, necesita unha asignación dun provedor que lla encamiñe, e esa é unha decisión de deseño aparte co seu propio tamaño de prefixo.

Non asuma que todo despregamento necesita un /48. RFC 6177 afastouse dun único tamaño obrigatorio para a sede final, e o tamaño correcto depende do número de redes que vaia operar. Xere a ULA co procedemento RFC 4193 en vez de inventar un prefixo que outra organización tamén podería usar. Escriba o resultado no plan de enderezos antes de configurar calquera dispositivo, porque un prefixo que ninguén rexistrou é un prefixo que alguén reutilizará.

Divida o prefixo en roles

O exemplo seguinte usa fd7c:2e91:4a00::/48, e a táboa está organizada por onde se escribe cada bloque, non por sede. Trate os valores como unha mostra e xere os seus antes de despregar nada.

Os bloques LAN son /64 porque o SLAAC ordinario espera un identificador de interface de 64 bits. Dividir unha LAN nun bloque menor rompe esa suposición na maioría dos equipos, e o custo operativo non compensa o aforro de enderezos nun plan privado. Ambos os bloques LAN proveñen do centro do /48, deixando o rango baixo libre para sedes posteriores.

Os enderezos de túnel son un depósito administrativo, non unha rede no enlace. Cada interface recibe unha única /128 del, así que ningún equipo supón unha subrede compartida no túnel e non se executa descubrimento de veciños onde non fai falta. Manteña os roles disxuntos e rexístreos no plan de enderezos da organización para que unha sede posterior non reutilice un bloque.

Dea a cada encamiñador un enderezo de túnel

Asigne unha /128 por encamiñador e conserve as claves e os extremos existentes do concentrador que funciona. Os tres valores seguintes só difiren na parte do equipo.

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

Esta /128 describe o único enderezo asignado a esa interface. Non di nada sobre cantos destinos pode encamiñar o par, porque a conectividade exprésase en AllowedIPs e non no prefixo da interface.

Cada encamiñador de sede tamén necesita un enderezo no seu bloque LAN e unha forma de distribuílo, normalmente anuncios de encamiñador para SLAAC. WireGuard non envía eses anuncios por vostede e non une as dúas LAN. O encamiñador de sede é un encamiñador en ambos os sentidos.

Pon a propiedade da subrede en AllowedIPs

A entrada de par do concentrador para a Sede A posúe o enderezo de túnel de A e a LAN de A, e ese emparellamento é toda a declaración de propiedade. Nada máis nesa sección de par necesita describir a sede.

AllowedIPs = fd7c:2e91:4a00:ff00::2/128, fd7c:2e91:4a00:10::/64

A entrada de par para a Sede B posúe o par correspondente, e aquí a simetría importa máis que a brevidade. Lea as dúas liñas xuntas e a división de propiedade vólvese visible dunha ollada.

AllowedIPs = fd7c:2e91:4a00:ff00::3/128, fd7c:2e91:4a00:20::/64

Son dúas seccións de par separadas, non dúas listas que compiten por un par. WireGuard usa AllowedIPs en ambos os sentidos: escolle o par para un destino saínte e rexeita un paquete entrante cuxa orixe non coincide co rango asignado ao par que o descifrou. Dar todo o /48 aos dous pares desactivaría esa segunda comprobación e difuminaría que sede posúe que bloque. Esa distinción é o que fai visible un enderezo de orixe incorrecto en vez de aceptalo en silencio.

Cada sede só necesita os destinos alcanzables a través do seu par de concentrador: a Sede A enumera o enderezo do concentrador, o enderezo de túnel da Sede B e a LAN de B, e a Sede B enumera o conxunto recíproco. As listas son asimétricas a propósito, porque cada encamiñador ve un lado distinto da topoloxía. Escriba ambas desde o plan de enderezos e non desde a configuración da outra sede, que é como un rango obsoleto sobrevive a unha renumeración.

Con wg-quick, estes rangos tamén crean rutas. Con systemd-networkd ou unha configuración manual, engada vostede mesmo as rutas equivalentes; se non, o túnel transporta paquetes que o núcleo nunca lle envía.

Complete o reenvío e probe ambos os sentidos

Active o reenvío de IPv6 no concentrador e nos dous encamiñadores de sede, e permita os servizos necesarios entre sedes na política de reenvío. Manteña utilizables as mensaxes ICMPv6 Packet Too Big, porque descartalas rompe o descubrimento de MTU da ruta e produce bloqueos en transferencias grandes que parecen fallos de aplicación. Un concentrador que reenvía sen o permiso da devasa descarta o paquete entre o encamiñamento e o túnel. Ese modo de fallo paga a pena coñecelo, porque o túnel segue activo e só morren algúns fluxos.

sysctl net.ipv6.conf.all.forwarding
ip -6 route
ping -6 -c 3 fd7c:2e91:4a00:20::1

Probe desde un equipo da Sede A ata un equipo da Sede B e despois na dirección oposta. Un ping ao enderezo de túnel do concentrador só exercita o primeiro salto e pasará mesmo cando as rutas LAN sexan incorrectas. O fluxo de equipo a equipo é o que demostra o plan.

A conexión WireGuard exterior pode funcionar sobre IPv4 mentres o tráfico interior é IPv6, e esa independencia é útil durante a migración. Se máis adiante se engade saída global IPv6, revise a asignación do provedor, a selección de enderezo de orixe e o encamiñamento de retorno como un novo paso de deseño; o plan privado anterior segue sendo válido para o tráfico entre sedes.