☰

Rotear o tráfego entre dois túneis IPsec

tag-icon • tag-icon vpn ipsec strongswan backend libreswan
Rotear o tráfego entre dois túneis IPsec

Eu executo um back-end na infraestrutura DO, chamo-o de siteYvi, que se conecta a um site de terceirosProv.através de um túnel IPsec, com esta configuração do libreswan:

conn prov-client
  ...
  right=$YVI_IP
  rightsourceip=10.31.3.1
  rightsubnet=10.31.3.0/28
  left=$PROV_IP
  leftsubnet=10.70.0.36/28

Prov.tem um servidor em execução 10.70.0.37e posso interagir com ele deYvi.

Meu problema é que estou configurando um ambiente de desenvolvimento local (uma caixa Ubuntu em outra rede) e cada vez que faço uma alteração, tenho que implantarYviporque só a partir daí posso acessar a API emProv.. Eu gostaria de evitar isso conectandoLocalparaYvie encaminhar esse tráfego paraProv.para poder acessar a API emProv.deLocale facilitar o desenvolvimento.

eu conectoLocalparaYvicomo um guerreiro da estrada com a seguinte configuração:

conn remote-dev-client
  ...
  left=$YVI_IP
  leftsubnet=10.31.3.0/28
  right=%any
  rightaddresspool=10.31.4.1-10.31.4.254

A conexão foi estabelecida com sucesso e deLocalEu posso 10.31.3.1alcançarYvi. O que eu quero é 10.70.0.37chegarProv.deLocal. A rota para a 10.70.0.36/28rede não é adicionada automaticamente, então tentei definir algumas ip xfrmregras ip routemanualmente emLocal:

# Outgoing
ip xfrm policy add dst 10.70.0.37 src 10.31.4.1 dir out tmpl src $LOCAL_IP dst $YVI_IP proto esp spi $SPI reqid $REQID mode tunnel priority 100000

# Incoming
ip xfrm policy add dst 10.31.4.1 src 10.70.0.37 dir fwd tmpl src $YVI_IP dst $LOCAL_IP proto esp reqid $REQID mode tunnel priority 100000
ip xfrm policy add dst 10.31.4.1 src 10.70.0.37 dir in tmpl src $YVI_IP dst $LOCAL_IP proto esp reqid $REQID mode tunnel priority 100000

ip route add table 220 src 10.31.4.1 10.70.0.37 via $LOCAL_IP dev $LOCAL_IF proto static

agora eu ip xfrm monitorcorroYvie então deLocalpingar 10.70.0.37; Eu posso ver os pacotes chegandoYvi(do monitor xfrm emYvi), mas apenas a saída, não a resposta (como é visto se eu executar ping em 10.31.3.1, por exemplo), sugerindo queYviestá recebendo o tráfego, mas não o encaminhando paraProv.? Eu realmente não sei como interpretar isso.

Acho que tenho que adicionar rotasYvipara encaminhar o tráfego para oProv.API corretamente, mas adicionar regras semelhantes às acima não funcionou. Gostaria de receber ajuda para entender o que estou perdendo e o que estou fazendo de errado.

Sugestões para uma abordagem diferente também são bem-vindas, embora a única maneira de se conectarProv., que não controlo, é através de um túnel IPsec deYvi, que eu controlo.

Responder1

Consegui resolver isso com regras NAT do iptables. As ip xfrmpolíticas não eram necessárias. Esta é uma pequena explicação do que fiz, para alguém que, como eu, não é especialista:

DeYviEstou atribuindo uma 10.31.4.0/24sub-rede aos road warriors, então uma rota para essa rede é instalada automaticamente pelo daemon de chave (libreswan no meu caso), então adicionei regras NAT emYvi( /etc/ufw/before.rules, já que estou usando o UFW, mas você pode conseguir o mesmo iptablesdiretamente):

*nat
-F
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]

# PRE 
-A PREROUTING -s 10.31.4.0/24 -d 10.31.3.2 -j DNAT --to-destination 10.70.0.37


# POST
-A POSTROUTING -s 10.31.4.0/24 -d 10.70.0.37 -j SNAT --to-source 10.31.3.1

COMMIT

Diz ao *natiptables para aplicar as regras à tabela NAT e COMMITrealmente salva as regras. O -Fexiste apenas por conveniência, já que o UFW adiciona as regras, ufw enablemas não as exclui, ufw disableentão você acaba com duplicatas, daí o sinalizador flush -F.

A PREROUTINGregra se aplica a pacotes recebidos da sub-rede do road warrior destinados a 10.31.3.2, e o que ela faz é alterar o endereço de destino para ser 10.70.0.37em vez de 10.31.3.2, atribuindo efetivamente esse endereço IP aoProv.servidor, da perspectiva dos guerreiros da estrada.

A POSTROUTINGregra se aplica a pacotes que chegam da sub-rede do road warrior prestes a sair 10.70.0.37(ou seja, pacotes que acabaram de atingir a regra de pré-roteamento) e altera seu endereço de destino de um endereço 10.31.4.0/0para 10.31.3.1. Isso é necessário porque eu não controlo as rotas, o servidor ou qualquer coisa emProv., então seProv.recebe uma solicitação da 10.30.4.0/24sub-rede, não saberia como responder. Mas ele sabe 10.31.3.1.

E é isso! Agora eu posso alcançarProv.deLocalatravés daYvino 10.31.3.2.

informação relacionada