VPN IPSec entre Amazon VPC e Linux Server

9

Estou tentando configurar uma conexão VPN IPSec entre nossa rede corporativa e a nuvem privada virtual da Amazon, usando o sistema VPN e um servidor Linux. Infelizmente, o único guia que encontrei discute como configurar o túnel usando uma máquina Linux host e fazer com que essa máquina Linux acesse instâncias de VPC, mas não há nenhuma discussão que eu possa encontrar on-line sobre como fazer com que a instância acesse a rede corporativa (ou o resto da internet através dessa rede).

Informações de rede

Local subnet: 10.3.0.0/25
Remote subnet: 10.4.0.0/16

Tunnel 1:
  Outside IP Addresses:
    - Customer Gateway:        : 199.167.xxx.xxx
    - VPN Gateway              : 205.251.233.121

  Inside IP Addresses
    - Customer Gateway         : 169.254.249.2/30
    - VPN Gateway              : 169.254.249.1/30

Tunnel 2:
  Outside IP Addresses:
    - Customer Gateway:        : 199.167.xxx.xxx
    - VPN Gateway              : 205.251.233.122

  Inside IP Addresses
    - Customer Gateway         : 169.254.249.6/30
    - VPN Gateway              : 169.254.249.5/30

Aqui está o meu /etc/ipsec-tools.conf:

flush;
spdflush;

spdadd 169.254.249.2/30 169.254.249.1/30 any -P out ipsec
   esp/tunnel/199.167.xxx.xxx-205.251.233.121/require;

spdadd 169.254.249.1/30 169.254.249.2/30 any -P in ipsec
   esp/tunnel/205.251.233.121-199.167.xxx.xxx/require;

spdadd 169.254.249.6/30 169.254.249.5/30 any -P out ipsec
   esp/tunnel/199.167.xxx.xxx-205.251.233.122/require;

spdadd 169.254.249.5/30 169.254.249.6/30 any -P in ipsec
   esp/tunnel/205.251.233.122-199.167.xxx.xxx/require;



spdadd 169.254.249.2/30 10.4.0.0/16 any -P out ipsec
   esp/tunnel/199.167.xxx.xxx-205.251.233.121/require;

spdadd 10.4.0.0/16 169.254.249.2/30 any -P in ipsec
   esp/tunnel/205.251.233.121-199.167.xxx.xxx/require;

spdadd 169.254.249.6/30 10.4.0.0/16 any -P out ipsec
   esp/tunnel/199.167.xxx.xxx-205.251.233.122/require;

spdadd 10.4.0.0/16 169.254.249.6/30 any -P in ipsec
   esp/tunnel/205.251.233.122-199.167.xxx.xxx/require;

Aqui está o meu /etc/racoon/racoon.conf:

remote 205.251.233.122 {
        exchange_mode main;
        lifetime time 28800 seconds;
        proposal {
                encryption_algorithm aes128;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2;
        }
        generate_policy off;
}

remote 205.251.233.121 {
        exchange_mode main;
        lifetime time 28800 seconds;
        proposal {
                encryption_algorithm aes128;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2;
        }
        generate_policy off;
}

sainfo address 169.254.249.2/30 any address 169.254.249.1/30 any {
    pfs_group 2;
    lifetime time 3600 seconds;
    encryption_algorithm aes128;
    authentication_algorithm hmac_sha1;
    compression_algorithm deflate;
}

sainfo address 169.254.249.6/30 any address 169.254.249.5/30 any {
    pfs_group 2;
    lifetime time 3600 seconds;
    encryption_algorithm aes128;
    authentication_algorithm hmac_sha1;
    compression_algorithm deflate;
}

O BGP está funcionando bem, então não vou postar essas configurações.

Aqui está o que funciona

  • Na caixa Linux, posso executar ping nos pontos de extremidade locais (169.254.249.2/169.254.249.6) e seus equivalentes remotos (169.254.249.1/169.254.249.5).
  • Também posso executar ping nas instâncias em VPC, SSH para elas etc.
  • Nas instâncias remotas na VPC, também posso executar ping nos terminais locais e remotos
  • Não consigo executar ping nos servidores locais na sub-rede 10.3.0.0/25

Suponho que estou perdendo algo simples, mas tentei adicionar entradas ao ipsec-tools.conf para espelhar o {local endpoint} <-> {remote subnet}, usando {local subnet} <-> {remote endpoint}, mas não parecia funcionar.

Quando eu sigo de {instância remota} para {servidor local}, o tempo limite é excedido. Os pacotes são visíveis na interface eth0 (mesmo que a rede local esteja em eth1).

O Google tem sido de pouca ajuda; mostra apenas pessoas tentando usar o OpenSwan, ou tendo problemas semelhantes, mas com roteadores de hardware ou usando ferramentas mais antigas.

vpn  ipsec  amazon-vpc 
— Dan Udey
fonte
Não sou especialista, mas parece que a partir daqui, wiki.debian.org/IPsec, é necessário adicionar rotas manualmente à rede local remota ao usar o ipsec, mas posso estar errado ..
— user993553

Respostas:

3

Bem, eu trapacei :) Instalei o gateway Astaro, oficialmente suportado pela Amazon, e depois o usei para modelar o meu. Você pode simplesmente fazer o SSH na unidade Astaro e ver como eles configuram tudo. Obviamente, você pode ficar com a unidade Astaro se quiser pagar.

— Petter
fonte
1
Você poderia elaborar sua solução? O que você quer dizer com "model my own"? Estou preso no mesmo problema e estaria interessado em como você o resolveu, obrigado!
— Max
3

Descobri isso. Tive que mudar meu ipsec-tools.conf para isso:

flush;
spdflush;

# Generic routing
spdadd 10.4.0.0/16 10.3.0.0/25 any -P in  ipsec esp/tunnel/205.251.233.121-199.167.xxx.xxx/require;
spdadd 10.3.0.0/25 10.4.0.0/16 any -P out ipsec esp/tunnel/199.167.xxx.xxx-205.251.233.121/require;

# Tunnel 1
spdadd 169.254.249.1/30 169.254.249.2/30 any -P in  ipsec esp/tunnel/205.251.233.121-199.167.xxx.xxx/require;
spdadd 169.254.249.2/30 169.254.249.1/30 any -P out ipsec esp/tunnel/199.167.xxx.xxx-205.251.233.121/require;

spdadd 10.4.0.0/16 169.254.249.2/30 any -P in  ipsec esp/tunnel/205.251.233.121-199.167.xxx.xxx/require;
spdadd 169.254.249.2/30 10.4.0.0/16 any -P out ipsec esp/tunnel/199.167.xxx.xxx-205.251.233.121/require;

# Tunnel 2
spdadd 169.254.249.5/30 169.254.249.6/30 any -P in  ipsec esp/tunnel/205.251.233.122-199.167.xxx.xxx/require;
spdadd 169.254.249.6/30 169.254.249.5/30 any -P out ipsec esp/tunnel/199.167.xxx.xxx-205.251.233.122/require;

spdadd 10.4.0.0/16 169.254.249.6/30 any -P in  ipsec esp/tunnel/205.251.233.122-199.167.xxx.xxx/require;
spdadd 169.254.249.6/30 10.4.0.0/16 any -P out ipsec esp/tunnel/199.167.xxx.xxx-205.251.233.122/require;

E mude meu racoon.conf para isso:

path pre_shared_key "/etc/racoon/psk.txt";

remote 205.251.233.122 {
        exchange_mode main;
        lifetime time 28800 seconds;
        proposal {
                encryption_algorithm aes128;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2;
        }
        generate_policy off;
}

remote 205.251.233.121 {
        exchange_mode main;
        lifetime time 28800 seconds;
        proposal {
                encryption_algorithm aes128;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2;
        }
        generate_policy off;
}

sainfo address 169.254.249.2/30 any address 169.254.249.1/30 any {
    pfs_group 2;
    lifetime time 3600 seconds;
    encryption_algorithm aes128;
    authentication_algorithm hmac_sha1;
    compression_algorithm deflate;
}

sainfo address 169.254.249.6/30 any address 169.254.249.5/30 any {
    pfs_group 2;
    lifetime time 3600 seconds;
    encryption_algorithm aes128;
    authentication_algorithm hmac_sha1;
    compression_algorithm deflate;
}

sainfo address 10.3.0.0/25 any address 10.4.0.0/16 any {
    pfs_group 2;
    lifetime time 3600 seconds;
    encryption_algorithm aes128;
    authentication_algorithm hmac_sha1;
    compression_algorithm deflate;
}

No entanto, essa configuração, como eu a entendo, só roteará o tráfego entre 10.3.0.0/25 e 10.4.0.0/16 sobre o primeiro túnel (via xxx121). Vou atualizar a resposta quando descobrir isso.

— Dan Udey
fonte
Também estou com esse problema há algum tempo e sua resposta realmente ajudou. Você encontrou uma solução para fazer o roteamento pelos dois túneis? Adicionei as partes 'Roteamento genérico' com o outro IP do túnel, mas ainda não o testei.
— Will
Não encontrei nenhuma boa solução para rotear pelos dois túneis, mas acho que faz sentido em um contexto. A idéia aqui é fornecer redundância e, idealmente, isso incluiria redundância nas duas extremidades. Você pode configurar um servidor separado no segundo túnel e fornecer duas rotas para suas VPNs (por exemplo, fornecendo aos servidores padrão duas rotas, uma para cada caixa). Ou você aciona o failover manual com algum tipo de sistema de monitoramento. Nenhuma das soluções é realmente 'ideal', mas a primeira também fornece redundância.
— Dan Udey
0

Você sabe o motivo de usar "require" em vez de "use" para a configuração do setkey? Você também sabe se importa em que ordem eu coloco as instruções nas seções remota e sainfo e duplico por engano certas declarações? Por exemplo:

#original
remote 205.251.233.121 {
        exchange_mode main;
        lifetime time 28800 seconds;
        proposal {
                encryption_algorithm aes128;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2;
        }
        generate_policy off;
}

vs

#edited
remote 205.251.233.121 {
        generate_policy off;                           #moved/duplicated
        lifetime time 28800 seconds;
        proposal {
                dh_group 2;                           #moved
                encryption_algorithm aes128;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
        }
         exchange_mode main;                      #moved
        generate_policy off;                   #duplicated/moved
}

Você também descobriu como fazer o tráfego fluir nos dois túneis?

Obrigado por qualquer orientação.

— DPfiler
fonte
Bem-vindo ao Serverfault. Parece que você está tentando fazer uma pergunta na seção de respostas da pergunta de outro pôster. Se você tiver uma nova pergunta, poste-a como uma nova pergunta, acessando serverfault.com e clicando no grande botão vermelho "Fazer pergunta".
— vjones
Obrigado, pelo acompanhamento.
— DPfiler
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.