Resumen

  • RFC 5382 prohíbe que un NAT TCP asigne simultáneamente el mismo par público de dirección y puerto a extremos internos diferentes, porque ambos pueden colisionar al conectarse al mismo extremo externo.
  • Una prueba de compra debe distinguir capacidad de tabla, asignación única, permiso de filtrado, establecimiento TCP y resultado de aplicación. Contar sesiones admitidas no demuestra que cada sesión conserve una identidad enrutable.

El punto ciego del concurso

Las fichas técnicas favorecen los números fáciles de ordenar: sesiones concurrentes, conexiones nuevas por segundo, direcciones públicas necesarias, memoria por entrada. Son medidas útiles. También crean un incentivo para que toda reducción aparente de estado parezca innovación.

El port overloading ofrece una cifra seductora. Dos pares internos diferentes reciben la misma dirección y el mismo puerto externos. Mientras cada uno contacte un servidor distinto, el traductor añade el destino remoto a su clave privada y sabe cómo devolver los paquetes. En el banco de pruebas, con tráfico distribuido entre muchos destinos, el producto puede soportar más sesiones por puerto.

Después llega el tráfico real. Dos abonados abren una conexión hacia la misma plataforma, en la misma dirección y puerto de servicio. Ya no queda un campo exterior que separe sus flujos: origen público igual, destino igual, protocolo igual. El servidor ve la misma identidad de transporte y el traductor debe resolver dos reclamaciones incompatibles.

RFC 5382 no trata este resultado como una pequeña penalización. Su sección 7.1 explica que los extremos internos que comparten un mapeo no pueden crear conexiones simultáneas con un extremo externo común. REQ-7 ordena que un NAT no use port overloading para TCP. La palabra normativa importa: la densidad no compensa la pérdida de identidad.

La prueba debe hacer converger el tráfico

Un ensayo con miles de destinos puede ocultar el defecto, porque cada destino actúa como un discriminador gratuito. La prueba correcta obliga a converger. Se preparan dos direcciones y puertos internos distintos. El primer cliente conecta con un listener externo y mantiene vivo su mapeo. El segundo conecta con la misma dirección y puerto externos. Las fuentes traducidas deben ser distintas. Si el pool no tiene capacidad, el segundo intento debe fallar de forma explícita.

Ese rechazo no mejora la experiencia del usuario, pero conserva la verdad del sistema. El operador puede medirlo, ampliar el pool, ajustar la asignación o cambiar la arquitectura. Una admisión ambigua es peor: el contador de conexiones aumenta y la avería queda aplazada hasta que un paquete de retorno, una retransmisión o una segunda conversación expone la colisión.

La prueba debe repetirse con presión de puertos, cambios de configuración y conmutación a un nodo de respaldo. No basta con mirar el paquete de salida. Hay que correlacionar la decisión de asignación con los SYN, SYN-ACK y ACK de ambas conexiones, y después con una operación de aplicación. El establecimiento TCP no es todavía la entrega del servicio; pero sin identidad de transporte única, ni siquiera existe una base fiable para evaluar lo demás.

Independencia de destino no significa copropiedad

La misma RFC pide mapeo independiente del extremo para TCP. El nombre puede confundir a un comprador que solo lee una matriz de capacidades. El comportamiento correcto permite que un par interno conserve su mapeo al hablar con varios destinos. El titular sigue siendo el mismo. Lo que cambia es el interlocutor.

Port overloading hace otra cosa: asigna ese mapeo a más de un par interno. Ya no se trata de continuidad para un titular, sino de copropiedad simultánea. Para sostenerla, el traductor convierte al interlocutor en parte oculta de la identidad. Así, una propiedad que debía ser independiente del destino termina dependiendo de él para distinguir a los clientes.

El filtrado también debe quedar fuera de esta equivalencia. Una política puede aceptar retornos de cualquier origen, solo de direcciones contactadas o de direcciones y puertos concretos. Esa elección determina permiso, no singularidad. Un artículo BTW ya analiza la diferencia entre mapeo NAT64 y filtrado. La pregunta de REQ-7 precede a ese control: cuando un paquete está permitido, ¿existe un único extremo interno al que entregarlo?

Una homologación madura registra tres respuestas separadas: quién posee temporalmente el mapeo; qué orígenes pueden usarlo; y qué trabajo terminó en la aplicación. Ninguna respuesta se deduce de otra.

No es el problema de los SYN cruzados

RFC 5382 también preservó la apertura simultánea de TCP. Allí dos pares se llaman a la vez, sus SYN se cruzan y una implementación completa del autómata TCP puede formar una sola conexión. Los NAT que aprendieron solo el orden cliente-servidor podían bloquear ese camino válido. Esa historia ya tiene un análisis BTW propio.

En la colisión de puertos, los dos clientes no intentan necesariamente conectarse entre sí. Ambos llaman a un tercero. El problema no es interpretar un SYN entrante durante SYN-SENT. Es haber proyectado dos fuentes internas sobre la misma fuente pública. Mezclar ambos incidentes conduce a una reparación errónea: ampliar una ventana de estado no crea el puerto distinto que falta.

Los registros también son diferentes. La apertura simultánea requiere las transiciones de estado y el orden de paquetes. La sobrecarga requiere el recibo de asignación completo: par interno, par externo, destino, protocolo, momento, versión del asignador y nodo responsable. Si ese recibo no existe, el operador solo puede observar el síntoma posterior.

La escasez tiene precio, no autoridad ilimitada

La razón económica del CGN es comprensible. Las direcciones IPv4 públicas son escasas, y migrar todos los servicios y accesos a IPv6 no sucede en un solo ciclo presupuestario. RFC 6888 reconoce requisitos comunes para traductores de gran escala. La necesidad de compartir direcciones es real.

Pero compartir una dirección no equivale a compartir simultáneamente una identidad TCP completa. Los puertos permiten multiplexar muchos flujos precisamente porque cada mapeo mantiene una distinción. Si la organización elimina esa distinción para mejorar una ratio comercial, no ha creado más espacio de nombres. Ha trasladado la colisión a una condición que el benchmark quizá no ejercite.

Por eso las métricas de capacidad deben incluir la calidad del rechazo. ¿Qué ocurre cuando no hay un puerto conforme? ¿El cliente recibe un error observable? ¿Se preservan las sesiones existentes? ¿El evento queda registrado con la causa correcta? ¿Puede el equipo de planificación relacionar los rechazos con el tamaño del pool y la demanda?

Un sistema que rechaza de modo controlado está declarando su límite. Un sistema que sobrecarga puede fingir que no tiene límite y hacer que clientes y servidores paguen la diferencia mediante fallos intermitentes. El contrato de capacidad debe valorar la honestidad del límite.

Hairpinning, ICMP y ALG: límites vecinos

REQ-8 exige hairpinning para TCP y la presentación del origen externo en el paquete que vuelve al interior. Dos aplicaciones internas que se conocen por sus mapeos públicos esperan ver esas identidades, aunque el recorrido no abandone el traductor. La exigencia muestra que el par externo participa en la asociación del peer; no es una etiqueta prescindible.

REQ-9 recomienda traducir mensajes ICMP Destination Unreachable y REQ-10 impide que un ICMP termine por sí mismo el mapeo o la conexión. El mensaje aporta evidencia, pero no recibe autoridad para destruir el estado. Es la misma disciplina que conviene aplicar al asignador: una señal de baja utilización no concede autoridad para prestar una identidad todavía activa.

Los ALG introducen más estado. RFC 5382 recomienda desactivarlos por defecto, salvo FTP, y recuerda que cualquier cambio de números de secuencia debe manejar SACK correctamente. Cada mutación exige una cuenta consistente. Si además se comparte el mapeo entre titulares, aparece una ambigüedad anterior: qué espacio de secuencia y qué traducción pertenecen al paquete observado.

Estas exigencias no convierten el artículo en un catálogo. Todas apuntan a una regla operativa: un componente intermedio puede traducir, observar y decidir dentro de un alcance definido; no puede borrar una identidad y dejar que los recibos posteriores aparenten continuidad.

El expediente que sí permite decidir

Por cada asignación TCP deben conservarse el origen interno, el origen externo, el destino remoto, el protocolo, la hora de creación, los refrescos, la causa de eliminación, la versión de política y la identidad del nodo. Durante una conmutación, el epoch del estado indica si el nodo de respaldo recibió la reclamación o la reconstruyó.

Los relojes forman parte del expediente. Una dirección y un puerto públicos solo pueden atribuirse dentro de una ventana temporal. Si un diseño dependiera además del destino remoto para identificar al cliente, esa dependencia tendría que acompañar cualquier consulta de abuso o investigación. REQ-7 evita para TCP la copropiedad simultánea que produce tal fragilidad.

Finalmente, la prueba debe conservar el resultado negativo. La ausencia de duplicados en una captura pequeña no demuestra la política global. Hace falta registrar el escenario de concurrencia, la presión de recursos y la respuesta cuando el segundo mapeo no está disponible. La conformidad es una conducta reproducible, no el texto de una opción.

Fuentes