VPN en entornos de servidor dedicado / alojamiento en la nube, túneles IPSec vs tinc

Estoy en el proceso de diseñar una configuración de red privada virtual para un entorno de alojamiento en la nube. Dados nuestros requisitos, realmente no veo esto como diferente de un entorno de servidor dedicado. La idea es que queremos permitir que los clientes puedan exigir que sus usuarios se conecten a máquinas virtuales específicas o servidores dedicados utilizando una VPN que podría proporcionar cifrado auxiliar (por ejemplo, para trabajos de impresión enviados a las redes de los clientes).

Estamos buscando soportar host a host IPSec (ESP y AH) y, por supuesto, túneles SSH, pero ninguno de estos realmente ofrece la capacidad de usar adaptadores VPN. Por lo tanto, estamos considerando agregar al menos algunos de los siguientes, pero dado que el espacio es muy importante, queremos estandarizar no más de uno o dos de estos (uno sería mejor):

1. Soporte de túnel IPSec en el host virtual o dedicado
2. tinc
3. PPTP

Debido a que nuestros servidores que realizan copias de seguridad, etc., pueden estar en diferentes centros de datos, preferiríamos poder reutilizar nuestro enfoque de VPN aquí. Esto parecería descartar PPTP. Mi opinión actual es que es probable que IPSec sea mejor porque podemos usar adaptadores VPN estándar, pero es probable que configurar el enrutamiento (según los requisitos del cliente) sea significativamente más difícil, por lo que también estamos analizando tinc.

¿Cuál de estos dos es preferible? ¿Temo que la administración de enrutamiento sea un dolor de cabeza severo con IPSec injustificado? ¿Hay alguna manera fácil de evitar esto? ¿Hay otros problemas con respecto a tinc que me faltan (es decir, aparte de requerir un cliente por separado)?

Actualización en respuesta a la respuesta de @ Wintermute :

Sí, esta pregunta es desde la perspectiva del servidor. La razón es que estos son servidores efectivamente desconectados de las redes del cliente. Sí, nuestro mercado objetivo es la red de PYME. Sí, esperamos usar IP públicas para cada servidor cliente a menos que necesiten algo diferente (y luego podemos hablar).

La solución a la que nos estamos inclinando es aquella en la que los clientes definen los túneles IP y los rangos de red accesibles por esos túneles y donde los unimos con nuestras propias herramientas de administración (que están en desarrollo), que conectan las solicitudes de los clientes con los cambios de configuración. El problema es que, dado que no es probable que ejecutemos software de enrutamiento en vms y servidores, la tabla de enrutamiento debe administrarse estáticamente para que los clientes que cometen errores en la configuración descubran que las VPN no funcionan correctamente.

También es probable que usemos ESP a través de la red para nuestras propias operaciones internas (para cosas como copias de seguridad). Toda la configuración es bastante compleja y tiene muchas perspectivas diferentes, desde centrada en el servidor (nuestro cliente vpn a la instancia alojada) a centrada en la red (material interno), hasta centrada en la base de datos (nuestras herramientas). Por lo tanto, no diría que la pregunta es representativa de todo nuestro enfoque (y se hacen preguntas en varios sitios de SE).

Sin embargo, nada de esto realmente afecta la pregunta en su conjunto. Sin embargo, es quizás un contexto útil.

No estoy seguro acerca de tinc pero IPSEC es casi obligatorio. Ningún negocio serio confiaría en PPTP.

No estoy seguro de cómo IPSEC afecta el enrutamiento. Un túnel es un túnel es un túnel independientemente del cifrado. Te encontrarás con los mismos problemas con respecto a: dividir el túnel o no, haciendo que los clientes comprendan el concepto / mira los conflictos de IP de LAN de un cliente en particular con el grupo VPN que has elegido, etc.

Parece que apunta al mercado de las PYME (servidores individuales, inicio de sesión directo, etc.) para descartar soluciones más sofisticadas, pero de todos modos enumeraré dos enfoques posibles

• algún tipo de concentrador VPN que permite perfiles. Todos los clientes inician sesión en el concentrador VPN y, según su perfil / grupo / cualquier teminología del proveedor, obtienen permisos para usar el protocolo X a IP Y (es decir, su propio servidor).

• Enrutadores virtuales Cisco ASR1000V: cada cliente obtiene uno, luego puede ejecutar túneles IPSEC directos (con VTI para que el enrutamiento parezca fácil) o incluso dirigir MPLS a los clientes para que el enrutador aparezca como una rama más en su topología, luego asigne sus VNIC VLAN, etc. en el interior para que obtengan una "rama" virtual agradable.

• En una versión más pequeña de lo anterior, hemos utilizado monowall con gran efecto para este propósito (es decir, cada cliente obtiene un dispositivo virtual de capa 3 que actúa como un enrutador / firewall, se conectan a este dispositivo y obtienen acceso a sus VLAN únicamente) Sin embargo, cada enrutador / firewall necesita su propia dirección IP pública.

Re: su enfoque actual, se da cuenta de que cada servidor necesita una IP pública o tiene un sistema complicado y complicado de NAT donde la ruta VPN de cada cliente recibe un puerto único o similar.

Recomiendo obtener un networker a tiempo completo para que revise cualquier diseño / propuesta que tenga, parece que viene desde un fondo de servidor.

Sí tienes razón. Parece que tendrá que lidiar con tener IP separadas a menos que se agregue a través de un concentrador VPN. TBH, el concentrador es probablemente la mejor opción, solo necesitará 1 IP adicional para todas las conexiones VPN, pero su interfaz externa deberá residir en una subred / VLAN diferente de los hosts de IP públicos. Yo diría que, de lo contrario, está configurando IPSEC VPN directamente en cada servidor individual, qué pesadilla