Tengo un servidor A con una VPN configurada para otro servidor B. Actualmente, el servidor A puede hacer ping al servidor B utilizando la dirección VPN 10.12.0.1.
Me gustaría enrutar todo el tráfico HTTPS a través del servidor B y permitir que el resto del tráfico utilice la interfaz predeterminada.
Para hacer eso, me inspiré enesta respuesta de Unix StackExchangey he ejecutado los siguientes comandos:
# define route
echo "200 myroute" >> /etc/iproute2/rt_tables
# seems necessary
sysctl -w net.ipv4.conf.wg1.rp_filter=2
# actual routing
ip route add table 200 10.12.0.0/24 dev wg1 src 10.12.0.10
ip route add table 200 default via 10.12.0.1
# actual rule telling HTTPS traffic to use table 200
ip rule add iif lo ipproto tcp dport 443 lookup 200
Luego, ejecuto curl https://1.1.1.1(o cualquier otro host) y aparece el error Failed to connect to 1.1.1.1 port 443: No route to host. Cuando elimino la regla, todo vuelve a funcionar.
Supongo que mi ruta para la tabla 200 no es correcta, pero parece coincidir con la de la respuesta original y las de la interfaz predeterminada.
¿Sabes cómo puedo investigar y depurar el problema?
Gracias
Información adicional:
$ ip route show table 200
default via 10.12.0.1 dev wg1
10.12.0.0/24 dev wg1 scope link src 10.12.0.10
$ ip route show dev wg1
10.12.0.0/24 proto kernel scope link src 10.12.0.10
$ ip route get 1.1.1.1 ipproto tcp dport 443
1.1.1.1 via 10.12.0.1 dev wg1 table 200 src 10.12.0.10 uid 1001
cache
$ ip route
default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.51 metric 202
10.12.0.0/24 dev wg1 proto kernel scope link src 10.12.0.10
192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.51 metric 202
La VPN es una VPN Wireguard. Cuando se configura para enrutar todo el tráfico a través de la VPN, todo funciona.
Respuesta1
El error "no hay ruta al host" probablemente se deba a que intenta conectarse a un host ( 1.1.1.1) que no está incluido en su AllowedIPsconfiguración de WireGuard. Suponiendo que estás usando wg-quick, haz esto:
Comopaso 1, en la configuración WireGuard del Servidor A, ajuste la AllowedIPsconfiguración en la [Peer]sección del Servidor B para incluir las direcciones IP (o bloques de direcciones IP) a las que desea conectarse.
En lugar de 1.1.1.1, digamos que desde el Servidor A desea poder conectarse a cualquier servidor HTTPS en el 192.0.2.0/24bloque (y en particular había un servidor 192.0.2.123con el que está probando). Digamos también que inicialmente configuró su AllowedIPsconfiguración en el Servidor A para que el Servidor B incluya el 10.12.0.0/24bloqueo. Cambie esta configuración a la siguiente:
AllowedIPs = 10.12.0.0/24, 192.0.2.0/24
Deshágase de las rutas y reglas que configuró previamente para la tabla 200 en el Servidor A, reinicie WireGuard (p. ej. sudo wg-quick down wg1; sudo wg-quick up wg1) y pruebe este cambio ejecutando lo siguiente:
$ curl -k https://192.0.2.123
Eso al menos debería llevarlo más allá del error "no hay ruta al host". Si todavía recibe errores solo con eso, probablemente necesite ajustar su firewall/reglas de enrutamiento en el Servidor B para permitirle reenviar paquetes desde el Servidor A a 192.0.2.0/24.
Comopaso 2, en la [Interface]sección de configuración WireGuard del Servidor A, agregue la siguiente configuración:
Table = 200
Esto le indicará a wg-quick que agregue las rutas que crea automáticamente a su 200tabla de enrutamiento personalizada, en lugar de a su tabla principal. Reinicie WireGuard nuevamente y verifique sus tablas de enrutamiento:
$ ip route
default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.51 metric 202
192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.51 metric 202
$ ip route show table 200
10.12.0.0/24 dev wg1 scope link
192.0.2.0/24 dev wg1 scope link
Ahora agregue su regla de política HTTPS especial:
$ sudo ip rule add iif lo ipproto tcp dport 443 lookup 200
Y pruébalo:
$ curl -k https://192.0.2.123
Comopaso 3, suponiendo que aún desea poder conectarse directamente desde el Servidor A al Servidor B a través de WireGuard para servicios distintos de HTTPS (como SSH, etc.), agregue otra regla de política en el Servidor A para todas las conexiones al 10.12.0.0/24bloque:
$ sudo ip rule add to 10.12.0.0/24 table 200 priority 201
Ahora debería poder usar WireGuard para conectarse nuevamente del servidor A al servidor B:
$ ssh 10.12.0.1