VPN IPSec entre Amazon VPC y el servidor Linux

9

Estoy tratando de configurar una conexión VPN IPSec entre nuestra red corporativa y la Nube privada virtual de Amazon, utilizando su sistema VPN y un servidor Linux. Desafortunadamente, la única guía que he encontrado discute cómo configurar el túnel usando una máquina Linux host y hacer que esa máquina Linux acceda a instancias VPC, pero no hay discusión que pueda encontrar en línea sobre cómo hacer que la instancia acceda a la red corporativa (o el resto de Internet a través de esa red).

Información de red

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

Aquí está mi /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;

Aquí está mi /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;
}

BGP funciona bien, así que no voy a publicar esas configuraciones.

Esto es lo que funciona.

  • Desde el cuadro de Linux, puedo hacer ping a los puntos finales locales (169.254.249.2/169.254.249.6) y sus equivalentes remotos (169.254.249.1/169.254.249.5).
  • También puedo hacer ping a las instancias en VPC, SSH, etc.
  • Desde las instancias remotas en VPC, también puedo hacer ping a los puntos finales locales y remotos
  • No puedo hacer ping a los servidores locales en la subred 10.3.0.0/25

Supongo que me falta algo simple, pero he intentado agregar entradas a ipsec-tools.conf para reflejar el {punto final local} <-> {subred remota}, usando {subred local} <-> {punto final remoto}, Pero no parecía funcionar.

Cuando hago ping desde {instancia remota} a {servidor local}, se agota el tiempo de espera. Los paquetes son visibles en la interfaz eth0 (aunque la red local esté en eth1).

Google ha sido de poca ayuda; muestra solo a personas que intentan usar OpenSwan, o que tienen problemas similares pero con enrutadores de hardware, o que usan herramientas más antiguas.

Dan Udey
fuente
No soy un experto, pero parece que desde aquí wiki.debian.org/IPsec que tienes que agregar manualmente rutas a la red local remota cuando utilizas ipsec, podría estar equivocado ...
user993553

Respuestas:

3

Bueno, hice trampa :) Instalé la puerta de enlace Astaro que es oficialmente compatible con Amazon y luego la usé para modelar la mía. Puede simplemente SSH en la unidad Astaro y ver cómo configuran todo. Por supuesto, puede quedarse con la unidad Astaro si tiene ganas de pagarla.

Petter
fuente
1
¿Podría por favor elaborar su solución? ¿Qué quieres decir con "model my own"? Estoy atrapado en el mismo problema, y ​​estaría interesado en cómo lo resolvió, ¡gracias!
Max
3

Lo averigué. Tuve que cambiar mi ipsec-tools.conf a esto:

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;

Y cambie mi mapache.conf a esto:

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;
}

Sin embargo, esta configuración, según tengo entendido, solo enrutará el tráfico entre 10.3.0.0/25 y 10.4.0.0/16 a través del primer túnel (a través de xxx121). Actualizaré la respuesta cuando descubra eso.

Dan Udey
fuente
También he estado atrapado con este problema por un tiempo y su respuesta realmente ayudó. ¿Se te ocurrió una solución para enrutar los dos túneles? Agregué las partes de 'Enrutamiento genérico' con la otra IP del túnel, pero no lo he probado.
Será
No encontré ninguna buena solución para el enrutamiento en ambos túneles, pero creo que eso tiene sentido en un contexto. La idea aquí es proporcionar redundancia, e idealmente eso incluiría redundancia en ambos extremos. Puede configurar un servidor separado en el segundo túnel y proporcionar dos rutas a sus VPN (por ejemplo, proporcionando a sus servidores estándar dos rutas, una a cada caja). O eso, o activa la conmutación por error manual con algún tipo de sistema de monitoreo. Ninguna de las soluciones es realmente 'óptima', pero la primera también brinda redundancia de su parte.
Dan Udey
0

¿Conoces la razón para usar "require" en lugar de "use" para la configuración setkey? ¿Sabes también si importa en qué orden coloco las declaraciones dentro de las secciones remotas y sainfo y duplico por error ciertas declaraciones? Por ejemplo:

#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
}

¿También descubriste cómo hacer que el tráfico fluya en ambos túneles?

Gracias por cualquier orientación

DPfiler
fuente
Bienvenido a Serverfault. Parece que estás intentando hacer una pregunta en la sección de respuestas de la pregunta de otro póster. Si tiene una nueva pregunta, publíquela como una nueva pregunta yendo a serverfault.com y haciendo clic en el botón rojo grande "Preguntar".
vjones
Lo haré, gracias por el seguimiento.
DPfiler