ipsec / strongswan - como usar o roteador remoto como gateway local usando o comando route

1

Ok, isso deve ser fácil, mas está me enlouquecendo.

Scenario:

Site A (San Francisco) Site B (Colombia)

Ambos os sites estão conectados com sucesso via IPSec (openswan, debian 8):

SiteA---------------SiteB
10.2.0.1 <==inet==> 10.3.0.1

Eu posso usar o PING 10.3.0.1 do SiteA com êxito. Além disso, 10 extensões de telefone na sub-rede 10.3.0.0 se conectam ao SiteA. Doce, sem problemas.

No entanto, note 10.3.0.1 NÃO É LISTADO como uma rota em qualquer lugar sob a tabela de roteamento do kernel do SiteA, mas se eu fizer um ping a partir de 10.2.0.1, ele funciona.

THE PROBLEM:

Ok. Acabei de adicionar um roteador SIP 10.11.208.93 no SiteB. SiteA precisa ser 10.11.208.94 e tem que ser capaz de alcançar 10.11.208.93 via 10.3.0.1. Eu adicionei esta ponte com sucesso em 10.3.0.1 no SiteB.

Quando tento criar a rota estática para o roteador SIP via 10.3.0.1 no SiteA, o comando route diz que o host não está acessível. Mas eu posso pingar 10.3.0.1 do SiteA.

ip route add -net 10.11.208.92/30 via 10.3.0.1

SIOADDR: Host unreachable

A pergunta é: onde / como diabos é o strongswan (ipsec) configurando a tabela de roteamento linux para acessar 10.3.0.1 através do túnel ??? não aparece na tabela de roteamento.

Se eu conseguir fazer o ping em 10.3.0.1, por que não posso usá-lo como uma rota para alcançar uma sub-rede por trás dele, já tendo um túnel de trabalho?

    
por Pedro Guillem 23.12.2015 / 06:24

1 resposta

4

O strongSwan instala rotas na tabela de roteamento 220 por padrão. Você pode ver isso com ip route list table 220 .

No entanto, adicionar um trajeto não fará com que seu tráfego seja tunelado. O IPsec é baseado em diretivas (você pode vê-las com ip xfrm policy ), portanto, se você tiver uma diretiva IPsec que permita o tráfego entre, e. 10.2.0.0/16 e 10.3.0.0/16 somente o tráfego correspondente é realmente encapsulado. Qual não é o caso para pacotes enviados de 10.11.208.94 a 10.11.208.93. Portanto, você precisa adicionar explicitamente um túnel que cubra esses IPs.

    
por 23.12.2015 / 10:46