IPsec VPN site-to-site: Como devo configurar os arquivos ipsec.conf em ambos os sites para obter o túnel?

Navegue suas respostas
5

O que estou tentando fazer é criar uma VPN IPsec site-a-site entre minha rede e a rede de meu amigo. Nós dois temos um roteador e dois computadores em cada roteador, com todos os computadores executando o Linux. Então eu acho que a topologia se parece com isso

[myPC1 + myPC2] --- myRouter ------ internet ----- hisRouter --- [hisPC1 + hisPC2]

Ambos os roteadores são baratos, então eles não têm nada parecido com o OpenWRT.

Então a configuração - eu acho que isso deve ser feito no Linux em ambos os lados.

Até agora, tentamos com o openSwan ambos com chaves RSA e PSK, mas depois do comando 

ipsec auto --up net-to-net

ou recebemos o erro "nenhuma conexão chamada net-to-net" ou o erro "Não podemos nos identificar com nenhum dos dois extremos dessa conexão".

Acho que estamos configurando o arquivo ipsec.conf errado. Alguém poderia explicar como devemos configurá-lo corretamente para alcançar essa topologia, por favor?

EDITAR ...

Aqui estão alguns fatos que podem ajudar você a entender melhor o meu caso.
Estes são todos do exemplo PSK que testamos.

Meu ifconfig: 

eth0 Link encap:Ethernet HWaddr 00:0C:29:1B:F5:1C
inet addr:192.168.1.78 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fe1b:f51c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:829 errors:0 dropped:0 overruns:0 frame:0
TX packets:704 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1213737 (1.1 MiB) TX bytes:57876 (56.5 KiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:53 errors:0 dropped:0 overruns:0 frame:0
TX packets:53 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3664 (3.5 KiB) TX bytes:3664 (3.5 KiB)

Seu ifconfig 

Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:240 (240.0 b) TX bytes:240 (240.0 b)

p2p1 Link encap:Ethernet HWaddr 08:00:27:2A:F1:F5
inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe2a:f1f5/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:21104 errors:0 dropped:0 overruns:0 frame:0
TX packets:12458 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:16079321 (15.3 MiB) TX bytes:1012204 (988.4 KiB)

O arquivo ipsec.conf, nós dois usamos exatamente o mesmo arquivo, também o colocamos em /etc/init.d 

version 2.0    
config setup    
    protostack=netkey    
    nat_traversal=yes    
    #virtual_private=    
    oe=off    

conn net-to-net  
    authby=secret                # Key exchange method  

    left=212.251.112.115         # Public Internet IP address of the
    leftsubnet=10.0.2.0/24       # Subnet protected by the LEFT VPN device  
    leftnexthop=%defaultroute    # correct in many situations  

    right=79.103.7.114           # Public Internet IP address of
    rightsubnet=192.168.1.0/24   # Subnet protected by the RIGHT VPN device  
    rightnexthop=%defaultroute   # correct in many situations

    auto=start                   # authorizes and starts this connection

Também usamos os mesmos ipsec.secrets, que ambos colocamos em /etc/init.d 

212.251.112.115 79.103.7.114 : PSK "123"

temos esses IPs com o ifconfig.me Após essa configuração, executamos: 

service ipsec restart  
ipsec verify

e recebemos a mesma mensagem de falha no send_redirects, que se recusou a mudar para 0 

Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                                 [OK]
Linux Openswan U2.6.37/K3.1.0-7.fc16.x86_64 (netkey)
Checking for IPsec support in kernel                            [OK]
 SAref kernel support                                           [N/A]
 NETKEY:  Testing XFRM related proc values                      [FAILED]

  Please disable /proc/sys/net/ipv4/conf/*/send_redirects
  or NETKEY will cause the sending of bogus ICMP redirects!

    [FAILED]

  Please disable /proc/sys/net/ipv4/conf/*/accept_redirects
  or NETKEY will accept bogus ICMP redirects!

    [OK]
Checking that pluto is running                                  [OK]
 Pluto listening for IKE on udp 500                             [OK]
 Pluto listening for NAT-T on udp 4500                          [OK]
Checking for 'ip' command                                       [OK]
Checking /bin/sh is not /bin/dash                               [OK]
Checking for 'iptables' command                                 [OK]
Opportunistic Encryption Support                                [DISABLED]

então prosseguimos com 

ipsec auto --up net-to-net

e nós dois conseguimos 

022 "net-to-net": We cannot identify ourselves with either end of this connection.

Eu não sei se isso ajuda, talvez você já tenha percebido o que está errado, mas aqui está uma última coisa, o status do ipsec: 

ipsec auto --status
000 using kernel interface: netkey
000 interface lo/lo ::1
000 interface lo/lo 127.0.0.1
000 interface lo/lo 127.0.0.1
000 interface eth0/eth0 192.168.1.78
000 interface eth0/eth0 192.168.1.78
000 %myid = (none)
000 debug none
000 
000 virtual_private (%priv):
000 - allowed 0 subnets: 
000 - disallowed 0 subnets: 
000 WARNING: Either virtual_private= is not specified, or there is a syntax 
000          error in that line. 'left/rightsubnet=vhost:%priv' will not work!
000 WARNING: Disallowed subnets in virtual_private= is empty. If you have 
000          private address space in internal use, it should be excluded!
000 
000 algorithm ESP encrypt: id=2, name=ESP_DES, ivlen=8, keysizemin=64, keysizemax=64
000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=8, keysizemin=192, keysizemax=192
000 algorithm ESP encrypt: id=6, name=ESP_CAST, ivlen=8, keysizemin=40, keysizemax=128
000 algorithm ESP encrypt: id=7, name=ESP_BLOWFISH, ivlen=8, keysizemin=40, keysizemax=448
000 algorithm ESP encrypt: id=11, name=ESP_NULL, ivlen=0, keysizemin=0, keysizemax=0
000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=13, name=ESP_AES_CTR, ivlen=8, keysizemin=160, keysizemax=288
000 algorithm ESP encrypt: id=14, name=ESP_AES_CCM_A, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=15, name=ESP_AES_CCM_B, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=16, name=ESP_AES_CCM_C, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=18, name=ESP_AES_GCM_A, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=19, name=ESP_AES_GCM_B, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=20, name=ESP_AES_GCM_C, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=22, name=ESP_CAMELLIA, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=252, name=ESP_SERPENT, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=253, name=ESP_TWOFISH, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP auth attr: id=1, name=AUTH_ALGORITHM_HMAC_MD5, keysizemin=128, keysizemax=128
000 algorithm ESP auth attr: id=2, name=AUTH_ALGORITHM_HMAC_SHA1, keysizemin=160, keysizemax=160
000 algorithm ESP auth attr: id=5, name=AUTH_ALGORITHM_HMAC_SHA2_256, keysizemin=256, keysizemax=256
000 algorithm ESP auth attr: id=6, name=AUTH_ALGORITHM_HMAC_SHA2_384, keysizemin=384, keysizemax=384
000 algorithm ESP auth attr: id=7, name=AUTH_ALGORITHM_HMAC_SHA2_512, keysizemin=512, keysizemax=512
000 algorithm ESP auth attr: id=8, name=AUTH_ALGORITHM_HMAC_RIPEMD, keysizemin=160, keysizemax=160
000 algorithm ESP auth attr: id=9, name=AUTH_ALGORITHM_AES_CBC, keysizemin=128, keysizemax=128
000 algorithm ESP auth attr: id=251, name=(null), keysizemin=0, keysizemax=0
000 
000 algorithm IKE encrypt: id=0, name=(null), blocksize=16, keydeflen=131
000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, blocksize=8, keydeflen=192
000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, blocksize=16, keydeflen=128
000 algorithm IKE hash: id=1, name=OAKLEY_MD5, hashsize=16
000 algorithm IKE hash: id=2, name=OAKLEY_SHA1, hashsize=20
000 algorithm IKE dh group: id=2, name=OAKLEY_GROUP_MODP1024, bits=1024
000 algorithm IKE dh group: id=5, name=OAKLEY_GROUP_MODP1536, bits=1536
000 algorithm IKE dh group: id=14, name=OAKLEY_GROUP_MODP2048, bits=2048
000 algorithm IKE dh group: id=15, name=OAKLEY_GROUP_MODP3072, bits=3072
000 algorithm IKE dh group: id=16, name=OAKLEY_GROUP_MODP4096, bits=4096
000 algorithm IKE dh group: id=17, name=OAKLEY_GROUP_MODP6144, bits=6144
000 algorithm IKE dh group: id=18, name=OAKLEY_GROUP_MODP8192, bits=8192
000 algorithm IKE dh group: id=22, name=OAKLEY_GROUP_DH22, bits=1024
000 algorithm IKE dh group: id=23, name=OAKLEY_GROUP_DH23, bits=2048
000 algorithm IKE dh group: id=24, name=OAKLEY_GROUP_DH24, bits=2048
000 
000 stats db_ops: {curr_cnt, total_cnt, maxsz} :context={0,0,0} trans={0,0,0} attrs={0,0,0} 
000 
000 "net-to-net": 10.0.2.0/24===212.251.112.115<212.251.112.115>[+S=C]---192.168.1.254...192.168.1.254---79.103.7.114<79.103.7.114>[+S=C]===192.168.1.0/24; unrouted; eroute owner: #0
000 "net-to-net":     myip=unset; hisip=unset;
000 "net-to-net":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
000 "net-to-net":   policy: PSK+ENCRYPT+TUNNEL+PFS+IKEv2ALLOW+SAREFTRACK+lKOD+rKOD; prio: 24,24; interface: ; 
000 "net-to-net":   newest ISAKMP SA: #0; newest IPsec SA: #0;

Mais uma pergunta é como o problema NETKEY [Failed] pode ser resolvido, se for necessário!

    
por Deneb 04.05.2012 / 11:18

1 resposta

24

Minha palavra, você tem seu trabalho cortado. ESTÁ BEM; aqui está uma espécie de resumo, porque no momento você tem os fundamentos tão errados que os detalhes não importam.

Antes de mais nada, o fato de você não ter endereços públicos estáticos para cada uma das suas conexões com a Internet é um problema. O IPSec não suporta facilmente túneis em tais configurações [1], então você vai acabar editando seu ipsec.conf toda vez que um dos seus endereços mudar. OK?

Agora, quando perguntei se cada ponto de extremidade do OpenSWAN tinha um endereço IP público e você disse "sim" com confiança, descobriu-se - como eu suspeitava - que você estava errado. Sua saída ifconfig me mostra que uma extremidade tem o endereço 192.168.1.78 e a outra tem o endereço 10.0.2.15. Você também me diz que uma extremidade está (atualmente) atrasada no endereço IP público 212.251.112.115 e a outra está atrás de 79.103.7.114. Você não diz qual é qual, então eu assumirei que 192.168.1.78 está atrás de 212.251.112.115 e 10.0.2.15 está atrás de 79.103.7.114. Se isso estiver errado, apenas inverta a correspondência. Também chamarei o antigo par left e o último par right . Não faz diferença qual é qual, mas isso vai nos ajudar a manter nosso raciocínio em ordem, o que seria uma boa ideia agora.

Você precisará configurar os roteadores públicos em ambas as extremidades para encaminhar o UDP / 500 e os protocolos 50 e 51 (apenas para integridade) para os pontos de extremidade do OpenSWAN dentro de cada endereço público. Se você não conseguir gerenciar as duas perfurações de protocolo, então investigue o doco na passagem NAT e encaminhe UDP / 4500 também.

Em primeiro lugar, é um requisito que cada extremidade encontre seu próprio endereço IP na configuração, para que cada extremidade possa saber qual é a esquerda e a direita quando é inicializada. Então, a esquerda precisa ter um ipsec.conf que contenha 

conn net-to-net  
    authby=secret
    left=192.168.1.78
    leftsubnet=192.168.1.0/24
    leftnexthop=%defaultroute
    right=79.103.7.114
    rightsubnet=10.0.2.0/24

e um ipsec.secrets que diz 

192.168.1.78 79.103.7.114: PSK "123"

enquanto o direito deve ter um ipsec.conf que contenha 

conn net-to-net  
    authby=secret
    left=212.251.112.115
    leftsubnet=192.168.1.0/24
    right=10.0.2.15
    rightsubnet=10.0.2.0/24 
    rightnexthop=%defaultroute

e um ipsec.secrets que diz 

10.0.2.15 212.251.112.115: PSK "123"

Cada final precisa realmente saber quem realmente é, enquanto pode fingir que não se importa que o fim remoto esteja por trás de um NAT. Você vê?

Além disso, você precisará configurar todos os clientes em cada extremidade para que eles tenham uma rota para a rede RFC1918 remota através do ponto de extremidade OpenSWAN local. Você precisará verificar se /proc/sys/net/ipv4/ip_forward está definido como 1 em cada endpoint. E seria uma boa ideia desligar qualquer firewall nos dois endpoints, pelo menos por enquanto. Você também pode precisar ativar algumas variáveis de configuração que dizem a cada endpoint para não se importar que o endpoint remoto pense que possui um endereço IP diferente do que o endpoint local acha que possui; da memória, estes são leftid= e rightid= , mas você terá que resolver isso por si mesmo.

Então, isso é o básico. Se você tiver a topologia e os conceitos fundamentais certos, o resto é apenas a depuração dos detalhes. Boa sorte com isso.

[1] Isso não é bem verdade. As implementações SWAN suportam criptografia IPSec oportunista, mas isso requer que você controle seu DNS reverso em ambas as extremidades, e estou supondo que não. Novamente, leia as man pages se você quiser saber mais sobre isso.

    
por 07.05.2012 / 10:39

Tags

Raid 5 com hot spare ou RAID 10 sem hot spare? O Ubuntu é um substituto viável do Windows XP para ambientes de pequenas empresas?