☰

Excluir uma sub-rede local do StrongSwan VPN

tag-icon • tag-icon vpn linux-networking strongswan
Excluir uma sub-rede local do StrongSwan VPN

Eu tenho um computador com uma interface Ethernet extra somente local, com uma sub-rede privada. Quando uma VPN StrongSwan é estabelecida, não consigo acessar essa sub-rede.

Esta é a configuração local 'esquerda' (estabelecida 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

A sub-rede em questão é 10.0.0.0/24. %defaultroute resolve para um endereço em 192.168.0.0/24.

'left' e 'leftsubnet' não parecem as opções certas para isso, mas não vejo nada melhor. Tentei configurar leftsubnet para 10.0.0.0/24 e para !10.0.0.0/24.

Como excluo uma sub-rede local de uma conexão VPN StronSwan?

Como inspeciono a configuração da rota de uma conexão?

Responder1

Você pode definir umpolítica de passagem.

ATUALIZAÇÃO: conforme observado por @ecdsa, com Strongswan >= 5.5.2 há ummétodo mais fácil, veja no final se sua versão pode utilizá-lo.

Exemplo com alguns IPs aleatórios. Antes de qualquer mudança e túnel:

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

Depois de estabelecer o túnel, o 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

Adicionando esta configuração 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

e recarregando-o:

# ipsec reload

deve ativá-lo imediatamente. Se não (desta vez), você pode fazer:

# ipsec route ignorelan
'ignorelan' shunt PASS policy installed

De qualquer forma, deve ser usado em qualquer reinicialização posterior. Agora você tem (além de qualquer túnel):

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

[...]

Agora, com o túnel sendo estabelecido ou não, você recebe de volta a rota correta (tratada pelo Strongswan, portanto na tabela 220, não (apenas) na tabela principal (mais)):

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

Com um túnel ativado para 0.0.0.0/0, haveria um resultado semelhante a este na tabela 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

Se você não colocar rotas que correspondam à realidade (por exemplo: máscara de rede errada) nas configurações de passagem, espere resultados errados para o "shunt" (como o IP de origem esperado, mas passando pela placa de rede errada), então tome cuidado.

ATUALIZAR: oplugin bypass-lané mais fácil de usar, especialmente em ambientes dinâmicos.

Em vez de adicionar novas connentradas, ative-o (por exemplo, no Debian buster (não estável), edite /etc/strongswan.d/charon/bypass-lan.conf e defina load=yes (ou seja: charon.plugins.bypass-lan.load =sim) ). Por padrão, todas as interfaces são desviadas, o que significa que um túnel seria estabelecido, mas não seria usado por padrão. Portanto, basta definir interfaces_ignoreou interfaces_usede acordo. Você deve definir interfaces_ignoreas interfaces que desejanão queropara ignorar túneis ou, então, definir interfaces_usepara a(s) interface(s) que vocêquererpara contornar túneis. Por exemplo:

interface_use = lxcbr0

Entraremos neste exemplo depois ipsec start, como no método anterior:

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

(mas também considerará rotas IPv6 relacionadas a esta interface quando o IPv6 estiver em uso).

No entanto, um outro método (hackish) seria ignorar a tabela 220 do cisne forte: em vez de quaisquer configurações de cisne forte, o mesmo seria alcançado (para estas perguntas e exemplos) com:

ip rule add priority 219 to 10.0.0.0/24 lookup main

Ele usará a tabela de roteamento padrão (principal) com a rede de destino em vez de continuar para a próxima entrada usando a tabela 220 do Strongswan.

informação relacionada