☰

Excluir una subred local de StrongSwan VPN

tag-icon • tag-icon vpn linux-networking strongswan
Excluir una subred local de StrongSwan VPN

Tengo una computadora con una interfaz Ethernet adicional solo local, con una subred privada. Cuando se establece una VPN StrongSwan, no puedo acceder a esa subred.

Esta es la configuración local 'izquierda' (establecida poralgo):

conn ikev2-<rightip>
    fragmentation=yes
    rekey=no
    dpdaction=clear
    keyexchange=ikev2
    compress=no
    dpddelay=35s

    ike=aes128gcm16-prfsha512-ecp256!
    esp=aes128gcm16-ecp256!

    right=<rightip>
    rightid=<rightip>
    rightsubnet=0.0.0.0/0
    rightauth=pubkey

    leftsourceip=%config
    leftauth=pubkey
    leftcert=daves.crt
    leftfirewall=yes
    left=%defaultroute

    auto=add

La subred en cuestión es 10.0.0.0/24. %defaultroute se resuelve en una dirección en 192.168.0.0/24.

'left' y 'leftsubnet' no parecen las opciones correctas para esto, pero no veo nada mejor. Intenté configurar leftsubnet en 10.0.0.0/24 y en !10.0.0.0/24.

¿Cómo excluyo una subred local de una conexión VPN de StronSwan?

¿Cómo inspecciono la configuración de ruta de una conexión?

Respuesta1

Puedes establecer unpolítica de transferencia.

ACTUALIZACIÓN: como lo señaló @ecdsa, con strongswan >= 5.5.2 hay unamétodo más fácil, mira al final si tu versión puede usarlo.

Ejemplo con algunas IP aleatorias. Antes de cualquier cambio y túnel:

# ip route get 10.0.0.55
10.0.0.55 dev lxcbr0 src 10.0.0.77 uid 0

Después de establecer el túnel, el problema:

# ip route get 10.0.0.55
10.0.0.55 via 192.168.0.1 dev eth0 table 220 src 192.168.0.44 uid 0

Agregar esta configuración a /etc/ipsec.conf:

conn ignorelan
    left=127.0.0.1 #prevents usage in peers selection algorithm
    leftsubnet=10.0.0.0/24
    rightsubnet=10.0.0.0/24
    authby=never
    type=passthrough
    auto=route

y recargarlo:

# ipsec reload

debe activarlo inmediatamente. Si no fue así (esta vez) puedes hacer:

# ipsec route ignorelan
'ignorelan' shunt PASS policy installed

De todos modos, debería usarse en cualquier reinicio posterior. Ahora tienes (además de cualquier túnel):

# ipsec status 
Shunted Connections:
     ignorelan:  10.0.0.0/24 === 10.0.0.0/24 PASS

[...]

Ahora, independientemente de que se haya establecido el túnel o no, se obtiene la ruta correcta (manejada por strongswan, por lo que en la tabla 220, no (solo) en la tabla principal (ya más)):

# ip route get 10.0.0.55
10.0.0.55 dev lxcbr0 table 220 src 10.0.0.77 uid 0 
    cache

Con un túnel activado para 0.0.0.0/0, habría un resultado similar a este en la tabla 220:

# ip route show table 220
default via 192.168.0.1 dev eth0 proto static src 192.168.0.44 
10.0.0.0/24 dev lxcbr0 proto static src 10.0.0.77 
192.168.0.0/24 dev eth0 proto static src 192.168.0.44

Si no coloca rutas que coincidan con la realidad (por ejemplo: máscara de red incorrecta) en la configuración de paso a través, espere resultados incorrectos para la "derivación" (como la IP de origen esperada, pero pasando por la tarjeta de red incorrecta), así que tenga cuidado.

ACTUALIZAR: elcomplemento de bypass-lanEs más fácil de usar, especialmente con entornos dinámicos.

En lugar de agregar nuevas connentradas, actívelo (por ejemplo, en Debian buster (no estable), edite /etc/strongswan.d/charon/bypass-lan.conf y configure load=yes (es decir: charon.plugins.bypass-lan.load =sí) ). De forma predeterminada, cada interfaz se desvía, lo que significa que se establecería un túnel, pero no se utilizaría de forma predeterminada. Así que simplemente configure interfaces_ignoreo interfaces_useen consecuencia. Debes configurar interfaces_ignorelas interfaces queno quieropara evitar túneles o, de lo contrario, configurar interfaces_usepara las interfaces quedesearpara evitar túneles. P.ej:

interface_use = lxcbr0

Aparecerá en este ejemplo después ipsec start, como el método anterior:

# ip route show table 220
10.0.0.0/24 dev lxcbr0 proto static src 10.0.0.77

(pero también considerará las rutas IPv6 relacionadas con esta interfaz cuando IPv6 esté en uso).

Sin embargo, otro método (pirata) sería omitir la tabla 220 de strongswan: en lugar de cualquier configuración de strongswan, se lograría lo mismo (para estas preguntas y ejemplos) con:

ip rule add priority 219 to 10.0.0.0/24 lookup main

Utilizará la tabla de enrutamiento predeterminada (principal) con la red de destino en lugar de continuar con la siguiente entrada usando la tabla 220 de strongswan.

información relacionada