Verificación de conocimientos - Redes y Conectividad
FinCorp está diseñando un VDC de tres niveles: un nivel web público, un nivel de aplicación privado y un nivel de datos privado. El equipo de seguridad quiere que el nivel de datos sea accesible solo desde el nivel de aplicación, y asume que el Managed Network Load Balancer frente al nivel de datos puede ser bloqueado con una lista de permitidos IP. ¿Qué debería decirles el arquitecto?
Los firewalls de NIC y Network Security Groups se unen a las NIC de los servidores y al VDC, no al ALB/NLB gestionado ni a la capa de abstracción Kubernetes Cluster. La postura correcta es aislar el nivel de datos por topología (LAN privado) y filtrar en los objetivos mismos; esperar que el Load Balancer gestionado realice el filtrado de origen es el error de límite que la plataforma explícitamente no admite.
Un dispositivo de red Firewall autoadministrado debe presentar una sola dirección pública estable IP y conmutar a una instancia de respaldo si la activa se pierde. El equipo ejecutará su propio software de alta disponibilidad dentro del dispositivo. ¿Qué constructo de IONOS es adecuado y qué deben entender sobre él!
La conmutación por error de IP es exactamente el patrón activo-pasivo autoadministrado: provisiona una dirección pública reservada IP en NIC redundantes y permite que el software de alta disponibilidad del invitado decida cuándo conmutar por error, porque la plataforma no supervisa la salud del servicio. Un Load Balancer administrado no puede compartir una LAN con conmutación por error de IP y está diseñado para niveles elásticos; el NAT Gateway es para salida; la conmutación por error DNS dirige nombres, no una sola dirección pública compartida IP en una LAN.
FinCorp debe conectar su centro de datos local a un centro de datos virtual sobre un enlace de sitio a sitio cifrado durante la migración. El dispositivo local actualmente está configurado para IKEv1 con enrutamiento dinámico basado en BGP. ¿Qué es lo que el arquitecto necesita planificar en el IONOS VPN Gateway?
El IONOS VPN Gateway admite IKEv2 y WireGuard, pero no IKEv1, y la ruta es estática a través de las listas de red en la nube y de red del par CIDR; no hay BGP. El par heredado debe ser reconfigurado, y las subredes enrutadas declaradas explícitamente. La puerta de enlace NAT y DNAT no están relacionados con este requisito.
Los servidores de aplicaciones privadas en un VDC deben descargar parches de sistema operativo y llegar a un SaaS API externo, pero nunca deben ser accesibles desde internet y no deben tener IP público. El arquitecto proporciona una puerta de enlace NAT con una IP pública reservada y una regla SNAT, pero los servidores aún no pueden llegar a internet. ¿Cuál es la causa más probable?
Una puerta de enlace NAT es solo SNAT y solo reenvía el tráfico una vez que las máquinas virtuales privadas enrutan el tráfico destinado a internet hacia ella; el cambio de enrutamiento (ruta predeterminada hacia la puerta de enlace, o rutas por objetivo) es el paso que más a menudo se pierde. Una regla DNAT no existe en este producto, y asignar direcciones IP públicas derrotaría el objetivo de egreso privado.
Un arquitecto necesita un enlace privado de baja latencia para intercambiar datos entre dos de los centros de datos virtuales (VDC) propios de FinCorp. Los dos VDC están en diferentes regiones y, para la isolación de facturación, bajo diferentes contratos. ¿Cuál es la opción viable?
El Cross-Connect privado está limitado categóricamente a VDC en la misma región y bajo el mismo contrato, compartiendo un rango de IP; no puede abarcar regiones o contratos. El requisito de cruzar regiones y contratos lo descarta, por lo que el arquitecto debe utilizar un modelo de conectividad diferente. El NAT Gateway proporciona salida de internet, no interconexión privada de VDC a VDC.
FinCorp necesita un failover automatizado para un servicio público cuando el punto de conexión de la región principal falla, redirigiendo a los clientes a un punto de conexión de la región secundaria. No hay un producto de failover gestionado. ¿Cómo debería diseñar el arquitecto esto, y cuál es el principal controlador del tiempo de recuperación?
Sin un producto de failover gestionado, el patrón nativo es el failover de DNS orquestado por el cliente: una comprobación de salud externa (por ejemplo, desde el plano del equilibrio de carga) conduce a la reasignación del registro Cloud DNS a un punto de conexión saludable, y el TTL del registro limita lo rápido que los clientes redirigidos recogen el cambio, lo que lo convierte en el principal controlador del tiempo de recuperación. El propio Cloud DNS no es consciente de la salud. Debido a que DNS solo dirige nuevas conexiones, la capa frontal debe ser sin estado. El failover de IP está limitado a una región LAN, y los controladores NAT/equilibrio de carga no abordan el failover de puntos de conexión entre regiones.