Verificación de conocimientos - Red y conectividad
FinCorp está diseñando un VDC de tres niveles: un nivel web público, un nivel de aplicaciones privado y un nivel de datos privado. El equipo de seguridad desea que el nivel de datos sea accesible únicamente desde el nivel de aplicaciones, y asume que el Load Balancer administrado que se encuentra delante del nivel de datos puede restringirse mediante una lista de permisos de IP. ¿Qué debe decirles el arquitecto?
Los firewalls de NIC y los Network Security Groups se asocian a las NIC de los servidores y al VDC, no al ALB/NLB administrado ni a la capa de abstracción del clúster de Kubernetes. La postura correcta es aislar el nivel de datos mediante la topología (LAN privada) y filtrar en los propios objetivos; esperar que el balanceador de carga administrado realice el filtrado por origen es un error de límite que la plataforma no admite explícitamente.
Un dispositivo de firewall de red autogestionado debe presentar una única IP pública estable y cambiar a una instancia en espera si se pierde la instancia activa. El equipo ejecutará su propio software de alta disponibilidad dentro del dispositivo. ¿Qué constructo de IONOS CLOUD es el adecuado y qué deben comprender al respecto?
La conmutación por error de IP es exactamente el patrón activo-pasivo autogestionado: aprovisiona una única IP pública reservada entre tarjetas de interfaz de red redundantes y permite que el software de alta disponibilidad del cliente decida cuándo realizar la conmutación, porque la plataforma no supervisa el estado del servicio. Un balanceador de carga gestionado no puede compartir una LAN con la conmutación por error de IP y está destinado a capas elásticas; la NAT Gateway es para el tráfico saliente; la conmutación por error de DNS dirige nombres, no una única IP compartida en una LAN.
FinCorp debe conectar su centro de datos en las instalaciones a un VDC a través de un enlace cifrado de sitio a sitio durante la migración. El dispositivo en las instalaciones está configurado actualmente para IKEv1 con enrutamiento dinámico basado en BGP. ¿Qué debe planificar el arquitecto en el VPN Gateway de IONOS CLOUD?
El VPN Gateway de IONOS CLOUD admite IKEv2 y WireGuard, pero no IKEv1, y el enrutamiento es estático mediante las listas CIDR de la red de la nube y de la red del par; no hay BGP. El par heredado debe reconfigurarse y las subredes enrutadas deben declararse de forma explícita. NAT Gateway y DNAT no tienen relación con este requisito.
Los servidores de aplicaciones privados en un VDC deben descargar parches del sistema operativo y acceder a una API SaaS externa, pero nunca deben ser accesibles desde internet y no deben tener ninguna IP pública. El arquitecto aprovisiona un NAT Gateway con una IP pública reservada y una regla de SNAT, pero los servidores aún no pueden acceder a internet. ¿Cuál es la causa más probable?
Un NAT Gateway es exclusivamente de SNAT y solo reenvía el tráfico una vez que las VM privadas dirigen el tráfico destinado a internet hacia él; el cambio de enrutamiento (ruta predeterminada hacia el gateway o rutas por destino) es el paso que más a menudo se omite. No existe una regla de DNAT en este producto, y asignar IPs públicas iría en contra del objetivo de salida privada.
Un arquitecto necesita un enlace privado de baja latencia para intercambiar datos entre dos VDC propios de FinCorp. Los dos VDC se encuentran en regiones diferentes y, por aislamiento de facturación, están bajo contratos distintos. ¿Qué opción es viable?
Private Cross-Connect está limitada de forma categórica a VDC en la misma región y bajo el mismo contrato, compartiendo un solo rango de IP; no puede abarcar regiones o contratos diferentes. El requisito de cruzar regiones y contratos lo descarta, por lo que el arquitecto debe utilizar un modelo de conectividad diferente. NAT Gateway proporciona salida a internet, no interconexión privada entre VDC.
FinCorp necesita un conmutado por error automatizado para un servicio público cuando el punto de acceso de la región principal falla, redirigiendo a los clientes hacia un punto de acceso de la región secundaria. No existe un producto de conmutación por error administrado. ¿Cómo debería el arquitecto diseñar esto y cuál es el factor dominante para el tiempo de recuperación?
Al no existir un producto de conmutación por error administrado, el patrón nativo es el conmutado por error de DNS orquestado por el cliente: una comprobación de estado externa (por ejemplo, del plano del equilibrador de carga) dirige la redirección del registro de Cloud DNS hacia un punto de acceso operativo, y el TTL del registro limita la rapidez con la que los clientes redirigidos detectan el cambio, lo que lo convierte en el factor dominante para el RTO. Cloud DNS en sí mismo no es consciente del estado. Dado que DNS solo dirige las nuevas conexiones, la capa frontal debe ser sin estado. La conmutación por error de IP está vinculada a una sola LAN en una región, y los factores de NAT o del equilibrador de carga no abordan el conmutado por error entre puntos de acceso en diferentes regiones.