Si se deben hacer dos máquinas (virtuales o no) para comunicarse entre sí, entonces establezca una VPN entre ellas no puede dañar por definición, la VPN tiene como objetivo emular un conjunto aislado de cables entre sus dos hosts (por lo tanto, presumiblemente libres de interferencias e interferencias hostiles) para que el tráfico arbitrario entre las dos máquinas se vuelva "seguro". OpenVPN tiene buena reputación y es gratis, por lo que su uso no es una mala idea. Alternativamente, si las aplicaciones que deben comunicarse entre sí pueden manejar su propia seguridad (por ejemplo, SSL), eso también es aplicable; Sin embargo, la VPN es probablemente más sencilla de configurar y más completa.
Como han dicho otros, si sus máquinas son máquinas virtuales, entonces el proveedor de la nube es Dios: si lo desea, técnicamente puede ver todos sus secretos y alterarlos a voluntad. Por lo tanto, el proveedor es de confianza . Por lo tanto, el proveedor no puede ser un atacante, y se debe asumir que no cae bajo el control hostil. En estas condiciones, si el proveedor puede configurar un "enlace privado" entre sus dos máquinas (una VLAN , de hecho), entonces eso está bien La seguridad de la VLAN es sólida siempre que los cables y enrutadores reales de la red del proveedor sean limpios y honestos, lo que, como acabo de escribir, es una suposición fundamental del modelo de la nube.
Ahora, por supuesto, puede haber una diferencia sutil entre "el proveedor de servicios es honesto" y "el proveedor de servicios es honesto y competente". Un pequeño error de configuración (el temido error humano ) puede poner sistemas de terceros en su VLAN. Una vez más, ejecutar su propia VPN puede agregar protección contra los caprichos del proveedor (no se opondría a la malicia del proveedor, pero la incompetencia es mucho más común que la maldad).
Editar: Olvidé el argumento clásico sobre el rendimiento. Va así:
- Los problemas de rendimiento no existen.
- Los problemas de rendimiento no existen hasta que se midan debidamente .
Entonces, si temes los problemas de rendimiento, entonces la única forma sensata es intentarlo y ver si los temores fueron justificados o no. Se pueden hacer estimaciones a priori pero esto requiere un conocimiento íntimo del comportamiento de los algoritmos involucrados y de los protocolos de red y las latencias; de manera realista, no puede esperar obtener estimaciones decentemente precisas a menos que sea altamente competente en criptografía, programación interna de bajo nivel y internas de TCP / IP. Probar y cuantificar problemas es una manera mucho mejor; la mayoría de las veces, los supuestos problemas de rendimiento resultan ser inexistentes (pero otros problemas de rendimiento inesperados pueden aparecer inesperadamente). Si desea realizar puntos de referencia en OpenVPN, primero debe leer lo que ya se ha hecho sobre el tema, es decir, esta página .