Malla Wireguard entre red pública y local.

Question

Si los nodos 4,5,6 están cada uno detrás del suyoCGNAT, entonces, como de costumbre, no pueden lograr una comunicación adecuada entre ellos. Tienen que depender de los nodos 1,2,3 para retransmitir el tráfico. Entonces estos nodos CGNAT requerirán másIP permitidaspara algunos pares públicos en sus configuraciones permitir que otros nodos CGNAT pasen por los nodos públicos, y los nodos públicos deben configurarse como enrutadores.

Ejemplo para el nodo 4 que se supone que tiene la dirección IP 10.1.0.51/32 y utiliza el nodo 2 como nodo de enrutamiento:

[Interface]
Address = 10.1.0.51/32
PrivateKey =

[Peer] # example public node 1
PublicKey =
AllowedIPs = 10.1.0.1/32
Endpoint = X.X.X.X:5888
PersistentKeepalive = 25

[Peer] # example public node 2
PublicKey =
AllowedIPs = 10.1.0.2/32,10.1.0.52/32,10.1.0.53/32
Endpoint = Y.Y.Y.Y:5888
PersistentKeepalive = 25

[Peer] # example public node 3
PublicKey =
AllowedIPs = 10.1.0.3/32
Endpoint = Z.Z.Z.Z:5888
PersistentKeepalive = 25

Se espera que las direcciones IP de otros nodos CGNAT se enruten a través del nodo 2 y se deben agregar a la dirección IP de ese par.IP permitidas. Esto también debería agregarlos automáticamente a la tabla de enrutamiento.

El nodo 2 ahora también debe ser un enrutador, al menos en su interfaz WireGuard, que será tanto de entrada como de salida. En Linux esto se haría, por ejemplo, con (asumiendo una interfazwg0):

sysctl -w net.ipv4.conf.wg0.forwarding=1

Sus reglas de firewall también deben permitir el tráfico reenviado enwg0.

Tenga en cuenta que no es necesario definir los otros pares CGNAT en los nodos CGNAT y, si están definidos,no debetener direcciones IP de otros nodos CGNAT enIP permitidas:

no serán accesibles directamente y,
si la misma dirección se establece en posterioresIP permitidasse eliminará de cada definición anterior y solo la tendrá el último par definido. Conenrutamiento de clave criptográficaDirección(es) IP <=> par.

Los nodos 5 y 6 deben tener una configuración compatible (utilizando también el nodo 2 como enrutador). También podrías imaginar tener en su lugar:

roles divididos donde 4 y 5 son enrutados por el nodo 2, 4 y 6 por el nodo 3 y 5 y 6 por el nodo 1,
o tener múltiples direcciones IP dentro de diferentes bloques de IP para que cada bloque pueda enrutarse a través de un nodo de enrutamiento diferente,
o usar enrutamiento cebolla con tráfico WireGuard dentro del tráfico WireGuard para que los nodos de enrutamiento no puedan decodificar el tráfico que no está destinado a ellos,
o utilizando múltiples interfaces WireGuard independientes (que no están sujetas a interacción de clave criptográfica entre sí, sino solo a la tabla de enrutamiento),
o alguna combinación de opciones anteriores,

[...]

En todos los casos, para cualquier cambio de topología, incluso si se debe a una falla en lugar de un cambio previsto, se necesita una forma de sincronizar los cambios de configuración en todos los pares afectados y actualmente no existe ninguna herramienta dedicada para hacerlo.

Como conclusión, aquí tenéis un blog dondeBGP(esa sería la herramienta que falta) se usa junto con WireGuard, con múltiples direcciones y también una interfaz por nodo par con solo ese par definido para evitar el enrutamiento de claves criptográficas. Probablemente haya algo que aprender de esto, pero el tema es demasiado avanzado para mí.

VPN basada en rutas en Linux con WireGuard

Answer 1