Não é possível ssh ao sistema remoto depois de ativar o IPSec

Question

Eu criei duas VMs em cima do sistema operacional básico e habilitei o IPSec entre as duas VMs. Agora, o problema é que, assim que o IPsec é iniciado e a SA é estabelecida entre as duas VMs, não consigo fazer ping ou ssh na VM pelo SO base, mas as VMs podem fazer ping umas com as outras. Tanto quanto sei, o IPsec cria um túnel entre os IPs especificados, ou seja, os pacotes destinados ao IP B do IP A são criptografados e todos os outros pacotes do IP A podem passar sem criptografia. Estou faltando alguma coisa aqui? O arquivo de configuração usado é:

conn example  
        left=192.168.54.220  
        leftcert=CA_Server  
        leftsubnet=192.168.54.1/24  
        leftsendcert=always  
        leftrsasigkey=%cert  
        right=192.168.54.221  
        rightca=%same  
        rightrsasigkey=%cert  
        rightsubnet=192.168.54.1/24  
        rightcert=CA_Client  
        authby=rsasig  
        ikev2=permit  
        auto=start  

    

Answer 1

IPsec creates a tunnel between the specified IPs only, i.e. packets intended for IP B from IP A gets encrypted and all other packets from IP A can pass through without encryption. Am I missing something here?

Sim. O IPSec cria um túnel entre dois endpoints especificados, left e right . Mas o tráfego que usa esse túnel, ou seja, o tráfego criptografado, está entre duas redes especificadas, leftsubnet e rightsubnet . No seu caso, as duas sub-redes roteadas são as mesmas umas das outras, o que não funcionará.

Se o que você deseja é ter tráfego de A para B criptografado em A e descriptografado em B, e vice-versa, informe a S / WAN definindo leftsubnet como o endereço left , no seu caso 192.168.54.220/32 (a máscara é importante) e definindo rightsubnet como o endereço right , no seu caso 192.168.54.221/32 .

    

Answer 2

As far as I know, IPsec creats a tunnel between the specified IPs only, i.e. packets intended for IP B from IP A gets encrypted and all other packets from IP A can pass through without encryption. Am I missing something here?

Não! Essa é a essência do seu caso de uso atual.

Eu vejo as chaves de sub-rede, mas elas são da mesma sub-rede. Eu não olhei para o código-fonte, então não posso dizer definitivamente que esse é o problema ... mas acho que esse é o problema. Se não estiver roteando ou usando nat, você vai querer o modo de transporte. Aqui está uma configuração ponto-a-ponto que usei algumas semanas atrás:

conn transportModeFirewallToPhoneServer
        authby="psk"
        auto="start"
        compress="no"
        ecn="no"
        esp="aes128-md5"
        ike="aes256-md5-modp1536"
        ikelifetime="7800"
        keyexchange="ike"
        keylife="3600"
        left="hq.myDynDNSDomainToMyOffice.com"
        leftid="hq.myDynDNSDomainToMyOffice.com"
        leftupdown="/usr/libexec/ipsec/updown classic"
        pfs="yes"
        pfsgroup="modp1536"
        pmtu_discovery="no"
        rekeymargin="540"
        right="XXX.XXX.XXX.XXX"
        rightid="XXX.XXX.XXX.XXX"
        type="transport"

Os bits de importação estão à esquerda *, à direita * e ao tipo. Sua configuração parece bem além dessas chaves. Além disso, você disse que já estabelece a VPN, então é claro que você tem o ike & auth correto.