Dos Direcciones de Tráfico, Una Caja
Bienvenidos
La mayoría de los diagramas de arquitectura muestran tráfico que va en una dirección: el cliente en la parte superior, el servidor en la parte inferior, una flecha apuntando hacia abajo. La realidad tiene tráfico que va en ambas direcciones.
Ingreso: los clientes externos llegan a tus servicios a través de este camino. Un proxy inverso en el borde de tu red network termina TLS, rutea solicitudes y aplica políticas de acceso.
Egreso: tus servicios llegan a servicios externos a través de este camino. Llamada a un procesador de pago API, recuperación de un objetivo de webhook, envío de una solicitud a un socio. A menudo a través de un proxy frontal o un gateway NAT con una lista de permitidos.
Muchas arquitecturas comienzan con una caja que maneja ambos. Funciona, hasta el día en que no lo hace. El modo de falla es sutil, solo se manifiesta después de que existen suficientes servicios internos y enseña una lección importante de separación de preocupaciones.
Al final de esta lección, entenderás:
- Por qué el ingreso y el egreso representan patrones de tráfico fundamentalmente diferentes con ejes de escalabilidad y modos de falla diferentes
- NAT con bucle de cabello y por qué un proxy que intenta conectarse a sí mismo falla
- El desvío arquitectónico: una caja se convierte en dos, y lo que cada una posee a partir de entonces
- Ganancias de aislamiento de seguridad: cada lado puede bloquearse a sus verdaderos pares permitidos
- Cómo identificar cuándo tu diseño de una sola caja ha cruzado el umbral en el que la división es necesaria
Por qué las Direcciones Requieren Herramientas Diferentes
Dos Cargas de Trabajo Diferentes en un Límite de Red
Características del tráfico de ingreso:
- Iniciado por partes externas (la internet en general)
- El volumen escala con tu base de usuarios
- Terminación de TLS, enrutamiento de solicitudes, limitación de tasa por origen
- Preocupaciones de defensa en profundidad: DDoS, abuso, rastreador
- Necesita una IP pública que acepte conexiones de cualquiera
Características del tráfico de egreso:
- Iniciado por tus propios servicios (un conjunto conocido y pequeño de clientes)
- El volumen escala con los patrones de llamada de servicio a servicio y API externa
- Lista de permitidos de direcciones IP de origen en puntos finales remotos (tienes una IP de salida fija que los socios confían)
- Preocupaciones de profundidad de defensa: extracción de datos, servicios internos comprometidos que llaman a otros
- Debería rechazar las conexiones de cualquier persona aparte de tus propios servicios
La clave asimetría: la entrada acepta tráfico del mundo; la salida acepta tráfico solo de tus propios servicios. Colocarlos en la misma máquina significa que esa máquina debe ser accesible tanto desde el mundo (para la entrada) como solo desde tus servicios (para la salida). Las reglas de firewall que satisfacen una trabajan en contra de la otra.
El camino de crecimiento: un pequeño proyecto puede esconder ambos detrás de una IP y una herramienta, porque el volumen es pequeño y la lista de IP de los socios es corta. A medida que el proyecto crece, la fricción entre los dos roles aumenta y un día un modo de falla específico (NAT en bucle) fuerza la separación.
El Bicho Que Forza La Separación
Una Historia De Apagón Desnormalizado
Imagina una bifurcación arquitectónica real que ocurre en flotas de producción. Los nombres a continuación se han cambiado; la forma es idéntica a lo que los equipos chocan en la selva.
Una organización ejecuta un servidor proxy en 203.0.113.5. Maneja la entrada (puerto 443 para los usuarios) y la salida (puerto 1080 SOCKS5 para servicios internos que llaman a otros). Los servicios internos viven en subredes privadas y dirigen todo el tráfico de salida a través de ese proxy SOCKS5 en 203.0.113.5:1080.
Uno de los servicios alojados detrás de 203.0.113.5 es api.example.com. El DNS público resuelve api.example.com a 203.0.113.5.
Ahora un servicio interno diferente necesita llamar a api.example.com. Su ruta de salida:
1. El servicio interno resuelve api.example.com → 203.0.113.5
2. El servicio interno envía la solicitud a través del proxy de salida SOCKS5 en 203.0.113.5:1080
3. El proxy intenta abrir una conexión desde sí mismo a 203.0.113.5:443
4. Negado la conexión. El paquete tendría que salir y volver a entrar en el mismo NAT, lo que la mayoría de los conjuntos de redes rechazan. El proxy no puede conectarse a sí mismo a través de su propia IP pública.
Este es NAT en bucle: un paquete que sale de un NAT y necesita volver a entrar en el mismo NAT para llegar a su destino. Sin el soporte especial de NAT en capa de enrutamiento, el paquete se cae.
¿Por qué aparece tarde
Al principio del proyecto, cada servicio interno se comunicaba con otros servicios internos mediante un nombre de host privado (internal-api.local) o no llamaba a los servicios públicos de su propia organización. La ruta de enlace simplemente no existía.
Luego, se requería una nueva función para que el servicio A llamara a api.example.com (un nombre de host público). Se activó la ruta de enlace. Se negó la conexión. Apagado.
La solución arregló el síntoma (forzó al resolutor a dar la IP privada de api.example.com en lugar de la pública). La causa raíz: una sola caja estaba haciendo demasiados trabajos.
El tenedor arquitectónico
Una caja se convierte en dos
La solución limpia: separar el proxy en dos máquinas.
Servidor de ingreso (IP pública 203.0.113.5):
- Caddy / proxy inverso en los puertos 80, 443
- Los registros DNS públicos apuntan aquí
- Hospeda api.example.com, app.example.com, etc.
Servidor de salida (diferente IP pública 203.0.113.99):
- SOCKS5 / proxy forward en el puerto 1080
- El firewall restringe las conexiones entrantes solo a IPs del subred interno
- Los servicios internos rutean todo lo que sale a través de esta dirección
Lo que esto compra:
1. Resuelto el enlace en bucle. Un servicio interno que llama a api.example.com se conecta de salida a través de 203.0.113.99 (egress), que luego se conecta normalmente a 203.0.113.5 (ingreso, una IP diferente). El bucle NAT desaparece porque las dos IPs viven en máquinas diferentes.
2. Aislamiento de seguridad. El servidor de salida puede bloquear en un conjunto pequeño de IPs internas. El servidor de ingreso permanece abierto al mundo. Dos conjuntos de reglas, cada uno expresando un papel limpiamente.
3. Escala independiente. La banda de ingreso escala con los usuarios; la banda de salida escala con la actividad del servicio interno. Actualice uno sin tocar al otro.
4. Aislamiento de fallas. Un mal configurado servidor de salida ya no rompe el sitio público. Un DDoS contra el sitio público ya no agota la banda de salida.
5. Modelo mental más claro. Cada máquina tiene un solo trabajo. Los ingenieros razonan sobre las preocupaciones de ingreso sin pensar en egreso, y viceversa.
Dos ejes, dos decisiones de tamaño
Escalabilidad independiente
Antes del corte, el crecimiento en cualquiera de las direcciones ponía presión en la misma máquina. Después del corte, cada dirección tiene su propia provisión.
Tamaño de ingreso: se escala con los usuarios. Las decisiones de capacidad viven en la capa frontal (más réplicas de proxy inverso, VMs más grandes, CDN en frente). Presupuesto de ancho de banda calculado contra el tráfico de usuario en el pico.
Tamaño de egreso: se escala con el volumen de llamadas internas a API externas. A menudo se domina por la entrega de webhook, las llamadas a procesadores de pago o la recuperación de datos de terceros. Presupuesto de ancho de banda calculado contra los patrones de llamada interna.
Aislamiento de fallas: un DDoS contra el ingreso frontal público ya no consume ancho de banda de egreso (aquellas llamadas a procesadores de pago siguen a través de cualquiera). Un crash del proxy de egreso ya no lleva abajo el sitio público (los usuarios siguen llegando al sitio; solo las llamadas internas de salida fallan).
SLOs diferentes: la disponibilidad de ingreso importa para los usuarios (aparente corte del sitio); la disponibilidad de egreso importa para los operadores (fallas de fondo que pueden tardar más en detectarse). Cada lado puede llevar su propio SLO.
Varios servidores de egreso
Una vez que el rol de egreso es su propia máquina, el siguiente movimiento obvio es correr varios servidores de egreso detrás de un equilibrador de carga para HA. Cada nuevo servicio interno apunta al nombre de host de egreso (que resuelve en la piscina equilibrada) en lugar de a una IP única.
La misma lección que el resto de los sistemas distribuidos: una vez que una capa se vuelve sin estado y tiene su propio rol, se multiplica barato.
Una nueva integración de socio
Tu organización ejecuta el corte de ingreso / egreso como se diseñó. El servidor de egreso tiene una IP pública fija (203.0.113.99) que has allowlistado con tres API de socios existentes (un procesador de pago, un gateway de SMS, un proveedor de correo).
Un equipo de producto quiere agregar una cuarta integración: un sistema de entrega de webhooks que llama de vuelta a los puntos de extremo de los clientes en todo el mundo. Predicción de volumen: 10,000 llamadas por minuto, con picos de hasta 30,000.
Diseñar un límite de red para un servicio en crecimiento
Síntesis
Usted ha aprendido por qué el ingreso y el egreso requieren herramientas diferentes, el fallo de NAT hairpin que fuerza la división en flotas reales y cómo se acumulan la escalabilidad independiente, el aislamiento de seguridad y el aislamiento de fallas una vez que la división se produce.
Aplique los cuatro.
Una empresa de software como servicio de tamaño medio ejecuta tres subdominios de producto (app, api, admin) para sus usuarios, además de cuatro integraciones de salida (Stripe, Twilio, SendGrid, un sistema de webhook para clientes). Hoy en día todo vive detrás de una sola máquina de proxy con una IP pública. Han comenzado a recibir informes de fallas hairpin intermitentes cuando los servicios internos intentan llamar a api.example.com. Desean diseñar una solución permanente.
Adónde Va Este Curso A Continuación
Adónde Va Este Curso A Continuación
Ahora ha visto uno de los refactores de separación de responsabilidades más limpios en los sistemas distribuidos: una caja se convierte en dos, cada una con un papel claro, y el sistema hereda beneficios de escalabilidad, seguridad e aislamiento de fallas a lo largo del camino.
La próxima lección (cs_distsys_failure_modes_and_blast_radius) extiende la razón de aislamiento de fallas. Leerá un postmortem de DNS-SERVFAIL sanitizado, identificará el patrón de falla en cascada y escribirá acciones sin culpa que objetiven los sistemas en lugar de las personas.
Lección complementaria: geometry_of_ingress_egress_separation representa la división como un gráfico bipartito y explora los vértices de corte, las particiones de la red y lo que la teoría de grafos te dice sobre la frontera de una red.
Bien hecho. Adelante.