Wireguard funciona incluso sin configurar una dirección IP de túnel, es decir, es suficiente configurar las IP permitidas, las direcciones de punto final y las claves públicas y privadas.
En los documentos deOpnSense, existe la siguiente advertencia:
Nota:La dirección del túnel debe estar en notación CIDR y debe ser una IP y una subred únicas para su red. [..]No utilice una dirección de túnel que sea /32 (IPv4) o /128 (IPv6)
y pfSense tiene una explicación probable:
Nota:Las rutas no se crean automáticamente en la tabla de enrutamiento del sistema. Las rutas para redes distintas a la propia red de túneles deben configurarse por separado mediante rutas estáticas o dinámicas.
Buscar en internet no arroja muchas explicaciones:
- Reddit: Confusión sobre máscaras de subred
- Reddit: Ayuda sobre /24 y /32 cuando se usa como servidor VPN
- Reddit: diferencias entre /8, /16 etc... ¿Para qué sirven?
La subred no parece tener ninguna funcionalidad, hicimos algunas pruebas:
- No está relacionado con el enrutamiento del tráfico local, es decir, el enrutamiento a un segundo par conectado funciona con y sin una subred que contenga ambos pares.
- no está relacionado con "permanecer en la interfaz" versus pasar por el kernel. En ambos casos podríamos controlar el tráfico mediante reglas de firewall.
Entonces, ¿cuál es el propósito de la máscara de subred en la IP del túnel?
Respuesta1
La máscara de subredno hace nadaEspecífico de WireGuard.
WireGuard en sí no usa ni se preocupa por las máscaras de subred en sus direcciones de interfaz (ni siquiera usa ni se preocupa por las direcciones mismas). Sin embargo, la pila de red y otras herramientas de red en el host WireGuard se preocupan por las direcciones IP y las subredes registradas para cada interfaz de red, y las usarán para intentar determinar si una interfaz en particular está conectada directamente a una red en particular.
Su comportamiento observado puede variar según el sistema operativo y las herramientas de red particulares que utilice (como OPNSense/pfSense y todos sus diversos complementos), pero se pueden generar muchas cosas como tablas de enrutamiento, reglas de firewall, mensajes ARP, tablas vecinas, etc. automáticamente en función de las direcciones IP y subredes que haya configurado para cada interfaz de red. Sin embargo, en muchos casos, aún puede anular estos valores predeterminados mediante reglas personalizadas de enrutamiento/firewall, configuraciones del kernel, configuración del demonio de red, etc.
Por ejemplo, cuando inicia una interfaz WireGuard con el estándarwg-rápidoscript en Linux, ese script utilizará eliproute2herramienta para agregar cada dirección y subred que haya configurado para la interfaz. Para cada dirección que agrega, iproute2 agrega automáticamente una ruta correspondiente a la tabla de enrutamiento principal para que coincida con la subred de la dirección. El uso de ese script para iniciar una interfaz nombrada wg0con una dirección de 10.0.0.123/24dará como resultado que iproute2 agregue la siguiente ruta a la tabla de enrutamiento principal:
10.0.0.0/24 dev wg0 proto kernel scope link src 10.0.0.123
Esto no es algo de WireGuard, es solo el comportamiento predeterminado de algunas de las herramientas de red estándar en Linux. Eres libre de eliminar esa ruta y agregar otras rutas, o simplemente usar un conjunto diferente de herramientas para configurar la interfaz WireGuard. (Pero tenga en cuenta que esta o cualquier otra ruta agregada a una interfaz WireGuard que no tenga una AllowedIPsentrada correspondiente en la configuración propia de la interfaz se convertirá efectivamente en un agujero negro).
El resultado es que, en la mayoría de los casos, está perfectamente bien usar una dirección con una máscara de subred /32 o /128 en una interfaz WireGuard. Puede configurar sus propias reglas de enrutamiento y firewall para enviar el tráfico que desee a esa interfaz. Pero para casos más avanzados, particularmente cuando desea ejecutar herramientas en la interfaz como Proxy ARP, NDP Proxy, OSPF, etc. (que están diseñadas para usarse dentro de subredes locales), puede evitar tener que luchar contra el comportamiento predeterminado de esas herramientas. asignando la interfaz WireGuard y sus vecinos virtuales a una subred lógica consistente.