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.

vpn  ipsec  amazon-vpc 
— 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
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.