ipsec rightsubnet para largura, não pode sobrescrever a tabela de roteamento | IPSec rotear alguns pacotes 'localmente', não via túnel; ip xfrm mudar?

Question

Gostaria de substituir parte da tabela de roteamento (IPSec)

(encaminhamento para 10.108.0.0/16 localmente via eth0, não via túnel IPSec)

minha configuração IPSEC

conn vpc
    type=tunnel
    authby=secret
    left=172.16.0.200
    leftid=x.x.x.x
    leftsubnet=172.16.0.0/16
    leftfirewall=yes
    right=y.y.y.y
    rightsubnet=10.0.0.0/8
    #pfs=yes
    auto=start

Como você pode ver, o túnel 10.0.0.0/8 é roteado

# ip r s t all
10.0.0.0/8 via 172.16.0.1 dev eth0  table 220  proto static  src 172.16.0.200 
default via 172.16.0.1 dev eth0 
10.108.0.0/16 via 172.16.0.1 dev eth0 
172.16.0.0/24 dev eth0  proto kernel  scope link  src 172.16.0.200 
broadcast 127.0.0.0 dev lo  table local  proto kernel  scope link  src 127.0.0.1 
local 127.0.0.0/8 dev lo  table local  proto kernel  scope host  src 127.0.0.1 
local 127.0.0.1 dev lo  table local  proto kernel  scope host  src 127.0.0.1 
broadcast 127.255.255.255 dev lo  table local  proto kernel  scope link  src 127.0.0.1 
broadcast 172.16.0.0 dev eth0  table local  proto kernel  scope link  src 172.16.0.200 
local 172.16.0.200 dev eth0  table local  proto kernel  scope host  src 172.16.0.200 
broadcast 172.16.0.255 dev eth0  table local  proto kernel  scope link  src 172.16.0.200 
unreachable default dev lo  table unspec  proto kernel  metric 4294967295  error -101
fe80::/64 dev eth0  proto kernel  metric 256 
unreachable default dev lo  table unspec  proto kernel  metric 4294967295  error -101
local ::1 dev lo  table local  proto none  metric 0 
local fe80::52:b2ff:fe65:b0fe dev lo  table local  proto none  metric 0 
ff00::/8 dev eth0  table local  metric 256 
unreachable default dev lo  table unspec  proto kernel  metric 4294967295  error -101

# ipsec statusall
Listening IP addresses:
  172.16.0.200
Connections:
     vpc:  172.16.0.200...x.x.x.x  IKEv1/2
     vpc:   local:  [x.x.x.x ] uses pre-shared key authentication
     vpc:   remote: [y.y.y.y] uses pre-shared key authentication
     vpc:   child:  172.16.0.0/16 === 10.0.0.0/8 TUNNEL
Security Associations (1 up, 0 connecting):
     vpc[3527]: ESTABLISHED 30 minutes ago, 172.16.0.200[x.x.x.x]...y.y.y.y[]
     vpc{1}:   172.16.0.0/16 === 10.0.0.0/8

Eu adicionei especificamente o

    #ip r a 10.108.0.0/16 via 172.16.0.1

10.108.0.0/16 via 172.16.0.1 dev eth0

Eu esperava que fosse pegar 'antes' da mesa 220, mas
mas o tráfego ainda passa pelo túnel IPSec. Eu devo estar perdendo alguma camada. Eu sei que eu poderia mudar o rightsubnet = 10.0.0.0 / 8 para rightsubnet = 10.0.0.0 / 16 mas eu gostaria de mudar apenas uma rota

Basta verificar o

# ip xfrm policy
src 10.0.0.0/8 dst 172.16.0.0/16 
    dir fwd priority 1955 
    tmpl src x.x.x.x dst 172.16.0.200
            proto esp reqid 1 mode tunnel
src 10.0.0.0/8 dst 172.16.0.0/16 
    dir in priority 1955 
    tmpl src x.x.x.x dst 172.16.0.200
            proto esp reqid 1 mode tunnel
src 172.16.0.0/16 dst 10.0.0.0/8 
    dir out priority 1955 
    tmpl src 172.16.0.200 dst x.x.x.x
            proto esp reqid 1 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src ::/0 dst ::/0 
    socket in priority 0 
src ::/0 dst ::/0 
    socket out priority 0 
src ::/0 dst ::/0 
    socket in priority 0 
src ::/0 dst ::/0 
    socket out priority 0 

talvez eu possa mudar alguma coisa aqui

Eu gostaria de direcionar 10.108.0.0/16 via eth0 local, não via túnel IPSec

EDITEi estendi a política com:

ip xfrm policy update dir in src 172.16.0.0/16 dst 10.108.0.0/16
ip xfrm policy update dir out src 172.16.0.0/16 dst 10.108.0.0/16
ip xfrm policy update dir fwd src 172.16.0.0/16 dst 10.108.0.0/16

# ip xfrm policy
src 10.0.0.0/8 dst 172.16.0.0/16 
    dir fwd priority 1955 
    tmpl src 54.77.116.107 dst 172.16.0.200
        proto esp reqid 1 mode tunnel
src 10.0.0.0/8 dst 172.16.0.0/16 
    dir in priority 1955 
    tmpl src 54.77.116.107 dst 172.16.0.200
        proto esp reqid 1 mode tunnel
src 172.16.0.0/16 dst 10.0.0.0/8 
    dir out priority 1955 
    tmpl src 172.16.0.200 dst 54.77.116.107
        proto esp reqid 1 mode tunnel
src 172.16.0.0/16 dst 10.108.0.0/16 
    dir fwd priority 0 
src 172.16.0.0/16 dst 10.108.0.0/16 
    dir out priority 0 
src 172.16.0.0/16 dst 10.108.0.0/16 
    dir in priority 0 

outra tentativa:

ip xfrm policy add dir out src 172.16.0.0/16 dst 172.16.0.1
ip xfrm policy add dir in src 172.16.0.0/16 dst 172.16.0.1 
ip xfrm policy add dir fwd src 172.16.0.0/16 dst 172.16.0.1

# ip xfrm policy 
src 172.16.0.0/16 dst 172.16.0.1/32 
    dir fwd priority 0 
src 172.16.0.0/16 dst 172.16.0.1/32 
    dir in priority 0 
src 172.16.0.0/16 dst 172.16.0.1/32 
    dir out priority 0 
src 10.0.0.0/8 dst 172.16.0.0/16 
    dir fwd priority 1955 
    tmpl src 54.77.116.107 dst 172.16.0.200
            proto esp reqid 1 mode tunnel
src 10.0.0.0/8 dst 172.16.0.0/16 
    dir in priority 1955 
    tmpl src 54.77.116.107 dst 172.16.0.200
            proto esp reqid 1 mode tunnel
src 172.16.0.0/16 dst 10.0.0.0/8 
    dir out priority 1955 
    tmpl src 172.16.0.200 dst 54.77.116.107
            proto esp reqid 1 mode tunnel

ainda não parece um bom 'redirecionamento'

    

Answer 1

Eu sei que isso provavelmente não é o que você quer ouvir, mas a melhor maneira de lidar com IPsec e roteamento é separar completamente os dois. O IPsec padrão no modo de política (da maneira como o Linux faz e se parece com o que você está usando) tem uma tendência a "mimar" as camadas tornando o roteamento muito obscuro. Uma maneira melhor de fazer isso é tratar o IPsec mais como um link de rede lógico típico: fazer IPsec lidar com comunicação ponto-a-ponto e camada GRE no topo com protocolos de roteamento dinâmico como OSPF e BGP (você pode pular o roteamento dinâmico se você quer, mas é recomendado).

No seu caso, em vez de fazer interface direta com 172.16.0.0/16 com 10.0.0.8/8 , você tem a pilha IPsec para criar um link ponto a ponto em um /30 ou mesmo um /31 . Por exemplo, você pode usar 10.254.254.1/30 para o IP esquerdo e 10.254.254.2/30 para o IP correto. Uma vez estabelecida, crie um túnel GRE com IPs internos 10.100.100.1/30 para o lado local e 10.100.100.2/30 para o lado remoto (e use os IPs 10.254.254.0/30 acima mencionados para o lado externo apropriado). Bônus: se você conseguir executar o IPsec no modo de transporte, poderá renunciar completamente à parte 10.254.254.0/30 e usar os IPs reais dos pontos de extremidade como a parte externa do túnel GRE.

Agora você tem uma interface Ethernet padrão (o túnel GRE) e pode fazer rotas estáticas com muita facilidade: basta apontar 10.0.0.8/8 via 10.100.100.2 e 172.16.0.0/16 at 10.100.100.1 . Melhor ainda: remova completamente estas rotas estáticas e faça com que o OSPF ou o BGP lidem com o roteamento automaticamente para você (veja o quagga para isso).

Benefícios: Você pode adicionar rotas facilmente a qualquer momento sem reconfigurar a pilha IPsec subjacente, já que ela está completamente isolada do roteamento. Você pode executar qualquer serviço que espere uma interface Ethernet padrão sem estranheza (o iptables é um exemplo perfeito disso). Você pode facilmente realizar vários caminhos divergentes e redundantes aproveitando BGP e vários túneis IPsec e evitar completamente os esquemas de alta disponibilidade de IPsec um pouco bizantinos. Mas o melhor benefício é que você agora colocou o IPsec em um local muito compartimentado (protegendo o tráfego em um link) que é facilmente expandido em camadas superiores da rede sem nenhuma configuração adicional.

O IPsec é um protocolo realmente flexível, e por causa disso muitas coisas acabam sendo sugadas em seu vórtice. Em um certo ponto, é realmente melhor que o IPsec se atenha ao que faz de melhor e utilize conceitos de pilha de rede de nível mais alto em vez de jogar a pia da cozinha nele.