Cómo los nombres, las traducciones, los intermediarios y los pools determinan la ruta real de una API
Edición en profundidad — material de estudio y consulta profesional
Por João Ricardo Dutra••Material completo
Presentación del capítulo
En capítulos anteriores, estudiamos cómo una aplicación produce una solicitud, cómo o transportan datos entre procesos y cómo o identifican interfaces y permiten a los enrutadores elegir una ruta. Este capítulo agrega los componentes que hacen que una arquitectura empresarial sea utilizable a escala: transforma nombres estables en destinos mutables; traduce identidades de red; los dividen una comunicación en conexiones independientes; y los equilibradores seleccionan una instancia entre varias posibilidades.
Estos mecanismos a menudo se dibujan en un solo diagrama como cuadros consecutivos, pero tienen diferentes responsabilidades. normalmente participa antes de la conexión. cambia los campos de los paquetes y mantiene el estado de traducción. Un cierra una conexión y crea otra, pudiendo interpretar el protocolo de la aplicación. Un equilibrador aplica una estrategia de selección sobre un conjunto de objetivos. Un mismo producto puede realizar varias de estas funciones, lo que hace imprescindible distinguir el concepto de la implementación.
En entornos , los errores atribuidos a la aplicación suelen surgir antes de que se ejecute la política. Es posible que un registro privado no sea visible para el tiempo de ejecución; una respuesta puede permanecer almacenada en caché; un grupo puede considerar una instancia en buen estado mediante una prueba superficial; un puede reemplazar al Anfitrión; un equilibrador puede finalizar con un certificado diferente; o un puede utilizar un origen no previsto por la lista de permitidos del . El último síntoma podría ser tiempo de espera, 502, 503, error de certificado o comportamiento intermitente.
El objetivo de este capítulo es proporcionar un modelo mental de un extremo a otro. Al final, el lector debería poder localizar dónde se tomó una decisión, qué datos se cambiaron y qué evidencia se debe recopilar en cada etapa. La atención se centra no en memorizar productos, sino en comprender los principios que se aplican a Axway , Azure Management, NGINX, HAProxy, Envoy, dispositivos de red, controladores de ingreso y servicios administrados en la nube.
Principio central
El nombre, la dirección, la conexión, el mensaje y la instancia de son objetos diferentes. Un diagnóstico fiable registra la transformación entre ellos en cada salto.
Objetivos de aprendizaje
Explique la jerarquía , las zonas, las delegaciones y las funciones del stub resolver, el resolvedor recursivo y el .
Interpretar consultas, respuestas, códigos, banderas y los principales tipos de registros de recursos utilizados en las .
Relacione los cambios de , caché positiva, caché negativa y con el comportamiento real del cliente.
Comprenda por qué utiliza y , la función de y el impacto del bloqueo selectivo.
Diseñe públicos, privados y de horizonte dividido para puertas de enlace, puntos finales privados y entornos híbridos.
Diferenciar entre , DoT, DoH y TSIG, incluyendo qué protege cada mecanismo y qué no.
Profundice la básica, , , , horquilla , tiempos de espera y agotamiento de puertos.
Distinga el , el , la puerta de enlace y el según la semántica .
Compare el paso a través de , la descarga, el recifrado y cuando hay intermediarios.
Diferenciar balanceo L4, L7 y basado en , además de algoritmos de selección y afinidad.
Diseñe controles de estado, preparación, drenaje, inicio lento y conmutación por error sin producir falsos positivos.
Aplicar los conceptos a Axway y los servicios de Azure utilizados en arquitecturas .
Diagnosticar fallas de resolución, 502/503, origen inesperado, distribución desigual y agotamiento de .
Estructura del capítulo
4.1 Cuatro decisiones diferentes en el camino hacia una
4.2 Arquitectura y jerarquía
4.3 Zonas, delegaciones y autoridad
4.4 e iterativa
4.5 Mensajes y registros de recursos
4.6 , almacenamiento en caché y propagación
4.7 , , EDNS y cifrado
4.8 privado, horizonte dividido y descubrimiento de servicios
4.9 Disponibilidad y equilibrio basados en
4.10 Seguridad y
4.11 en profundidad
4.12 , , horquilla y CGNAT
4.13 en y nube
4.14 Intermediarios
4.15 , , puerta de enlace y
4.16 Capa 4, Capa 7 y terminación
4.17 Host, , y encabezados reenviados
4.18 Fundamentos del balanceo de carga
4.19 Algoritmos de selección
4.20 Controles de salud y ciclo de vida
4.21 Agrupación de afinidad, estado y conexión
4.22 Arquitectura multicapa
4.23 Aplicación en Axway y Azure
4.24 Solución de problemas
4.25 Estudios de casos y laboratorios
Resumen, lista de verificación, ejercicios, glosario y referencias.
4.1 Cuatro decisiones diferentes en el camino hacia una
Cuando una aplicación llama a :// .empresa.com/clientes, la primera decisión es la resolución: ¿a qué dirección o servicio corresponde el nombre .empresa.com? Esta decisión la toma el sistema de resolución de nombres, normalmente , y puede producir una dirección , , una cadena de alias o información de servicio adicional. El resultado puede depender del entorno, la ubicación del resolvedor, el caché y las políticas de tráfico global.
La segunda decisión es la traducción. Al atravesar una , se reemplazan las direcciones y eventualmente los puertos del flujo. El destino puede observar la de un firewall, puerta de enlace en la nube o grupo , en lugar de la original de la aplicación. Esta traducción es una operación de red orientada al estado y no es equivalente al , aunque ambos mecanismos pueden existir en el mismo equipo.
La tercera decisión es de intermediación. Un recibe una conexión del cliente, interpreta o reenvía el mensaje y crea otra conexión ascendente. A partir de este existen dos relaciones de transporte independientes: cliente- y - . Los tiempos de espera, las versiones , los certificados, las direcciones de mantenimiento y de origen pueden ser diferentes para cada tramo.
La cuarta decisión es la selección de instancias. Cuando hay varios destinos elegibles, un equilibrador elige cuál recibirá el flujo o la solicitud. La elección depende del algoritmo, pesos, estado de salud, afinidad y políticas de localidad. , y también pueden realizar algún tipo de distribución, pero el momento y la granularidad de elección son diferentes.
Tabla 1 - Responsabilidades que deben analizarse por separado.
Mecanismo
Entrada principal
Decisión o transformación
Evidencia típica
DNS
Nombre y tipo de registro
Devuelve datos de resolución
excavar, nslookup, Resolve-DnsName
NAT
Flujo de IP/puerto
Traducir origen o destino
Tabla NAT, captura, registros de flujo
apoderado
Conexión y protocolo
Finaliza y recrea la comunicación.
Registro de acceso, registro ascendente, encabezados
equilibrador de carga
Grupo elegible
Seleccionar destino
Salud, algoritmo, métricas de backend
4.2 Arquitectura y jerarquía
El Sistema de Nombres de Dominio fue diseñado como una base de datos jerárquica distribuida. En lugar de mantener una tabla central que contenga todos los nombres de Internet, el espacio de nombres se organiza como un árbol invertido. La parte superior es la raíz, representada por un . Debajo se encuentran dominios de nivel superior como com, org y br. Cada sucursal se puede delegar en diferentes organizaciones, que luego gestionan las áreas correspondientes.
Un nombre completo, o , se compone de etiquetas separadas por puntos. En .pagamentos.empresa.com., , pagos, empresa y com son etiquetas, y el explica la raíz. Las interfaces y herramientas a menudo omiten este final, pero la distinción entre nombre absoluto y nombre relativo es importante en los archivos de y en las configuraciones que agregan sufijos de búsqueda.
La jerarquía proporciona escalabilidad administrativa. La organización responsable de com no necesita conocer las direcciones de .empresa.com; debe indicar qué servidores tienen autoridad de empresa.com. De manera similar, la empresa.com puede delegar pagos.empresa.com a otro equipo. La resolución pasa por estas referencias hasta llegar a una autoridad capaz de responder al nombre consultado.
no es sólo una lista de nombres- . Almacena conjuntos de datos escritos llamados conjuntos de registros de recursos. Un nombre puede tener registros A, , TXT, MX, CAA y otros. La respuesta correcta depende del nombre, clase y tipo solicitado. Este modelo explica por qué puede existir un nombre y aún no tener el tipo de registro solicitado.
Figura 1: la autoridad se distribuye entre zonas y delegaciones en el árbol .
nombre absoluto
En configuración , .empresa.com y .empresa.com. se puede interpretar de manera diferente. El indica que el nombre ya está completo y no debe tener el sufijo de la actual.
4.3 Zonas, delegaciones y autoridad
Una es la parte del espacio de nombres administrada como una unidad. y dominio no son sinónimos perfectos: un dominio puede contener subdominios delegados que pertenecen a otras zonas. La empresa.com, por ejemplo, puede contener registros para .empresa.com y delegado socios.empresa.com. Después de la , los registros internos de los socios se mantienen en los servidores designados para la nueva .
La la publican los registros NS en el lado principal. Dependiendo de la posición de los propios servidores de nombres, pueden ser necesarios registros adicionales llamados glue para evitar la dependencia circular. Si empresa.com es atendido por ns1.empresa.com, el padre debe proporcionar la dirección de ns1.empresa.com junto con la referencia; de lo contrario, el resolvedor tendría que consultar la antes de saber cómo llegar a ella.
El registro SOA describe las propiedades administrativas de la , como el servidor principal, el contacto, el número de serie y los temporizadores relacionados con la transferencia y el caché negativo. El serial es utilizado por servidores secundarios para detectar cambios. El diseño de alta disponibilidad normalmente publica varios servidores autoritativos en redes y ubicaciones independientes, y a menudo utiliza anycast para distribuir consultas.
Una respuesta autoritativa significa que el servidor responde en función de la para la que tiene autoridad, no sólo en función del caché. La bandera AA del mensaje indica esta condición en las respuestas apropiadas. En la resolución de problemas, preguntar a un resolvedor recursivo y preguntar directamente a cada son pruebas diferentes: la primera revela la experiencia del cliente; el segundo ayuda a identificar divergencias entre servidores y propagación de zonas.
Tabla 2 - Componentes de autoridad y delegación.
Elemento
Función
Fallo típico
Zona
unidad administrativa de datos DNS
Registro creado en la zona incorrecta
Delegación NS
Indica autoridad de la zona infantil.
NS inconsistente o no disponible
pegamento
Proporciona dirección para el servidor de nombres dentro de la zona delegada.
Dependencia de resolución circular
SOA serie
Versiones del contenido de la zona
Secundario no detecta actualización
servidor autoritativo
Responde a los datos del área.
Respuestas divergentes entre réplicas.
4.4 e iterativa
Normalmente, la aplicación no atraviesa la jerarquía directamente. Utiliza un stub resolver del sistema operativo, que envía una consulta al resolvedor recursivo configurado en la red. El stub resolver solicita una respuesta final y generalmente activa el indicador RD, recursividad deseada. El resolvedor recursivo consulta su caché y, cuando es necesario, toma medidas para obtener la respuesta en nombre del cliente.
En la resolución iterativa, los servidores intermedios devuelven la mejor información que tienen, normalmente una referencia a los servidores de la siguiente. El recursivo comienza con una raíz, recibe una referencia al TLD, consulta el TLD, recibe una referencia a la autoridad y luego consulta la de anotación. El resultado se almacena en caché de acuerdo con los de los RRsets recibidos.
La ruta exacta puede ser más compleja debido a los , las delegaciones, los registros adicionales y la validación de . Un indica que el nombre consultado es un alias de otro nombre; el resolvedor debe continuar resolviendo hasta obtener el tipo final. Cada enlace tiene su propio y puede apuntar a una administrada por otra organización o proveedor de tráfico.
En las redes corporativas, el resolvedor recursivo puede actuar como reenviador y reenviar consultas a otro resolvedor en lugar de atravesar la jerarquía pública. Esta cadena es común en sucursales, y entornos de nube. También crea dependencias: una regla de reenvío condicional incorrecta puede provocar que nombres privados salgan a Internet o crear bucles entre servidores .
Figura 2: ejemplo simplificado de con consultas iterativas.
Comandos de vigilancia: solo se ejecutan en entornos autorizados
# Linux / macOS
dig api.empresa.com A
dig api.empresa.com AAAA
dig +trace api.empresa.com
dig @ns1.exemplo.net api.empresa.com A +norecurse
# Windows PowerShell
Resolve-DnsName api.empresa.com -Type A
Resolve-DnsName api.empresa.com -Type AAAA
Resolve-DnsName api.empresa.com -Server 10.0.0.10
4.5 Mensajes y registros de recursos
El mensaje tiene un encabezado y cuatro secciones lógicas: Pregunta, Respuesta, Autoridad y Adicional. El encabezado incluye identificador, banderas y contadores de registros. Entre las banderas relevantes se encuentran QR, que distingue consulta y respuesta; RD y RA, relacionados con la recursividad; AA, que indica respuesta autoritaria; TC, que señala truncamiento; y el código de respuesta, como NOERROR, NXDOMAIN o SERVFAIL.
Los datos se transportan como registros de recursos. Un RR contiene nombre, tipo, clase, y datos específicos. Los registros con el mismo nombre, tipo y clase forman un y deben tratarse como un conjunto. Esta idea es importante en y múltiples registros A o : el orden presentado no debe confundirse con garantías de selección o afinidad.
A y asocian nombres con direcciones e . crea un alias para otro nombre y tiene restricciones de coexistencia con otros datos en el mismo nodo. NS informa servidores autoritativos. SOA describe la . PTR se utiliza en resolución inversa. MX dirige el correo. TXT transporta texto estructurado por diferentes protocolos. SRV le permite descubrir el host y el puerto de un servicio, mientras que CAA informa qué autoridades certificadoras pueden emitir certificados para el dominio.
Las modernas también pueden encontrar registros SVCB y , que le permiten anunciar las propiedades, alternativas y parámetros de conexión de un servicio. El soporte depende del cliente y de la plataforma; por lo tanto, estos registros no reemplazan automáticamente la configuración A, o de . El arquitecto debe separar la existencia del patrón de la capacidad realmente desplegada en el entorno.
Tabla 3 - Registros frecuentes de recursos en entornos corporativos.
Tipo
Datos principales
Uso en arquitectura API
un
dirección IPv4
Punto final público o privado
AAAA
dirección IPv6
Doble pila y acceso IPv6
CNOMBRE
Nombre canónico
Alias para puerta de entrada, CDN o servicio gestionado
NS
Servidor de nombres
Delegación de zona
SOA
Metadatos de zona
Parámetros seriales y administrativos.
PTR
Nombre asociado a la IP
Resolución inversa y auditoría
SRV
Prioridad, peso, puerto y destino
Descubrimiento de servicios en protocolos compatibles
CAA
CA autorizada
Gobernanza de la emisión de certificados
texto
texto arbitrario
Verificaciones y políticas de dominio
Ficha de didáctica con bloques de documentación
; Ejemplo didáctico de zona
$ORIGIN empresa.com.
$TTL 300
@ IN SOA ns1.empresa.com. dnsadmin.empresa.com. (
2026071501 ; serial
3600 ; refresh
600 ; retry
1209600 ; expire
300 ) ; negative cache
IN NS ns1.empresa.com.
IN NS ns2.empresa.com.
api IN A 198.51.100.25
api IN AAAA 2001:db8:20::25
status IN CNAME api.empresa.com.
4.6 , almacenamiento en caché y significado de propagación
El de un registro de recursos indica cuánto tiempo pueden permanecer los datos en la memoria caché. Cuando un resolvedor recibe un con 300, puede reutilizarlo durante cinco minutos sin consultar nuevamente a la autoridad. El valor disminuye en la caché y la entrada caduca cuando llega a cero. Authoritative no envía notificaciones a todos los cachés cuando cambia el registro; por lo tanto, diferentes clientes pueden observar respuestas antiguas hasta que caduquen sus entradas.
La expresión propagación de se utiliza de manera informal, pero puede ocultar diferentes fenómenos: transferencia de entre entidades autorizadas, actualización de los servidores de un proveedor, caducidad de cachés recursivos, caché del sistema operativo, caché de aplicaciones e incluso agrupación de conexiones para la dirección anterior. Cambiar el registro en el panel y confirmar el nuevo valor en el autoritativo no garantiza que una aplicación con caché o conexión persistente lo utilice inmediatamente.
Un bajo reduce el posible período de datos obsoletos y es útil antes de las migraciones, pero aumenta las consultas, la dependencia del y la carga operativa. Además, algunos componentes aplican valores mínimos, máximos o sus propias estrategias de actualización. Para un cambio planificado, el debe recortarse con suficiente antelación para que el valor anterior caduque en las cachés antes del recorte.
La caché negativa almacena el conocimiento de que un nombre no existe, representado por NXDOMAIN, o que el nombre existe pero no tiene el tipo solicitado, a menudo llamado NODATA. Esta optimización reduce las consultas repetidas, pero sorprende a los equipos que crean un registro justo después de una respuesta negativa. El tiempo de caché negativo se deriva de la información de la según las reglas actuales.
Figura 3: La caché sigue siendo válida hasta que caduque el , incluso para respuestas negativas.
Cambio de final seguro
Antes de cambiar una dirección, reduzca el , espere a que caduque el anterior, valide el nuevo objetivo, realice el recorte y mantenga el objetivo anterior disponible durante la ventana de transición cuando sea posible.
4.7 , , EDNS y cifrado
Las consultas clásicas utilizan el puerto 53 a través de y . tiene un coste menor ya que no establece conexión y responde a la mayoría de consultas. Sin embargo, sobre no es solo un mecanismo de transferencia de : las implementaciones deben admitirlo para respuestas grandes y truncadas y escenarios modernos. Un firewall que permite /53 y bloquea /53 puede crear fallas selectivas que son difíciles de reproducir.
En el formato original, un mensaje tenía un pequeño límite práctico. agrega un pseudorregistro OPT mediante el cual el solicitante anuncia los recursos y el tamaño de la carga útil que puede recibir. Los valores exagerados pueden provocar fragmentación de ; Los valores adecuados buscan equilibrar la eficiencia y la confiabilidad. Cuando la respuesta no encaja, el servidor puede configurar el indicador TC y el cliente vuelve a intentarlo a través de .
sobre , normalmente asociado al puerto 853, y sobre , transportado a través de , protegen el canal entre el cliente y el resolvedor contra observación o alteración en la ruta. No convierten al resolvedor en una autoridad confiable por sí mismos y no proporcionan autenticación criptográfica de datos de como . La organización necesita evaluar la privacidad, la gobernanza, el filtrado y la observabilidad al habilitar resolvedores externos o DoH integrado en las aplicaciones.
En las redes corporativas, interceptar o bloquear DoH sin una estrategia puede dañar las aplicaciones, mientras que liberarlas indiscriminadamente puede eludir las políticas privadas de , registro y seguridad. El objetivo de la arquitectura debe ser proporcionar resolvedores corporativos que sean confiables, redundantes y compatibles con los mecanismos requeridos, al tiempo que controlan explícitamente qué canales alternativos están permitidos.
Figura 4: tiene múltiples transportes; cada uno resuelve un problema diferente.
Tabla 4 - Fallos relacionados con el transporte DNS.
Síntoma
Posible causa
prueba
Las consultas simples funcionan, DNSSEC falla
EDNS o respuestas grandes filtradas
cavar + dnssec y capturar
UDP funciona, la gran respuesta falla
TCP/53 bloqueado después de TC=1
excavar + tcp
La aplicación omite el DNS privado
Propio Departamento de Salud o resolución externa
Verifique el destino DNS de la aplicación
Tiempo de espera solo en una rama
Fragmentación/MTU o firewall DNS
Compare la carga útil y la ruta de EDNS
4.8 privado, horizonte dividido y descubrimiento de servicios
El privado publica nombres que solo deben resolverse en determinados entornos, como redes corporativas, redes virtuales, clústeres y centros de datos. El acceso depende de qué resolvedores y zonas son visibles para la fuente. Puede existir un final privado sin una integración adecuada y aún así quedar inutilizable: la aplicación continuará resolviendo el nombre en el final público o recibirá NXDOMAIN.
En horizonte dividido, el mismo nombre devuelve diferentes respuestas según la ruta de resolución. Un cliente externo puede recibir la dirección pública, mientras que la puerta de enlace interna recibe la dirección privada del . Esta técnica preserva nombres, certificados y consistentes, pero requiere disciplina para evitar divergencias silenciosas entre zonas públicas y privadas.
El reenvío condicional dirige consultas para ciertos sufijos a resolvedores específicos. En un entorno híbrido, la VNet puede reenviar las corp.empresa al centro de datos, mientras que el centro de datos reenvía zonas de enlace privado o de nube al resolvedor correspondiente. Las reglas simétricas mal diseñadas pueden crear bucles y la falta de reglas puede filtrar nombres internos a los resolvedores públicos.
El descubrimiento de servicios en Kubernetes y mallas de servicios también utiliza nombres y registros, pero los ciclos de vida son más dinámicos. Un servicio puede resolverse en una de clúster virtual, una lista de pods o un final de . El corto y el comportamiento de almacenamiento en caché del cliente son decisivos. Las bibliotecas que se resuelven una vez al inicio no rastrean los cambios, mientras que los servidores como Envoy pueden consumir de descubrimiento y tener una vista explícita de los puntos finales.
Figura 5: el mismo puede dirigir clientes públicos y privados a diferentes puntos finales.
El final privado no es
El final proporciona conectividad privada. La aplicación aún necesita resolver el nombre de la dirección privada, tener una ruta y pasar las políticas de red y .
4.9 Disponibilidad y equilibrio basados en
puede devolver varias direcciones o elegir respuestas según la prioridad, el peso, la ubicación, el rendimiento y las políticas de salud. Esta técnica se utiliza para la distribución global y la conmutación por error entre regiones. La decisión se produce en la resolución; después de eso, el cliente se conecta directamente al final devuelto. Por lo tanto, el servicio no necesariamente observa la conexión o solicitud de aplicación.
El comportamiento depende del resolvedor recursivo. Las políticas geográficas pueden ver la dirección del resolvedor, que puede estar lejos del usuario real. El controla cuánto tiempo permanece la decisión en caché. Durante una falla, los clientes con una respuesta anterior pueden continuar probando el final no disponible hasta que caduque el caché o la aplicación implemente su propio respaldo.
Múltiples registros A o por sí solos no constituyen un balanceador de verificación de salud. El orden puede variar y los clientes sólo pueden elegir la primera dirección. Eliminar un registro no finaliza las conexiones existentes y no elimina la entrada de todas las cachés inmediatamente. El balanceo de carga basado en debe combinarse con puntos finales resistentes y monitoreo compatible con ventanas de caché.
Anycast es otra técnica utilizada por la infraestructura y los servicios globales. La misma dirección se anuncia en varias ubicaciones y el enrutamiento de Internet lleva al cliente a una instancia cercana según la topología BGP. Anycast no es una operación por turnos de : la respuesta puede contener una única , mientras que la distribución se produce en la capa de enrutamiento.
Tabla 5 - Diferentes formas de distribución global.
Estrategia
Momento de decisión
ventaja
Limitación
A/AAAA Múltiplos
En el cliente/resolvedor
Simplicidad
La salud y las opciones varían según el cliente.
GSLB por DNS
Durante la resolución
Distribución global y conmutación por error
Vista TTL y resolvedor
cualquier transmisión
Enrutamiento IP
Punto final global con proximidad
Depende de los anuncios y la convergencia.
proxy inverso global
Con cada conexión/solicitud
Control L7, WAF y TLS
El tráfico pasa por el servicio.
4.10 Seguridad y
El clásico se creó en un entorno con supuestos de confianza diferentes a los actuales. Los ataques pueden explotar respuestas falsificadas, envenenamiento de caché, servidores comprometidos, secuestro de la configuración del resolvedor y registros administrativos alterados. Los identificadores aleatorios, los puertos de origen impredecibles y las validaciones adicionales aumentan la resiliencia, pero no proporcionan una prueba criptográfica completa del origen de los datos.
agrega autenticación de origen e integridad a los datos a través de firmas sobre RRsets y una cadena de confianza basada en registros DS y DNSKEY. Un resolvedor validador puede distinguir datos firmados válidos, respuestas demostrablemente inexistentes y fallas de validación. no proporciona confidencialidad: los observadores aún pueden ver nombres y respuestas en el tradicional.
La validación depende del tiempo, las claves, las firmas y la publicación correcta. Una rotación mal ejecutada o una firma caducada pueden convertir una existente en SERVFAIL para los clientes validadores. Por lo tanto, requiere procedimientos específicos de monitoreo, sincronización horaria y transferencia. El beneficio es reducir la posibilidad de que un intermediario presente datos manipulados como si fueran autorizados.
sobre y sobre protegen el transporte al resolvedor, mientras que protege la autenticidad de los datos entre la firmada y el validador. TSIG, a su vez, autentica transacciones entre participantes que comparten una clave, como transferencias y actualizaciones dinámicas. Estos mecanismos son complementarios y no deben tratarse como sustitutos.
Volver a vincular
Las aplicaciones que confían únicamente en el nombre recibido del usuario pueden resolverse inicialmente en una pública y luego en una dirección interna. Los controles deben validar destinos, rangos, redireccionamientos y nuevas resoluciones efectivos, no solo la cadena del nombre de host.
4.11 en profundidad
La traducción de direcciones de red modifica las direcciones de los paquetes a medida que atraviesan un dispositivo perimetral. En básica, una dirección de un dominio se asigna a otra dirección. En o , la traducción incluye identificadores de transporte, lo que permite que múltiples conexiones internas compartan una dirección externa a través de diferentes puertos. El dispositivo mantiene el estado para invertir la traducción en el tráfico de retorno.
Una traducción cambia los campos cubiertos por sumas de verificación. necesita ajustar la y las sumas de verificación de transporte de acuerdo con el protocolo. Los protocolos que transportan direcciones o puertos dentro de la carga útil pueden requerir puertas de enlace a nivel de aplicación o fallar porque la traducción de encabezados no actualiza automáticamente los datos internos. La criptografía que protege estos campos también limita la capacidad de traducción transparente.
no es un firewall, aunque suele estar en el mismo equipo. El hecho de que una conexión entrante no tenga asignación no reemplaza la política de filtrado explícita. Port forwarding y pueden publicar servicios internos; las conexiones iniciadas desde dentro crean el estado; Las reglas del firewall determinan lo que se debe permitir. La seguridad debe modelarse como una política, no como un efecto secundario de abordarla.
La presencia de rompe la transparencia de las direcciones de un extremo a otro. Los registros de muestran la identidad traducida y los protocolos que dependen de la del cliente necesitan otro mecanismo. En , los servidores controlados pueden insertar Forwarded o X-Forwarded-For, pero estos encabezados son metadatos de la aplicación y pueden falsificarse si el borde no elimina los valores enviados por el consumidor.
Figura 6: permite que los flujos internos compartan una dirección externa a través de diferentes puertos.
4.12 , , en horquilla y CGNAT
La de origen cambia el origen del flujo y es común cuando se sale a Internet o a una red asociada. La de destino cambia el destino y se utiliza para publicar un servicio interno detrás de una dirección virtual. Una conexión puede atravesar ambos: el cliente llega a un VIP que es para el servidor, y el retorno puede ser para garantizar la simetría y ocultar la topología interna.
Hairpin , también llamado loopback, ocurre cuando un cliente interno accede a la dirección externa de un servicio que también está en la red interna. El dispositivo necesita traducir y guiar el flujo de regreso al interior. Sin soporte o configuración correcta, el cliente puede resolver el nombre público, enviarlo al firewall y recibir una respuesta directa del servidor, rompiendo el estado esperado. A menudo se utiliza dividido para evitar este camino.
de nivel de operador permite a los proveedores compartir direcciones entre suscriptores. En arquitecturas B2B, esto reduce la utilidad de identificar a un consumidor únicamente mediante pública. Varios clientes pueden compartir la misma dirección y el grupo puede cambiar. La lista de permitidos por puede seguir siendo un requisito de conectividad, pero no debería ser la única autenticación de una confidencial.
La doble ocurre cuando el flujo atraviesa traducciones sucesivas, por ejemplo, local, CGNAT y en la nube. Cada estado tiene sus propios tiempos de espera y límites de puertos. La solución de problemas debe registrar el origen observado en cada límite; asumir que la de la estación llegará al produce reglas y auditorías incorrectas.
Tabla 6 - Modalidades de traducción y sus impactos.
Tipo
Campo cambiado
uso frecuente
Riesgo operacional
SNAT
Origen
Salida de puerta de enlace/API al backend
Agotamiento de puertos y lista de permitidos
ADNT
Destino
Publicación VIP o de servicio.
retorno asimétrico
PAT/NAPT
IP y puerto
Compartir dirección externa
Estado y tiempo de espera
horquilla
Traducción interna de retorno
Acceso interno a dirección externa
flujo asimétrico
CGNAT
Origen en el proveedor
Compartir IPv4 entre suscriptores
IP no identifica al cliente
4.13 en y entornos de nube
Una crea conexiones salientes a . Dependiendo del modo de red, estas conexiones pueden salir a través de las direcciones propias de la instancia, a través de un , firewall, dispositivo o conjunto de administradas. El analiza esta fuente traducida y necesita permitir todas las direcciones posibles. El escalado, el cambio de niveles o el mantenimiento pueden cambiar la distribución entre las fuentes documentadas por la plataforma.
El agotamiento de se produce cuando demasiadas conexiones competidoras o conexiones cortas consumen los puertos disponibles para una combinación de origen y destino. El problema se agrava cuando la agrupación de conexiones está deshabilitada, los tiempos de espera mantienen los estados durante mucho tiempo o una única saliente sirve a un gran volumen. Los síntomas incluyen fallas de conexión intermitentes, tiempo de espera de conexión y recuperación espontánea después de que caducan los estados.
La solución no es sólo agregar reintentos. Los reintentos agresivos pueden consumir aún más puertos. El diseño debe reutilizar conexiones, dimensionar direcciones y puertos de salida, distribuir destinos, ajustar tiempos de espera con discreción y monitorear el uso. Cuando la plataforma ofrece integración privada sin o con múltiples , la elección debe considerar la capacidad y la previsibilidad de la fuente.
El final privado entrante y la conectividad privada saliente son direcciones diferentes. Un final privado para la puerta de enlace permite a los consumidores acceder a ella de forma privada; no garantiza que la puerta de enlace acceda a los a través de una red privada. Cada tramo requiere su propio , ruta, firewall, identidad y .
Diagnóstico
Recopile la cantidad de conexiones nuevas por segundo, conexiones establecidas, TIME_WAIT, destinos, salientes, errores de conexión y métricas de plataforma. Un 502 en la puerta de enlace puede ser consecuencia de una falta de /puerto antes de cualquier respuesta del .
4.14 Intermediarios
permite una cadena de intermediarios. 9110 distingue formas comunes como , puerta de enlace y . En la práctica, el vocabulario del producto varía, pero la pregunta técnica es estable: ¿el componente interpreta los mensajes y crea una nueva conexión, o simplemente reenvía bytes después de establecer un ? La respuesta determina qué políticas, registros y transformaciones son posibles.
Cuando un intermediario finaliza , recibe un mensaje completo o una secuencia de protocolo, aplica reglas y envía otro mensaje al siguiente salto. Puede cambiar el Host, la ruta, la consulta, los encabezados, la codificación y la versión . El no observa directamente el del consumidor; observa la conexión creada por el intermediario. Esta separación explica por qué la , el certificado y la latencia medidas en el representan el .
Los intermediarios mejoran la seguridad y la gobernanza centralizando la autenticación, , limitación de velocidad, enrutamiento y observabilidad. Al mismo tiempo, agregan colas, tiempos de espera, , límites de carga útil y puntos de falla. Cada capa debe tener un propósito claro. Apilar , , Application , , ingress y sin definir responsabilidades produce duplicidad de , reintentos y reglas contradictorias.
Un también modifica la semántica de fallas. Si no puede conectarse al flujo ascendente, puede devolver 502. Si el grupo no está disponible, puede devolver 503. Si el flujo ascendente excede el tiempo de espera, puede devolver 504. Es posible que el código recibido por el cliente haya sido creado por el intermediario y no por la aplicación. Los registros correlacionados por ID de solicitud son esenciales para localizar al remitente.
4.15 , , puerta de enlace y
El representa a los clientes. Se configura en el sistema o aplicación y recibe un de destino. Las empresas lo utilizan para control, filtrado, inspección y autenticación de salida. Para , el cliente puede utilizar el método CONNECT para solicitar un hacia el destino; en este caso, el conoce el host y el puerto, pero no necesariamente interpreta el cifrado. En la inspección empresarial, el finaliza y emite un certificado aceptado por la instalada en el cliente.
El representa servidores. El cliente cree que se está conectando al servicio final, pero la conexión finaliza en el , que elige un flujo ascendente. NGINX, HAProxy, Envoy, Application , Front Door y pueden actuar así. El controla los certificados, los hosts virtuales, el enrutamiento de rutas, la compresión, el almacenamiento en caché y la protección, siempre que la capa de aplicación esté visible.
El término puerta de enlace en describe un intermediario que actúa como fuente de la conexión entrante y traduce o se conecta a otro servicio. Una amplía esta idea con políticas de seguridad, cuotas, transformación y ciclo de vida de . Puede recibir / y llamar a , JMS u otro , ocultando la implementación. El término no debe confundirse con puerta de enlace predeterminada de enrutamiento .
Un reenvía bytes sin interpretar el protocolo después de su creación. El paso de en un equilibrador L4 se acerca a este modelo: el protocolo de enlace se produce con el . La ventaja es preservar la autenticación y el cifrado de un extremo a otro; la limitación es que el intermediario no puede aplicar reglas basadas en el método, la ruta, el contenido o .
Figura 7 - Los intermediarios difieren según la entidad representada y el nivel de interpretación.
4.16 Capa 4, Capa 7 y terminación
Un equilibrador o de Capa 4 decide en función de la información de transporte, como la dirección, el puerto y el estado del flujo. Puede reenviar o sin comprender la aplicación. Este enfoque admite distintos protocolos y reduce el acoplamiento a . Cuando permanece intacto, el certificado y la negociación pertenecen al y el intermediario no puede inspeccionar rutas ni encabezados.
En la capa 7, el componente comprende el protocolo de la aplicación. En , puedes enrutar por Host, , método, o encabezado; aplicar ; reescribir mensajes; y generar respuestas. Para ello, en normalmente termina . La conexión puede ser , o , formando una segunda sesión con parámetros independientes y de confianza.
La descarga de elimina el cifrado interno y simplifica el , pero deja datos de texto sin cifrar en la red después del . El nuevo cifrado mantiene en ambas secciones, pero no es de extremo a extremo: el tiene acceso al contenido y presenta su propia identidad al . Los certificados, , versiones y conjuntos de cifrado deben configurarse en ambos lados.
Cuando el cliente usa con el , el certificado del cliente no se presenta automáticamente al . El puede autenticar al cliente y propagar atributos a través de encabezados o , siempre que el confíe exclusivamente en este y la conexión esté segura. 9440 documenta encabezados estandarizados para transportar información de certificados en escenarios de terminados en , pero el modelo de confianza debe protegerse explícitamente.
Figura 8: Cada modo define diferentes límites de confianza. Figura 9 - La Capa 4 distribuye los flujos; La capa 7 puede tomar decisiones a través de .
4.17 Host, , y encabezados reenviados
El alojamiento virtual permite que múltiples servicios compartan una dirección. Antes de enviar a través de , el cliente puede incluir en ClientHello para indicar el nombre de host deseado, lo que permite que el terminador seleccione el certificado y la configuración. Después del protocolo de enlace, contiene la autoridad de la solicitud, normalmente reflejada en el Host en /1.1 o en el pseudoencabezado :authority en /2.
y Host pertenecen a capas diferentes y pueden divergir debido a un error o un ataque. El equilibrador puede seleccionar el certificado por y la ruta por Host. Las configuraciones deben validar las combinaciones permitidas para evitar un reenvío inadecuado. Cuando el llama al con un nombre de host diferente, debe decidir si conserva el host original o usa el nombre ascendente. Esta elección afecta a los hosts virtuales, las redirecciones, las y la validación de certificados.
Los inversos insertan metadatos como X-Forwarded-For, X-Forwarded-Proto y X-Forwarded-Host. 7239 define el encabezado como una forma estandarizada de transportar información perdida en el . Sin embargo, cualquier cliente puede enviar encabezados con estos nombres. El borde confiable debe eliminar o reconstruir los valores recibidos y el debe confiar solo en los saltos conocidos.
La original también se puede conservar en la capa 4 mediante mecanismos como el protocolo , cuando sea compatible. Esto cambia el protocolo esperado en los primeros bytes de la conexión y debe habilitarse de manera consistente en ambos lados. El envío del protocolo a un oyente que espera o genera fallas inmediatas y mensajes de protocolo no válidos.
Ejemplo didáctico de metadatos agregados por un borde confiable
Defina la lista de confiables y calcule el cliente a partir de la cadena conocida. De lo contrario, el consumidor puede introducir una arbitraria e influir en la auditoría, la limitación de tarifas o la autorización.
4.18 Fundamentos del balanceo de carga
El balanceo de carga distribuye el trabajo entre múltiples objetivos para utilizar la capacidad, tolerar fallas y permitir la escala. No acelera mágicamente una sola operación: una solicitud específica todavía es procesada por una instancia. La ganancia surge de la ejecución simultánea y la eliminación de puntos finales que no pueden atender nuevas solicitudes.
El conjunto de destinos se denomina grupo, clúster ascendente o conjunto de , según el producto. Antes de aplicar un algoritmo, el equilibrador determina qué puntos finales son elegibles por configuración, prioridad, ubicación y estado. El algoritmo selecciona entre estos candidatos. Por lo tanto, una distribución inesperada podría deberse no al round robin, sino a que la mitad del grupo esté marcado como no saludable.
El equilibrio puede ocurrir por conexión o por solicitud. En L4, generalmente se toma una decisión cuando se crea el flujo y permanece hasta su terminación. En /1.1, el puede reutilizar conexiones de y seleccionar por solicitud. En /2, varias solicitudes se multiplexan en unas pocas conexiones, lo que puede cambiar la relación entre la cantidad de conexiones y la carga real.
El alcance puede ser local o global. Un equilibrador regional distribuye entre instancias cercanas. Un sistema global selecciona la región mediante , anycast o de borde. Las arquitecturas robustas suelen combinar las dos capas: una decisión global elige la región y un equilibrador local elige la instancia.
4.19 Algoritmos de selección de
El round robin distribuye selecciones en secuencia y funciona bien cuando los servidores tienen capacidades similares y el costo de las solicitudes es relativamente homogéneo. El round robin ponderado asigna diferentes proporciones, lo que permite que una instancia más grande reciba más tráfico o que se introduzca una nueva versión gradualmente. Los pesos no garantizan porcentajes exactos en ventanas pequeñas.
elige el destino con activas. Es útil cuando las conexiones tienen duraciones variables, pero es posible que el recuento no represente el trabajo real en /2, o cuando una conexión contiene muchas operaciones. La menor solicitud y el menor tiempo de respuesta buscan aproximarse a la carga o latencia observada, pero deben evitar oscilaciones y decisiones basadas en métricas ruidosas.
selecciona el destino en función de una clave, como , , encabezado o identificador. Proporciona afinidad determinista mientras el conjunto permanece estable. Cuando los puntos finales entran o salen, un simple puede reasignar la mayoría de las claves. El consistente y algoritmos como ring o Maglev buscan reducir la reasignación, siendo útiles para cachés y datos localizados.
El poder de dos opciones selecciona dos candidatos aleatorios y elige el menos cargado, obteniendo una buena distribución con menos costo que examinar todo el grupo. Los productos modernos también combinan prioridad, localidad, pesos dinámicos, detección de valores atípicos y interrupción de circuitos. La elección debe validarse con el patrón de tráfico real, no sólo con una definición abstracta.
Figura 10: Diferentes algoritmos optimizan diferentes patrones de carga.
Tabla 7 - Criterios para elegir el algoritmo.
Algoritmo
Señal utilizada
Indicado cuando
Precaución
Todos contra todos
secuencia
Instancias y solicitudes similares
Ignorar la carga actual
RR ponderado
Peso estático/dinámico
Diferentes capacidades
Pesos incorrectos carga concentrada
Menos conexiones
Conexiones activas
Sesiones de duración variable
HTTP/2 distorsiona la métrica
Menor tiempo de respuesta
Latencia y actividad
Rendimiento variable
puede oscilar
picadillo
Solicitar clave
Afinidad y caché local
Reasignación y puntos de acceso
hash consistente
Anillo/mesa estable
Reducir la rotación por afinidad
Más complejidad
4.20 Comprobaciones de estado, preparación, drenaje y conmutación por error
Las comprobaciones de estado determinan si un final debe recibir tráfico. Una verificación confirma que el puerto acepta la conexión, pero no prueba que la aplicación pueda consultar la base de datos, validar o responder a una operación crítica. Una verificación puede verificar una ruta, un estado y un contenido. El final de estado debe reflejar la preparación para el tráfico que se enviará, sin causar una carga excesiva ni depender de componentes irrelevantes.
Liveness y readiness responden a diferentes preguntas. Liveness indica si el proceso debe reiniciarse. Readiness indica si está listo para recibir nuevas solicitudes. Mezclar los dos puede crear bucles: una dependencia temporalmente no disponible genera liveness falso, el orquestador reinicia todas las instancias y la recuperación se vuelve aún más difícil.
Los umbrales evitan la eliminación en caso de un solo fallo y el retorno prematuro después de un único éxito. El intervalo, el tiempo de espera, la cantidad de fallas y la cantidad de éxitos definen la velocidad de detección y recuperación. Los controles muy agresivos pueden generar falsos negativos durante los picos; Las comprobaciones lentas mantienen las instancias rotas en el grupo por más tiempo.
El drenaje elimina el final de las nuevas selecciones y al mismo tiempo permite que finalicen las conexiones existentes. El inicio lento aumenta el peso gradualmente después del inicio o la recuperación, evitando enviar la carga completa a cachés frías y runtimes que aún se están calentando. En las implementaciones, se deben coordinar readiness, pre-stop, el drenaje de conexiones y el tiempo de espera máximo de la aplicación para evitar reinicios.
Figura 11: Un final recorre los estados que influyen en la elegibilidad y el peso.
Comprobación de estado de
Un análisis de puertos puede marcar la puerta de enlace como en buen estado incluso cuando el repositorio de configuración, el o los críticos no están disponibles. Diseñe comprobaciones por capa y también supervise la experiencia de un extremo a otro.
4.21 Agrupación de afinidad, estado y conexión
La dirige las solicitudes relacionadas al mismo , generalmente mediante , o . Puede ser necesario para sistemas heredados con sesiones en memoria, pero reduce la libertad de distribución y complica la conmutación por error. Idealmente, las mantienen el estado de la sesión en mecanismos o compartidos, lo que permite que cualquier instancia procese la llamada.
La afinidad de es frágil detrás de y , ya que muchos consumidores pueden aparecer con el mismo origen. Los usuarios de dispositivos móviles pueden cambiar las y puede usar múltiples direcciones temporales. La afinidad basada en ofrece una clave más específica, pero debe considerar el dominio, la seguridad, el mismo sitio y el comportamiento cuando el abandona el grupo.
La agrupación de conexiones reutiliza las conexiones del al y reduce los protocolos de enlace / , la latencia y el consumo de puertos . Sin embargo, los grupos muy pequeños pueden concentrar el tráfico y las conexiones persistentes pueden mantener una dirección resuelta antes de un cambio de . La política de actualización de , duración de la conexión y tiempo de espera de inactividad debe ser compatible con la conmutación por error y la rotación de puntos finales.
/2 multiplexa múltiples flujos en una conexión. Si el mantiene una única conexión /2 por , las métricas de conexión ya no representan la cantidad de solicitudes. Es necesario respetar el algoritmo, los límites de flujo y la creación de múltiples conexiones. La misma preocupación se aplica a , y el sondeo largo, que tienen diferentes duraciones y patrones.
Tabla 8 - El estado y la persistencia cambian la distribución.
Mecanismo
Beneficio
efecto secundario
Afinidad con las cookies
Sesión estable
Dependencia de backend y conmutación por error
hash de IP
Sin galleta
NAT concentra clientes
Agrupación de conexiones
Menos apretón de manos y SNAT
Viejas conexiones y concentración.
Multiplexación HTTP/2
Alta eficiencia
La conexión no representa carga.
Drenaje
Implemente sin interrupciones abruptas
Necesita tiempo de espera coordinado
4.22 Arquitectura multicapa
Una arquitectura puede contener / , o Front Door, , equilibrador de carga regional, , controlador de ingreso, malla de servicios y aplicación. Cada capa puede terminar , generar encabezados, realizar reintentos y aplicar tiempo de espera. El diseño necesita definir una matriz de responsabilidades: quién autentica al cliente, quién aplica , quién selecciona la región, quién selecciona la instancia, quién preserva el host y quién genera el ID de la solicitud.
Los reintentos multicapa multiplican el tráfico. Si el cliente, Front Door, y la red de servicios lo intentan tres veces, una sola operación puede producir docenas de llamadas al . En operaciones no idempotentes, esto también crea un riesgo funcional. El presupuesto de tiempo de espera debe disminuir a lo largo de la cadena para que las capas externas todavía tengan tiempo de procesar la falla y responder.
La observabilidad debe registrar marcas de tiempo, dirección, nombre de host, protocolo, estado de origen, seleccionado, duración de la conexión y duración de la respuesta. Se debe crear un identificador de correlación en el borde o conservarlo de forma controlada. Los registros deben distinguir el estado del y el estado ascendente, además del tiempo de espera de conexión, el error de , el reinicio y el tiempo de espera de respuesta.
La alta disponibilidad requiere eliminar puntos únicos de falla en la propia capa de puerta de enlace. Se requieren varias instancias detrás del equilibrador de carga, una configuración coherente y comprobaciones de estado. Los componentes con estado, las cachés distribuidas y los bancos de configuración requieren su propio diseño; Duplicar solo el oyente no garantiza que la plataforma continuará funcionando durante una falla de dependencia.
Figura 12: Cada salto toma decisiones y puede cambiar la identidad observada.
Tabla 9 - Ejemplo de división de responsabilidades.
capa
Responsabilidad recomendada
Evite la duplicación de
DNS/GSLB
Elección global y conmutación por error de endpoints
Reglas de aplicación
Borde/WAF
Protección pública, TLS, enrutamiento amplio
Autorización comercial
Puerta de enlace API
Autenticación, cuotas, transformación, gobernanza
Equilibrio global improvisado
LB/Ingreso
Distribución local y salud.
Políticas de identidad duplicadas
Malla de servicio
Resiliencia de servicio a servicio y mTLS interno
Reintentos sin presupuesto
Solicitud
Regla de negocio y estado funcional.
Dependencia de encabezados no validados
4.23 Aplicación en Axway y Azure
Puerta de enlace de Axway
En una implementación de Axway de alta disponibilidad, varias instancias de se ubican detrás de un equilibrador que realiza comprobaciones de estado y distribuye la carga. El equilibrador debe preservar o reconstruir correctamente la identidad del host, el protocolo y la fuente según lo diseñado. La afinidad sólo debe utilizarse cuando un recurso realmente depende de ella; las políticas y el estado compartido deben evaluarse por separado.
En el enrutamiento saliente, filtros como Conectar a hacen que la puerta de enlace actúe como un final para el cliente y llame al destino configurado, ocultando la jerarquía de implementación. La configuración del host remoto controla cómo se conecta la puerta de enlace a destinos específicos, incluidas conexiones, tiempos de espera y parámetros relacionados. La resolución de y la agrupación de conexiones pueden hacer que los cambios en el no se noten inmediatamente.
Cuando la salida requiere un corporativo, la configuración del define un intermediario adicional. El diagnóstico necesita separar la conexión de puerta de enlace- y de -destino. En topologías con un equilibrador de carga al frente y un a la salida, la puerta de enlace se encuentra entre dos formas de intermediación, cada una con su propio , registros y tiempos de espera.
Las operaciones de mantenimiento deben coordinar el drenaje del equilibrador de carga y el apagado controlado de la instancia para evitar la interrupción de las conexiones activas. La documentación de Axway también le permite configurar direcciones y opciones de balanceo de carga en integraciones específicas de Manager; estos parámetros deben validarse según la versión en uso.
Aplicación práctica en Axway
Al investigar 502 o tiempo de espera de conexión, registre: nombre de host configurado en el filtro, respuesta vista por el proceso, dirección seleccionada, configuración de host remoto aplicada, saliente, grupo de conexiones y origen observada por el .
Servicios de Azure y gestión de
Azure ofrece servicios de distribución para diferentes propósitos. Traffic Manager toma decisiones a través de y el cliente se conecta directamente al final devuelto. Azure Front Door es un global de capa 7, con aceleración, , enrutamiento y . Azure opera principalmente en la capa 4. Application actúa como un regional de capa 7 para / , con host/ruta y enrutamiento , así como capacidades L4 en escenarios admitidos por la plataforma.
Azure Management es una plataforma de administración de cuya puerta de enlace aplica políticas, autenticación, transformación y observabilidad. No reemplaza automáticamente un o un servicio de distribución global. Un diseño común coloca Front Door o Application delante de , pero los sondeos de estado deben usar el nombre de host correcto, porque es posible que los puntos finales virtuales no respondan a los sondeos mediante y host predeterminados.
En modo interno, los puntos finales requieren accesible dentro de la red virtual. Application frente a necesita sondas personalizadas y una configuración de compatible con el nombre de host y el certificado. En la ruta de salida, necesita resolver privados y tener conectividad a la red correspondiente. Configurar solo la exposición entrante no resuelve el tramo final.
La elección entre Traffic Manager y Front Door ilustra la diferencia conceptual: Traffic Manager responde al y no ve el tráfico de las aplicaciones; Front Door permanece en la ruta como . Esto cambia el origen observado, , , registros, conmutación por error y capacidad de enrutamiento.
Figura 13 - Los servicios de Azure se diferencian por alcance, capa y permanencia en la ruta.
Tabla 10 - Mapeo conceptual de los servicios de Azure.
Servicio
Alcance/nivel
¿Permanecer en el camino?
Uso principal
Administrador de tráfico
Global por DNS
No
Elija el punto final por política y estado
puerta principal
L7 mundial
si
Proxy inverso, WAF, TLS y aceleración
Equilibrador de carga
Regional L4
si
Distribuir flujos TCP/UDP
Puerta de enlace de aplicaciones
Regional L7
si
Enrutamiento de host/ruta, WAF y TLS
Gestión de API
Puerta de enlace API
si
Seguridad, políticas y gobernanza de API
4.24 Solución de problemas sistemática
El diagnóstico debe seguir el orden de llamada real. Comience en el entorno de consumidor o de ejecución que falla, no en una estación de trabajo diferente. Registre el nombre consultado, el servidor utilizado, la respuesta A/ / , y caché. Luego identifique la dirección de destino, la ruta, , terminación , host y seleccionado.
Compare una llamada exitosa y una llamada fallida. Las diferencias en el resolvedor, la familia de , la dirección de retorno, la origen o la instancia del grupo a menudo revelan intermitencia. Para 502, determine si hubo una falla de , un error de conexión, un error de , un reinicio o una respuesta no válida. Para 503, verifique si al grupo le faltan puntos finales en buen estado o si la política en sí causó la indisponibilidad. Para 504, compare los tiempos de espera en todas las capas.
Las herramientas de captura y los registros deben usarse de manera autorizada y con filtros mínimos. excavar o Resolve-DnsName mira ; curl -v muestra resolución, conexión, y ; openssl s_client ayuda a analizar y la cadena; ss/netstat muestra ; tcpdump/Wireshark confirma direcciones y restablece; Las métricas del balanceador muestran el estado y la selección de . Ninguna herramienta explica toda la cadena.
El objetivo no es sólo restablecer el servicio, sino producir una causa verificable. Documente la configuración que causó la falla, la evidencia, el mecanismo técnico, la solución permanente y el monitoreo que detectará la recurrencia. Borrar la memoria caché, reiniciar la puerta de enlace o aumentar el tiempo de espera puede enmascarar el problema sin corregir la arquitectura.
Comandos de diagnóstico: úselos solo en sistemas y objetivos autorizados
# DNS
dig api.empresa.com A +noall +answer
dig api.empresa.com AAAA +noall +answer
dig api.empresa.com +tcp
dig api.empresa.com +dnssec
# Red y sockets
ip route get 198.51.100.25
ss -tan state established
ss -tan state time-wait
Tabla 11 - Síntomas y líneas iniciales de investigación.
Síntoma
Hipótesis prioritarias
evidencia
NXDOMAIN después de crear el registro
Caché negativo o zona incorrecta
SOA, TTL negativo, consulta autoritativa
Funciona por IP, falla por nombre
DNS, SNI, Host o certificado
cavar, rizar --resolve, s_client
Algunos clientes utilizan puntos finales antiguos
TTL/caché/conexión persistente
TTL restante y grupo de conexiones
502 intermitente
DNS múltiple, TLS ascendente, SNAT, reinicio
Backend elegido y error detallado
503 en equilibrador
Toda la piscina insalubre o vacía
Estado de salud y registros de sonda
504 después del tiempo fijo
Tiempo de espera en una capa
Duración del estado y emisor
El backend ve la IP del proxy
Proxy inverso o SNAT
Encabezados y captura confiables
Distribución desigual
Keep-alive, HTTP/2, afinidad, pesos
Solicitudes y conexiones de backend
Salud verde, la API falla
Sonda poco profunda
Dependencias de prueba y camino real.
Sólo fallan las respuestas DNS grandes
TCP/53, EDNS o fragmentación
Bandera TC, excavar +tcp, capturar
Árbol de decisión ante un fallo de
¿El nombre se resuelve en el mismo tiempo de ejecución que ejecuta la llamada? Registrar servidor , respuesta, y alias.
¿La dirección resuelta es el final esperado para este entorno y familia de ?
¿Se crea la conexión ? En caso contrario, analice ruta, firewall, , y capacidad de puerto.
¿Finaliza el protocolo de enlace ? Valide , certificado, , nombre de host y en el tramo correcto.
¿El recibe ? Identifique el componente que generó el estado y el ID de solicitud.
¿El grupo tiene puntos finales saludables y la sonda representa readiness real?
¿Qué se eligió y qué host/ruta/encabezado se envió?
¿El respondió, se reinició o se agotó el tiempo de espera?
¿La respuesta llegó a través del mismo estado y a través de las mismas capas?
¿La solución elimina la causa o simplemente fuerza una nueva caché/conexión?
4.25 Estudios de caso
Caso 1: cambio de sin reducir
Un equipo cambia el registro .empresa.com del antiguo balanceador al nuevo durante un cambio. El anterior era de 3600 segundos. Las pruebas realizadas directamente en el sistema autorizado muestran la nueva dirección, pero algunos consumidores permanecen en el antiguo terminal durante casi una hora. Reiniciar una estación parece resolver el problema, mientras que las aplicaciones en contenedores mantienen conexiones antiguas.
La causa combina el almacenamiento en caché recursivo válido y la agrupación de conexiones. El plan correcto sería reducir el por adelantado, esperar a que caduque, mantener ambos puntos finales compatibles durante la transición y observar el tráfico por dirección. El evento demuestra que una actualización autorizada no equivale a una adopción inmediata por parte de todos los clientes.
Caso 2: interno marcado como incorrecto por Application
Una puerta de enlace de aplicaciones utiliza la privada de Management como y la sonda predeterminada envía un host incompatible. responde solo a los nombres de host configurados y la sonda considera que el no está disponible. Los usuarios reciben 502 o 503 aunque esté operativo cuando se accede a ellos con el nombre de host correcto.
La solución es crear una sonda personalizada con el host y la ruta adecuados, configurar los ajustes del y garantizar la resolución/certificado. El caso muestra que la verificación de estado de la capa 7 debe reproducir la autoridad esperada y no solo alcanzar la .
Caso 3: agotamiento de causado por conexiones cortas
Una puerta de enlace llama a un externo y abre una nueva conexión para casi cada solicitud. Durante el pico, las nuevas conexiones comienzan a fallar de forma intermitente. El no muestra saturación y los reintentos aumentan aún más el volumen. Las métricas revelan una gran cantidad de TIME_WAIT y consumo de puerto en la saliente.
La solución implica agrupación de conexiones, mantenimiento de conexión, dimensionamiento de , ajuste de tiempos de espera y monitoreo de puertos. Aumentar el tiempo de espera de no crea puertos y puede prolongar los estados. El caso relaciona conceptos de los capítulos de y con el comportamiento de .
Caso 4: X- -for falsificado
Una aplica una limitación de velocidad por el primer valor de X-Forwarded-For, pero el balanceador de carga simplemente agrega la observada al final del encabezado recibido. Un consumidor envía X-Forwarded-For con direcciones arbitrarias y cambia el primer valor para evitar el límite y la auditoría de contaminación.
El borde debe eliminar los encabezados que no sean de confianza y crear la cadena a partir del zócalo observado. El debe configurar servidores confiables y seleccionar la posición correcta. Una identidad sólida debe provenir de la autenticación, no de un encabezado controlable por el cliente.
Caso 5: Distribución desigual con /2
El equilibrador utiliza la menor cantidad de conexiones entre tres puertas de enlace. Un cliente abre algunas conexiones /2 y envía miles de transmisiones a través de la misma conexión. El contador de conexiones no refleja la carga por solicitud y una instancia recibe una parte desproporcionada del trabajo.
La investigación compara flujos y solicitudes por , no solo por . La solución puede implicar balanceo por solicitud en el L7, múltiples conexiones, límites de transmisión o un algoritmo basado en solicitudes/latencia. El algoritmo debe ser compatible con el protocolo.
Aplicación en el mundo bancario
En las integraciones financieras, , origen de red, e identificación de institución son controles diferentes. La lista de permitidas reduce el área de superficie, autentica la entidad en el canal y / autoriza las operaciones. Ninguno de ellos debe utilizarse como sustituto automático de los demás.
Laboratorios prácticos
Los laboratorios deberán realizarse en su entorno propio o autorizado. Utilice dominios de documentación, servicios locales o recursos de laboratorio. No escanee ni intente eludir los controles corporativos. Registre las predicciones antes de ejecutar comandos y compárelas con los resultados.
Para cada práctica de laboratorio, anote la hora, la resolución, la respuesta , el , la dirección de destino, el protocolo, el terminador , el host, el estado, el servidor elegido y la duración. Esta disciplina transforma comandos aislados en evidencia arquitectónica.
Consulta el A, , , NS y SOA de un dominio bajo tu control. Identificar autoridad y .
Ejecutar una resolución normal y luego una consulta directa con la autoridad. Compara banderas AA, RD y RA.
Utilice dig + y compárelo con . Anote el tamaño, el momento y la presencia de EDNS.
Cree un registro con un bajo en el laboratorio, cambie el valor y realice un seguimiento del restante en la caché.
Pruebe una respuesta de NXDOMAIN y observe cuánto tiempo permanece en caché.
Configure dos nombres locales que apunten al mismo y ruta por Host.
En Docker o en la red local, configure NGINX/HAProxy con dos y observe el round robin y las conexiones mínimas.
Deshabilite un y verifique cuántas comprobaciones se necesitan para eliminarlo del grupo.
Habilite y compare la cantidad de apretones de manos y con nuevas conexiones por solicitud.
Simule un cambio de mientras mantiene activo el final antiguo y documente la ventana de coexistencia.
Agregue un encabezado X-Forwarded-For en el cliente y confirme que Lab Edge lo elimine o lo conserve.
Diseñar una arquitectura con global, , y dos , indicando quién completa y genera el ID de solicitud.
Resumen del capítulo
es una base distribuida y jerárquica de RRsets, no solo un directorio de .
Las zonas y los dominios no son idénticos; las delegaciones distribuyen la autoridad entre los registros NS y la pegan cuando es necesario.
El stub resolver utiliza un resolvedor recursivo, que puede consultar la raíz, el TLD y el autoritativo o reenviarlo a otro resolvedor.
controla el caché; Los cambios no invalidan instantáneamente las entradas ya almacenadas.
NXDOMAIN y la falta de tipos también se pueden almacenar en caché.
necesita funcionar sobre y ; EDNS amplía las capacidades y las respuestas grandes pueden requerir un respaldo.
DoT/DoH protegen el transporte; autentica datos; TSIG autentica transacciones específicas.
El privado y de horizonte dividido requiere visibilidad de , reenvío y control de bucle.
El equilibrio de toma una decisión antes de la conexión y está limitado por y el comportamiento del resolvedor.
traduce direcciones y puertos con estado; No reemplaza el firewall ni la autenticación.
cambia el origen observado y puede sufrir un agotamiento del puerto.
El finaliza una conexión y crea otra; un solo reenvía bytes una vez establecido.
L4 decide por el flujo; L7 puede interpretar , terminar , enrutar por host/ruta y aplicar .
Forwarded y X-Forwarded-* solo son confiables cuando los reconstruyen servidores conocidos.
El algoritmo selecciona entre puntos finales elegibles; Los controles de salud definen este conjunto.
Round Robin, conexiones mínimas y cumplen con diferentes patrones de carga.
La preparación, el drenaje y el inicio lento son necesarios para un despliegue y una recuperación sin avalanchas.
La agrupación de conexiones reduce los protocolos de enlace y , pero influye en el , la distribución y la conmutación por error.
En Azure, Traffic Manager, Front Door, , Application y tienen diferentes roles.
En Axway, el balanceador de carga entrante, los filtros de enrutamiento, los hosts remotos y el saliente deben analizarse por tramo.
Checklist de arquitectura
¿Qué utiliza cada consumidor y qué tiene autoridad?
¿Qué resolvedores utilizan los clientes, puertas de enlace y ?
¿Existen respuestas públicas y privadas para el mismo nombre?
¿Qué positivos y negativos se han establecido?
¿ /53 y /53 funcionan en todas las rutas requeridas?
¿Se valida y monitorea cuando se adopta?
¿Qué componente realiza y qué puede observar el ?
¿La capacidad del puerto admite picos y tiempos de espera?
¿Dónde termina cada conexión / ?
¿Qué nombre de host se utiliza en , host y validación de certificados?
¿Qué encabezados se eliminan y reconstruyen en el borde?
¿Qué capa elige región y cuál elige instancia?
¿La verificación de estado prueba readiness real y utiliza el host/ruta correctos?
¿Hay umbrales, drenaje y comienzo lento?
¿El algoritmo es adecuado para /2, , y conexiones largas?
¿Es realmente necesaria la afinidad? ¿Dónde está el Estado?
¿Los grupos de conexiones respetan los cambios de y la conmutación por error?
¿Los reintentos y los tiempos de espera tienen un presupuesto coordinado?
¿Los registros distinguen el estado del y el estado ascendente?
¿Hay métricas e ID de solicitud de un extremo a otro por ?
Ejercicios de repaso
Diferenciar entre dominio, , y .
Explique por qué un puede terminar con un y el riesgo de omitirlo en un archivo de .
Describa el flujo entre resolución de stub resolver, recursivo, raíz, TLD y autoritativo.
Diferenciar consulta recursiva e iterativa.
¿Cuál es la diferencia entre NXDOMAIN y NODATA?
Explicar la función de las banderas AA, RD, RA y TC.
Compare A, , , NS, SOA, PTR, SRV y CAA.
¿Por qué varios registros A no garantizan un equilibrio uniforme?
Explique cómo y la agrupación de conexiones pueden mantener el uso de un final antiguo.
¿Por qué publicar sólo /53 puede romper el ?
¿Qué problema resuelve y qué riesgo surge con cargas útiles muy grandes?
Compare , DoT, DoH y TSIG.
¿Cómo ayuda el horizonte dividido y qué riesgos operativos crea?
Diferenciar entre Básica, , y .
¿Por qué no debería tratarse como un mecanismo de autenticación?
Explique el agotamiento de y la relación con la agrupación de conexiones.
Diferenciar entre , , puerta de enlace y .
Compare el paso a través, la descarga y el nuevo cifrado de .
¿Por qué termina en el y no automáticamente hasta el ?
Diferenciar entre y Host y explicar cómo cada uno participa en el enrutamiento.
¿Cómo se debe establecer la confianza en X-Forwarded-For?
Compare el balanceo L4, L7 y .
¿Cuándo son apropiados el round robin, la menor cantidad de conexiones y el consistente?
Diferenciar vivacidad, preparación y externo.
Explique cómo /2 puede hacer que las conexiones mínimas sean inapropiadas.
¿Cuál es la diferencia entre Azure Traffic Manager y Azure Front Door?
¿Por qué podría fallar la sonda predeterminada de Application contra interno?
¿Qué elementos se deben recopilar para investigar un 502 en ?
Preguntas de escenario
Una cambia de 203.0.113.10 a 203.0.113.20, pero el 15% de los clientes permanecen en la dirección anterior. Proponer hipótesis y un plan de evidencia.
El privado devuelve 10.20.5.10 para las máquinas virtuales, pero resuelve la dirección pública. Dibuja la ruta de resolución y los puntos a comprobar.
Un permite solo una saliente, pero la puerta de enlace utiliza tres fuentes. Explique por qué la falla parece intermitente y proponga una solución.
Un equilibrador de carga considera que el está en buen estado a través de , pero la devuelve 500 por banco no disponible. Diseñar controles adecuados.
Un cliente utiliza hasta y el necesita conocer la identidad del certificado. Definir un modelo de propagación confiable.
Una aplicación con estado requiere afinidad de , pero los consumidores buscan CGNAT. Analizar el riesgo y proponer una alternativa.
Una arquitectura tiene reintentos en el cliente, Front Door, y la malla de servicios. Calcula el potencial de multiplicación y propone un presupuesto.
Después de habilitar /2 entre el y la puerta de enlace, la distribución por mínimo de conexiones se vuelve desigual. Explicar el mecanismo y posibles ajustes.
Glosario técnico
Tabla 12 - Glosario de capítulos.
Término
Definición
servidor autoritativo
Servidor que responde con autoridad sobre una zona.
CNOMBRE
Registro que define un nombre como alias de otro nombre canónico.
Delegación
Transferir autoridad de una parte del árbol DNS a otra zona.
ADNT
Traducción de la dirección o puerto de destino.
DNSSEC
Extensiones que proporcionan autenticación de origen e integridad para los datos DNS.
Departamento de Salud
Transporte de mensajes DNS a través de HTTPS.
punto
Transporte de mensajes DNS sobre TLS.
EDNS(0)
Mecanismo extensible que anuncia la carga útil y las capacidades de DNS UDP.
proxy directo
Intermediario que representa a los clientes en destino.
reenviado
Encabezado HTTP estandarizado para proxy de metadatos.
FQDN
Nombre de dominio completo.
Registro de pegamento
Dirección proporcionada por el padre para llegar al servidor de nombres dentro de la zona delegada.
GSLB
Distribución global del tráfico, a menudo basada en DNS y estado.
NAT de horquilla
Traducción que permite a los clientes internos acceder a la dirección externa del servicio interno.
control de salud
Prueba utilizada para decidir si un criterio de valoración debe seguir siendo elegible.
Menos conexiones
Algoritmo que elige el endpoint con menos conexiones activas.
NAPT/PAT
Traducción que incluye direcciones y puertos de transporte.
almacenamiento en caché negativo
Caché sin nombre ni tipo DNS.
resolución recursiva
Servidor que obtiene la respuesta final en nombre del cliente y mantiene el caché.
proxy inverso
Intermediario que representa servidores y selecciona upstream.
RRset
Conjunto de registros con el mismo nombre, clase y tipo.
Afinidad de sesión
Mecanismo que intenta mantener las solicitudes relacionadas en el mismo backend.
SNI
Indicación de nombre de host enviada durante el protocolo de enlace TLS.
SNAT
Traducción de la dirección de origen o puerto.
DNS de horizonte dividido
Diferentes respuestas para el mismo nombre según el entorno de resolución.
resolución de trozo
Componente local que envía consultas a un resolvedor recursivo.
TTL
Tiempo durante el cual los datos DNS pueden permanecer en caché.
Túnel
Intermediario que reenvía bytes después de establecer un túnel.
aguas arriba
Destino al que el proxy o puerta de enlace reenvía el tráfico.
Zona
Porción administrada del espacio de nombres DNS.
Referencias oficiales y lecturas recomendadas
Las especificaciones siguientes son las fuentes principales de los conceptos presentados. Los antiguos siguen siendo fundamentales, pero deben leerse junto con las actualizaciones indicadas en la página del Editor . La documentación del producto cambia con el tiempo; Valide la versión y el modo de implementación en uso antes de aplicar una configuración.
La lectura recomendada comienza con 1034 y 1035, continúa con la terminología y el almacenamiento en caché, luego los transportes y . Para intermediarios , lea la arquitectura 9110 y los encabezados reenviados. Luego compare la documentación sobre balanceo de carga y las referencias oficiales de Axway y Azure.
1034 - Domain Names: Concepts and Facilities
1035 - Domain Names: Implementation and Specification
2308 - Negative of Queries
6891 - Extension Mechanisms for ( )
7766 - Transport over
9499 - Terminology
4033 - Security Introduction and Requirements
4034 - Resource Records for
4035 - Protocol Modifications
7858 - over
8484 - Queries over
3022 - Traditional Network Address Translator
4787 - Behavioral Requirements for
5382 - Behavioral Requirements for
9110 - Semantics
7239 - Forwarded Extension
9440 - Client-Cert Field
- Service Name and Port Number Registry
- Technical requirements for authoritative name servers
NGINX -
Envoy - Overview
Axway - Configure High Availability
Axway - Routing Filters
Axway - Remote Host Settings
Axway - Configure Servers
Azure Overview
Azure Application Overview
Azure Traffic Manager Overview
Azure Front Door Overview
Azure Management Virtual Network Concepts
Integrate Management internal VNet with Application
Azure
Próximo capítulo
El Capítulo 5 profundizará en /1.1, /2 y /3: estructura de mensajes, semántica, conexiones persistentes, , compresión de encabezados, e impactos en .
