Meta
Estoy intentando configurar una VPN WireGuard solo con IPv6 a través de la cual (a) quiero enrutar todo el tráfico y (b) con un servidor al que se puede acceder desde Internet. Como ni siquiera pude hacer que (a) funcionara, intentaré que funcione, (b) es solo por contexto.
Tengo un VPS con IPv6 enrutable globalmente 2a03:4000:xx:xx:18d7:b1ef:fe48:7d35/64(eso es lo que ip ame dice) en eth0. Me referiré a él con el nombre de host vps. Para fines de prueba, el servidor no tiene firewall y net.ipv6.conf.all.forwarding=1y
net.ipv6.conf.all.accept_ra=2.
Entonces también tengo encendido mi dispositivo, que también tiene una dirección IPv6 2001:1715:yy:yy:db2d:ab24:ed3f:39d4/64( wlan0esto no debería ser información relevante, ya que esta dirección cambiará cuando esté en otra WLAN). Lleva el nombre de host laptop.
Quiero terminar con algo como esto:
Internet <-> vps <-> laptop
Con IPv4, usaría NAT, sin embargo, en el mundo IPv6, se desaconseja NAT. Es difícil saber qué hacer en su lugar, pero si leí correctamente, entonces debería dar otra dirección IP del 2a03:4000:xx:xx::/64bloque que el VPS llegó a la computadora portátil.
Configuración
Entonces escribo estas dos configuraciones de protección de cables:
VPS:
[Interface]
Address = fc01::1/128 # Shouldn't really matter?
ListenPort = 1935 # This port is open to UDP on most networks
PrivateKey = uLxxxxxxxxxxxxxxxxxxxxxxxxEQ=
[Peer]
# laptop
PublicKey = swxxxxxxxxxxxxxxxxxxxxxxxxxmQ=
AllowedIPs = 2a03:4000:xx:xx:ffff::3/128 # Is inside the vps' /64 block
Computadora portátil:
[Interface]
Address = 2a03:4000:xx:xx:ffff::3/128 # The globally routable IP addr of my laptop via the vps
ListenPort = 1935
PrivateKey = yMxxxxxxxxxxxxxxxxxxxxxxxxxxxxm8=
[Peer]
PublicKey = pCxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxzs=
AllowedIPs = ::/0 # Route all traffic through this peer
Endpoint = [2a03:4000:xx:xx:18d7:b1ef:fe48:7d35]:1935
Los menciono:
[root@vps ~]# wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -6 address add fc01::1/128 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] ip -6 route add 2a03:4000:xx:xx:ffff::3/128 dev wg0
[root@laptop ~]# wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -6 address add 2a03:4000:xx:xx:ffff::3/128 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] wg set wg0 fwmark 51820
[#] ip -6 route add ::/0 dev wg0 table 51820
[#] ip -6 rule add not fwmark 51820 table 51820
[#] ip -6 rule add table main suppress_prefixlength 0
[#] ip6tables-restore -n
...aaa y no funciona.
WireGuard no parece conectarse correctamente. La computadora portátil muestra una conexión y cuenta el tráfico enviado (pero se recibió 0B), pero el VPS no muestra una conexión.
¿Cómo se configura correctamente una VPN WireGuard solo IPv6? Y si esto es correcto, ¿por qué el tráfico enviado por un extremo no llega al otro extremo del túnel?
Si fuera útil obtener más información (pcaps, ipresultados, etc.), con gusto modificaré la pregunta.
Respuesta1
Esto no funciona porque la puerta de enlace de su servidor suponetodo el /64 está "en enlace", es decir, se puede acceder directamente a cada dirección en el mismo segmento de Ethernet, por lo que la puerta de enlace realiza consultas de Neighbor Discovery para la dirección MAC de su computadora portátil, pero no recibirá ninguna respuesta porque la computadora portátil no está en el mismo enlace en absoluto.
(Normalmente, el servidor no responde en nombre de las direcciones que están enrutadas a otro lugar; solo responde a las direcciones que están asignadas directamente a su propia interfaz eth0).
Para que esto funcione con direcciones en el enlace, necesitará usar "proxy NDP", es decir, hacer que el servidorproporcionar respuestas NDP en nombre de la computadora portátil(y cualquier otra dirección que esté intentando enrutar a través del túnel).
La forma más confiable de hacer esto para IPv6 sería ejecutar el ndpresponderdemonio en eth0. Escuchará los paquetes de Solicitud de Vecinos y enviará los Anuncios de Vecinos correctos.
(De manera similar, podrías usar ndppdo incluso la función incorporada del kernel proxy_ndp, pero se comportanlevementediferente a las respuestas NDP reales y, a veces, no pasan las comprobaciones anti-suplantación de identidad que realizan algunos operadores de alojamiento VPS).
Sin embargo, lo ideal es que la empresa de hostingdebería proporcionarte unenrutadoprefijo– uno en el que la puerta de enlace del centro de datos esté configurada explícitamente para enrutar todo "a través" de la dirección principal de su servidor. Esto también sería ligeramente beneficioso para ellos, ya que una única ruta estática sería más eficiente que muchas entradas de caché vecinas dinámicas.
(Desafortunadamente, muchas empresas de alojamiento de servidores utilizan internamente una determinada plataforma de administración de VPS que les impide ofrecer prefijos enrutados; he oído que es culpa de SolusVM, que insiste en el modelo "plano en enlace /48").
Nota: Esto no es específico de IPv6 de ninguna manera; la misma distinción entre 'en enlace' y 'enrutado' existe en IPv4, con la única diferencia de que IPv4 usa ARP en lugar de NDP. (Por ejemplo, si su servidor estaba en 192.168.1.0/24 en eth0 y deseaba enrutar 192.168.1.7 a un cliente VPN, tendría exactamente el mismo problema y necesitaría proxy-ARP para solucionarlo. )