1. INTRODUCCIÓN Y ENCUADRE

La arquitectura TCP/IP constituye la base técnica de Internet y de la inmensa mayoría de las redes corporativas actuales. No es un único protocolo, sino una familia coordinada de protocolos que permite identificar interfaces, transportar información entre procesos, resolver nombres, descubrir vecinos, notificar errores y elegir caminos entre redes heterogéneas. Su éxito se explica por una combinación de apertura, independencia respecto del medio físico, interoperabilidad y capacidad para crecer desde pequeños entornos académicos hasta una red mundial formada por miles de sistemas autónomos.

En una organización sanitaria, TCP/IP no es solo una materia teórica. Cada consulta a una aplicación clínica, transferencia de imagen médica, llamada a una API, conexión con una base de datos, sesión de administración remota o resolución de un nombre depende de una cadena de decisiones técnicas. El equipo cliente debe conocer su dirección, máscara o longitud de prefijo, puerta de enlace y servidores DNS; la red debe transportar el paquete por varios segmentos; los routers deben seleccionar rutas; el servidor debe escuchar en un puerto; y los controles de seguridad deben permitir únicamente los flujos autorizados. Una incidencia en cualquiera de esos elementos puede manifestarse para el usuario como «la aplicación no funciona», aunque su causa real sea de direccionamiento, resolución o encaminamiento.

El estudio del tema exige distinguir conceptos que en el lenguaje cotidiano suelen mezclarse. Una dirección IP identifica una interfaz o un punto de conexión lógico dentro de un ámbito de encaminamiento; un nombre DNS proporciona una referencia jerárquica y estable que puede traducirse a una o varias direcciones; un puerto ayuda a identificar el proceso o servicio de transporte; una dirección MAC se utiliza normalmente para la entrega en el enlace local; y una ruta expresa cómo alcanzar un prefijo de destino. Cada identificador tiene un alcance diferente y pertenece a una función distinta de la arquitectura.

También debe separarse el plano de datos del plano de control. El plano de datos reenvía paquetes aplicando reglas ya instaladas: consulta la dirección de destino, selecciona la entrada más específica de la tabla y transmite al siguiente salto o interfaz. El plano de control aprende, calcula o configura esas reglas mediante rutas conectadas, rutas estáticas o protocolos dinámicos como RIP, OSPF y BGP. En equipos modernos puede existir además un plano de gestión para configuración, monitorización, inventario, telemetría y auditoría.

La arquitectura Internet se normaliza principalmente mediante documentos del IETF publicados como RFC. No todos los RFC tienen el mismo estado: algunos son estándares de Internet, otros buenas prácticas, documentos informativos o especificaciones experimentales. Por ello, memorizar un número sin conocer su situación puede inducir a error. Por ejemplo, la especificación moderna de TCP se consolida en RFC 9293, que sustituye a la histórica RFC 793; IPv6 se especifica en RFC 8200; y DNS conserva como base las RFC 1034 y 1035, complementadas por muchas actualizaciones posteriores.

2. ARQUITECTURA TCP/IP Y RELACIÓN CON OSI

2.1. Modelo de cuatro capas

La representación más habitual de la arquitectura TCP/IP distingue cuatro niveles: aplicación, transporte, Internet y acceso a la red o enlace. Esta división no debe interpretarse como una copia reducida del modelo OSI. TCP/IP nació a partir de protocolos desplegados y de requisitos de interconexión reales; OSI se formuló como un modelo de referencia más general y detallado. La correspondencia entre ambos es funcional y aproximada.

Algunos manuales utilizan un modelo pedagógico de cinco capas, separando física y enlace. Esa variante facilita la comparación con OSI, pero no convierte a TCP/IP en un estándar de cinco niveles obligatorio. En una prueba debe atenderse al modelo citado. Si el enunciado habla de la pila TCP/IP clásica, la respuesta esperada suele ser cuatro capas; si presenta expresamente el modelo Internet de cinco niveles, la separación inferior es válida dentro de esa convención.

2.2. Principio extremo a extremo

Una idea central de la arquitectura Internet es que la red básica ofrece un servicio de datagramas y que muchas funciones complejas se implementan en los extremos. IP no garantiza entrega, orden ni ausencia de duplicados. Cuando una aplicación necesita fiabilidad, TCP la construye mediante números de secuencia, confirmaciones, retransmisiones y control de flujo. Este reparto evita exigir que todos los routers mantengan el estado completo de cada conversación y permite que aplicaciones diferentes adopten transportes distintos.

El principio extremo a extremo no significa que la red sea pasiva. Los routers decrementan el límite de saltos, seleccionan caminos, pueden aplicar calidad de servicio, listas de control, traducción, túneles y políticas. Significa que ciertas propiedades solo pueden verificarse plenamente en los sistemas finales. Una trama puede llegar correctamente a cada salto y, aun así, la aplicación final recibir datos incompletos; por eso la fiabilidad de enlace no sustituye a la fiabilidad extremo a extremo.

2.3. Interfaces, protocolos y servicios

Cada capa ofrece capacidades a la superior y usa las de la inferior. Una aplicación no construye normalmente una trama Ethernet: entrega datos a una API de sockets; el transporte genera segmentos o datagramas; IP añade sus direcciones y control; y la interfaz de red encapsula el paquete en una trama adecuada al medio. En recepción se realiza el proceso inverso. La separación facilita que la misma aplicación funcione sobre Ethernet, Wi-Fi, enlaces virtuales o túneles sin conocer los detalles eléctricos o radioeléctricos.

La comunicación «horizontal» entre entidades pares es lógica. Dos implementaciones de TCP parecen intercambiar segmentos directamente, pero la información real desciende por la pila, cruza enlaces y routers y asciende en el destino. Los routers intermedios procesan normalmente hasta la capa de Internet para reenviar, aunque sus funciones de seguridad y gestión pueden inspeccionar capas superiores.

3. ENCAPSULACIÓN, DEMULTIPLEXACIÓN Y UNIDADES DE DATOS

3.1. Encapsulación

La encapsulación es el proceso por el que cada nivel añade información de control a los datos recibidos de la capa superior. Una petición de aplicación se convierte en una unidad de transporte; esta se incluye en un paquete IP; el paquete se incorpora a una trama; y la trama se representa mediante símbolos o señales en el medio. En cada salto, la trama de enlace se consume y se crea otra para el enlace siguiente, mientras que el paquete IP conserva sus direcciones extremo a extremo salvo que intervengan mecanismos como NAT o túneles.

La terminología depende del protocolo. En TCP se habla habitualmente de segmento; en UDP, de datagrama UDP; en IP, de paquete o datagrama; y en Ethernet, de trama. En la formulación abstracta, cada capa intercambia una PDU. Es importante no convertir la tabla didáctica en una regla absoluta: «paquete» puede usarse en sentido genérico y ciertas tecnologías aplican nombres diferentes.

Datos de aplicación
      ↓
[Cabecera TCP o UDP | Datos]
      ↓
[Cabecera IPv4/IPv6 | Cabecera de transporte | Datos]
      ↓
[Cabecera Ethernet | Paquete IP | FCS]
      ↓
Bits o símbolos transmitidos por el medio

3.2. Demultiplexación

En recepción, cada cabecera contiene un identificador que permite entregar la carga al protocolo adecuado. Ethernet usa, entre otros mecanismos, el EtherType para distinguir IPv4 e IPv6. La cabecera IP contiene un campo que identifica el protocolo de capa superior: por ejemplo, TCP, UDP o ICMP. TCP y UDP incorporan puertos de origen y destino para dirigir los datos al socket asociado al proceso. Esta cadena de selectores explica cómo una única interfaz y una única dirección pueden atender simultáneamente servicios web, DNS, correo y administración.

Una conexión TCP se identifica de forma práctica por la combinación de dirección origen, puerto origen, dirección destino, puerto destino y protocolo. Dos clientes pueden conectarse al mismo servidor y puerto porque sus direcciones o puertos efímeros de origen son distintos. El puerto de escucha del servidor no identifica por sí solo una conversación concreta; identifica el punto donde se aceptan nuevas conexiones.

3.3. MTU, MSS y fragmentación

La MTU expresa el tamaño máximo de la carga de red que puede transportar una trama en un enlace sin fragmentación de ese nivel. En Ethernet es frecuente una MTU IP de 1500 octetos, aunque existen otros valores y tramas de mayor tamaño. La MSS de TCP indica la máxima cantidad de datos TCP que un extremo desea recibir en un segmento, excluyendo las cabeceras IP y TCP. Confundir MTU y MSS provoca errores de cálculo y de diagnóstico.

IPv4 permite que un router fragmente un datagrama si supera la MTU de salida, salvo que esté activado el bit DF. La fragmentación aumenta carga y riesgo de pérdida, porque la ausencia de un fragmento impide reconstruir el datagrama completo. En IPv6 los routers no fragmentan paquetes; el origen adapta el tamaño, normalmente con descubrimiento de MTU del camino, y si necesita fragmentar utiliza una cabecera de extensión. Esta diferencia es una perla típica de examen.

El descubrimiento de MTU del camino depende de mensajes ICMP o ICMPv6. Bloquear indiscriminadamente todo ICMP puede producir fallos difíciles de identificar: conexiones que se establecen pero se quedan bloqueadas al transferir respuestas mayores, túneles que funcionan solo con paquetes pequeños o servicios accesibles desde unas redes y no desde otras. La política segura debe filtrar por tipo y contexto, no eliminar ciegamente un protocolo necesario para la operación de IP.

4. PROTOCOLO IPv4 Y CABECERA DEL DATAGRAMA

4.1. Servicio ofrecido por IPv4

IPv4 proporciona un servicio de datagramas no orientado a conexión y de mejor esfuerzo. Cada paquete se trata de forma independiente y puede seguir un camino distinto. El protocolo no promete entrega, orden, latencia máxima ni reserva de ancho de banda. La robustez se consigue combinando redundancia de rutas, protocolos de control y, cuando procede, mecanismos de transporte y aplicación.

El direccionamiento IPv4 utiliza 32 bits. La notación decimal con puntos divide esos bits en cuatro octetos, pero la red no procesa «cuatro números decimales» como unidades lógicas; aplica operaciones binarias con la longitud de prefijo. Una dirección sin su máscara o prefijo es insuficiente para determinar qué parte identifica la red. Por ejemplo, 10.20.30.40 puede pertenecer a 10.20.30.0/24, 10.20.0.0/16 u otra agregación.

4.2. Campos principales de la cabecera

La cabecera mínima ocupa 20 octetos. Las opciones pueden ampliarla hasta 60 octetos, aunque en el tráfico ordinario no son habituales. El campo de longitud total permite un datagrama teórico de hasta 65.535 octetos, pero la MTU de los enlaces limita el tamaño transmitido sin fragmentación. No debe deducirse que cualquier red admite tramas de ese tamaño.

4.3. TTL y diagnóstico

El TTL fue concebido como límite temporal, pero se opera como contador de saltos: cada router lo decrementa al menos en una unidad. Cuando llega a cero, el paquete se descarta y normalmente se genera un mensaje ICMP Time Exceeded. Herramientas de trazado explotan este comportamiento enviando sondas con valores crecientes para obtener respuestas de los routers del camino.

El resultado de un trazado no es un mapa físico perfecto. Puede haber rutas asimétricas, balanceo por flujo, filtrado ICMP, túneles o equipos que no respondan. Un asterisco no prueba por sí solo que el router esté caído; puede significar que reenvía el tráfico pero no genera o no permite la respuesta de diagnóstico.

4.4. Fragmentación IPv4

Los fragmentos comparten el campo Identification y se colocan mediante Fragment Offset. El receptor final reensambla; los routers intermedios no suelen hacerlo. Si se pierde un fragmento, las capas superiores deberán recuperar el datagrama completo cuando el transporte sea fiable. Por esa razón, las arquitecturas modernas intentan evitar la fragmentación y ajustar el tamaño en el origen.

El bit DF se utiliza junto con el descubrimiento de MTU del camino. Si un router no puede reenviar el paquete sin fragmentarlo y DF está activo, lo descarta y comunica la limitación mediante ICMP. Filtrar ese mensaje puede generar un «agujero negro» de PMTUD. En entornos con VPN, encapsulación adicional o enlaces de distinta MTU, este problema aparece con especial frecuencia.

5. DIRECCIONAMIENTO IPV4, SUBREDES Y CIDR

5.1. Prefijo y parte de host

Una dirección IPv4 se interpreta junto con una longitud de prefijo. En 192.168.10.34/24, los primeros 24 bits forman el prefijo y los 8 restantes identifican posiciones dentro de esa subred. La máscara equivalente es 255.255.255.0. El prefijo se obtiene mediante una operación AND entre la dirección y la máscara. Para decidir si un destino es local, el host compara los prefijos resultantes, no los valores decimales de forma intuitiva.

Dirección:  192.168.10.34  = 11000000.10101000.00001010.00100010
Máscara /24:255.255.255.0  = 11111111.11111111.11111111.00000000
Red:        192.168.10.0   = 11000000.10101000.00001010.00000000

En una subred IPv4 convencional, la combinación con todos los bits de host a cero representa la dirección de red y con todos a uno la difusión dirigida de la subred. Por ello, la regla pedagógica para prefijos ordinarios es restar dos al número total de combinaciones de host. Sin embargo, existen excepciones operativas: /31 puede utilizarse en enlaces punto a punto conforme a RFC 3021, y /32 representa una ruta de host. Una pregunta técnica puede valorar que el candidato conozca la regla y sus límites.

5.2. CIDR y abandono de clases

Las clases A, B y C pertenecen al modelo histórico de direccionamiento classful. CIDR introdujo prefijos de longitud variable y agregación, permitiendo asignaciones ajustadas y reducción de entradas de encaminamiento. Hoy una red no se determina por el primer octeto y una supuesta clase, sino por el prefijo anunciado o configurado. Las clases conservan interés histórico y aparecen en manuales, pero no deben usarse para diseñar una red moderna.

La agregación resume varios prefijos contiguos en uno menos específico cuando comparten bits iniciales. Por ejemplo, cuatro redes /24 alineadas pueden resumirse como un /22. La operación reduce el tamaño de las tablas y oculta cambios internos, pero solo es correcta si el router que anuncia el agregado puede alcanzar todo el espacio cubierto o dispone de mecanismos para evitar bucles hacia huecos inexistentes.

5.3. Rangos especiales

Las direcciones privadas permiten reutilizar espacio dentro de múltiples organizaciones. Para comunicarse con Internet suelen combinarse con traducción de direcciones, pero NAT no es una propiedad obligatoria de RFC 1918 ni un mecanismo de encaminamiento global. Una red privada puede comunicarse con otra mediante VPN sin traducir si los prefijos no se solapan y existen rutas adecuadas.

5.4. Plan de direccionamiento

Un plan corporativo debe asignar prefijos de manera jerárquica y resumible, reservar capacidad de crecimiento y separar entornos por función y nivel de confianza. No basta con elegir redes «que parezcan libres». Deben evitarse solapamientos con sedes, proveedores, nubes y VPN; documentarse las asignaciones; integrarse con DNS e inventario; y establecerse procedimientos de alta, cambio y baja.

En una red sanitaria extensa, la jerarquía puede reflejar provincias, centros, edificios, zonas técnicas y tipos de dispositivo, pero la estructura lógica no debe revelar innecesariamente información sensible ni convertirse en una camisa de fuerza. La segmentación clínica, administrativa, de electromedicina, invitados y gestión puede requerir políticas distintas. El direccionamiento facilita la agregación y la política, pero la seguridad real se apoya en autenticación, filtrado, control de acceso, monitorización y configuración segura.

6. IPV6: ARQUITECTURA, DIRECCIONES Y FUNCIONAMIENTO

6.1. Motivación y diseño

IPv6 amplía el espacio de direcciones a 128 bits y revisa varios aspectos operativos de IPv4. Su objetivo no se limita a multiplicar el número de direcciones: simplifica la cabecera base, desplaza funciones opcionales a cabeceras de extensión, elimina la fragmentación por routers, integra Neighbor Discovery y facilita modelos de autoconfiguración. IPv6 no es «IPv4 con direcciones más largas»; exige revisar planificación, seguridad, monitorización, DNS, aplicaciones y procedimientos.

La cabecera base IPv6 tiene longitud fija de 40 octetos. Incluye versión, Traffic Class, Flow Label, Payload Length, Next Header, Hop Limit y direcciones de origen y destino. El campo Next Header puede identificar un protocolo superior o una cabecera de extensión. El Hop Limit cumple la función operativa del TTL. No existe checksum en la cabecera base, reduciendo trabajo repetitivo en cada router.

6.2. Notación

Las direcciones se representan como ocho grupos hexadecimales de 16 bits separados por dos puntos. Pueden omitirse ceros iniciales dentro de cada grupo y sustituirse una única secuencia continua de grupos cero por ::. La compresión :: solo puede aparecer una vez, porque de lo contrario la expansión sería ambigua.

Dirección completa: 2001:0db8:0000:0000:0000:0000:0000:0025
Forma abreviada:  2001:db8::25
Loopback:          ::1
No especificada:   ::

Cuando una dirección IPv6 se incluye en una URL junto con un puerto debe encerrarse entre corchetes para separar los dos puntos internos del delimitador de puerto. Esta regla pertenece a la sintaxis de URI, no al protocolo IP en sí. Un ejemplo sería https://[2001:db8::25]:8443/.

6.3. Tipos y ámbitos

El ámbito es fundamental. Dos interfaces de diferentes enlaces pueden utilizar direcciones link-local con la misma parte numérica; por eso algunos sistemas requieren un identificador de zona al referenciarlas. Una dirección global, una ULA y una link-local pueden coexistir en la misma interfaz. La selección de dirección origen y destino sigue reglas específicas y no debe dejarse al azar en diseños complejos.

6.4. Prefijos y subredes

En muchas LAN IPv6 se utiliza un prefijo /64, dejando 64 bits para el identificador de interfaz. Esta práctica se relaciona con SLAAC y con supuestos presentes en varias especificaciones. No significa que todo prefijo de encaminamiento deba ser /64: enlaces entre routers, loopbacks, delegaciones y agregaciones pueden usar otras longitudes. El diseño debe distinguir el prefijo asignado a una organización, los prefijos de subred y las rutas de host.

La abundancia de espacio no justifica una planificación desordenada. Conviene asignar bloques jerárquicos, facilitar resumen, reservar crecimiento y evitar codificar excesiva información organizativa en cada nibble. IPv6 también debe integrarse con IPAM, DNS directo e inverso, control de acceso, escáneres, SIEM y herramientas de gestión.

6.5. Cabeceras de extensión y fragmentación

Las opciones que en IPv4 podían ampliar la cabecera se modelan en IPv6 mediante una cadena de cabeceras de extensión. Su orden y tratamiento están normalizados. Algunos dispositivos de seguridad han gestionado históricamente estas cadenas de forma deficiente, por lo que la operación debe comprobar interoperabilidad y aplicar reglas que no bloqueen funciones legítimas ni permitan evasiones.

Los routers IPv6 no fragmentan. Si el paquete es demasiado grande para el enlace siguiente, se comunica al origen mediante ICMPv6 Packet Too Big. El origen adapta el tamaño y, si necesita fragmentar, añade la cabecera Fragment. Bloquear ICMPv6 rompe más funciones que en IPv4, porque Neighbor Discovery, descubrimiento de routers y Path MTU dependen de él.

7. CONFIGURACIÓN, ARP, NDP, DHCP Y NAT

7.1. Parámetros necesarios

Para comunicarse más allá de su enlace, un host necesita una dirección válida, un prefijo, información de encaminamiento y, normalmente, resolutores DNS. Estos datos pueden configurarse manualmente o obtenerse automáticamente. La configuración automática reduce errores, pero introduce dependencias en servicios de infraestructura. Una caída de DHCP puede dejar equipos sin dirección utilizable; una configuración DNS incorrecta puede mantener conectividad IP y, sin embargo, inutilizar aplicaciones basadas en nombres.

La puerta de enlace predeterminada no «da Internet» por sí sola. Es una ruta de último recurso hacia un router que debe disponer a su vez de rutas, políticas y conectividad. Un equipo puede tener puerta de enlace correcta y fallar por filtrado; o puede comunicarse con todas las redes necesarias sin ruta por defecto si dispone de rutas específicas.

7.2. ARP en IPv4

ARP permite conocer la dirección de enlace asociada a una dirección IPv4 situada en el mismo dominio de difusión. El host emite una solicitud preguntando quién posee la dirección objetivo y el propietario responde con su MAC. La asociación se guarda temporalmente en caché. Para un destino remoto, el host no busca la MAC final: resuelve la MAC del siguiente salto seleccionado por la tabla de rutas.

ARP carece de autenticación fuerte y puede ser objeto de suplantación. Los switches, controles de acceso y funciones como Dynamic ARP Inspection pueden mitigar riesgos en redes administradas, pero requieren una base confiable de asociaciones. Las entradas estáticas reducen exposición en casos concretos, aunque no escalan bien.

Windows:
arp -a

Linux con iproute2:
ip neigh show

7.3. Neighbor Discovery en IPv6

IPv6 reemplaza ARP por Neighbor Discovery, construido sobre ICMPv6. NDP descubre vecinos y routers, resuelve direcciones de enlace, comprueba alcanzabilidad, detecta duplicados y procesa redirecciones. Los mensajes Router Advertisement permiten anunciar prefijos, ruta por defecto y otros parámetros. La protección de NDP es crítica porque un anuncio de router falso puede desviar tráfico.

SLAAC permite formar direcciones a partir de prefijos anunciados. El identificador de interfaz no tiene por qué derivarse de la MAC; los sistemas modernos suelen emplear identificadores estables o temporales por razones de privacidad. DHCPv6 puede entregar direcciones y opciones, pero la ruta por defecto se aprende normalmente mediante Router Advertisement, una diferencia relevante respecto a DHCPv4.

7.4. DHCP

DHCPv4 automatiza la concesión de direcciones y opciones. El intercambio inicial suele resumirse como Discover, Offer, Request y Acknowledgment. El cliente que aún no dispone de dirección utiliza difusión y puertos UDP específicos. El servidor concede un arrendamiento con duración y parámetros. Los relay agents permiten atender subredes distintas sin desplegar un servidor en cada dominio de broadcast.

Un servicio corporativo debe coordinar DHCP con DNS e inventario. Las reservas pueden asociar dispositivos conocidos a direcciones previsibles; las actualizaciones dinámicas pueden registrar nombres; los registros de concesiones aportan trazabilidad. No obstante, identificar a un usuario solo por la IP es insuficiente: las direcciones cambian, se comparten mediante NAT y pueden ser falsificadas en determinados contextos.

7.5. NAT y PAT

NAT modifica direcciones en tránsito y puede ser estático, dinámico o combinarse con traducción de puertos. PAT permite que múltiples conexiones privadas compartan una dirección pública diferenciándose por puertos y estado. Esta técnica prolongó la vida de IPv4 y facilita ciertos diseños, pero rompe la transparencia extremo a extremo, complica algunos protocolos, dificulta trazabilidad y obliga a mantener estado.

Un cortafuegos con NAT puede bloquear conexiones entrantes no solicitadas como consecuencia de su política y de la ausencia de traducción, pero NAT no es sinónimo de cortafuegos. La seguridad debe expresarse mediante reglas explícitas, identidad, segmentación y registro. Del mismo modo, una dirección privada no es automáticamente confiable: puede originar tráfico malicioso desde un equipo comprometido.

8. TCP: TRANSPORTE FIABLE ORIENTADO A CONEXIÓN

8.1. Servicio y conexiones

TCP ofrece un flujo de octetos fiable, bidireccional y orientado a conexión entre procesos. No conserva los límites de mensajes de la aplicación: si una aplicación envía dos bloques, el receptor puede leerlos juntos o fraccionados. El protocolo garantiza el orden del flujo, no la preservación de llamadas individuales a escritura. Por ello, protocolos de aplicación deben definir longitud, delimitadores o estructuras que permitan reconstruir mensajes.

Antes de intercambiar datos se establece estado mediante el three-way handshake. Un extremo envía SYN, el otro responde SYN-ACK y el iniciador confirma con ACK. El intercambio sincroniza números de secuencia y negocia opciones. La existencia de una conexión no implica autenticación del usuario ni cifrado; TLS, SSH u otros protocolos aportan seguridad adicional.

Cliente                              Servidor
  | -------- SYN, seq=x -------------> |
  | <--- SYN+ACK, seq=y, ack=x+1 ------ |
  | -------- ACK, ack=y+1 ------------> |
  | ===== flujo de datos fiable ====== |

8.2. Cabecera y números de secuencia

La cabecera TCP contiene puertos, números de secuencia y confirmación, longitud de cabecera, bits de control, ventana, checksum, puntero urgente y opciones. La cabecera mínima ocupa 20 octetos. Los números de secuencia cuentan octetos del flujo; el ACK acumulativo indica el siguiente octeto esperado. SYN y FIN consumen espacio de secuencia porque representan eventos dentro del flujo lógico.

Entre los bits de control más conocidos se encuentran SYN, ACK, FIN, RST, PSH y URG, además de indicadores relacionados con ECN. RST aborta una conexión o rechaza tráfico que no corresponde a un estado válido. FIN realiza un cierre ordenado en una dirección; como TCP es dúplex, cada sentido puede cerrarse por separado.

8.3. Fiabilidad

El emisor conserva datos no confirmados y retransmite cuando detecta pérdida mediante temporizadores o patrones de ACK. El receptor puede descartar duplicados y reordenar segmentos. La suma de comprobación cubre cabecera y datos e incorpora una pseudocabecera IP para detectar ciertos errores de entrega. La fiabilidad no significa que una aplicación reciba respuesta en un tiempo ilimitado: una conexión puede agotarse, restablecerse o quedar afectada por fallos persistentes.

Las confirmaciones selectivas permiten informar de bloques recibidos y mejorar la recuperación ante pérdidas múltiples. Las opciones de timestamp ayudan a medir tiempos y proteger frente a ambigüedades. La implementación moderna de TCP es resultado de múltiples RFC; no debe reducirse a la especificación histórica de 1981.

8.4. Control de flujo y congestión

El control de flujo protege al receptor. Mediante la ventana anunciada, indica cuánto espacio puede aceptar. El control de congestión protege la red y adapta la cantidad de datos en vuelo a señales de pérdida o congestión. Son objetivos diferentes, aunque ambos limitan el envío efectivo. La ventana utilizable depende de la menor restricción entre capacidad del receptor y control de congestión.

En enlaces de gran ancho de banda y alta latencia, el producto ancho de banda-retardo determina cuántos datos deben estar en vuelo para utilizar la capacidad. El escalado de ventana permite superar el límite del campo básico. Un rendimiento bajo no implica necesariamente falta de ancho de banda: pérdidas, RTT elevado, ventanas pequeñas, inspección, servidor lento o aplicación secuencial pueden limitarlo.

8.5. Estados y cierre

TCP define una máquina de estados: LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, estados de cierre y TIME-WAIT, entre otros. TIME-WAIT evita que segmentos retrasados de una conexión anterior interfieran con una nueva y permite retransmitir el ACK final. Un número alto de sockets TIME-WAIT no demuestra por sí solo un ataque; debe analizarse junto con el patrón de la aplicación y los recursos disponibles.

El comando netstat -ano en Windows muestra conexiones, direcciones numéricas y PID. En sistemas modernos también se usan herramientas como Get-NetTCPConnection o ss, pero el conocimiento de netstat sigue apareciendo en exámenes. La asociación entre PID y servicio permite comprobar si la aplicación realmente escucha y si el puerto esperado está ocupado por otro proceso.

C:> netstat -ano
Proto  Local Address          Foreign Address        State           PID
TCP    0.0.0.0:443            0.0.0.0:0              LISTENING       4120
TCP    10.20.30.40:51120      10.50.60.70:443        ESTABLISHED     8240

9. UDP, ICMP Y OTROS PROTOCOLOS DE INTERNET

9.1. UDP

UDP ofrece un servicio de datagramas no orientado a conexión con una cabecera mínima de 8 octetos: puerto origen, puerto destino, longitud y checksum. Preserva los límites del mensaje: cada datagrama enviado corresponde a una unidad recibida, si llega. No establece sesión, no confirma entrega, no reordena y no aplica por sí mismo control de congestión o retransmisión.

Estas propiedades no convierten a UDP en «malo» o «inseguro». Resulta adecuado cuando la aplicación tolera pérdidas, necesita baja latencia, realiza intercambios breves o implementa su propio control. DNS, NTP, streaming, voz y numerosos protocolos de control lo utilizan. QUIC construye transporte fiable, cifrado y multiplexado sobre UDP para poder evolucionar en espacio de usuario y evitar ciertas limitaciones de intermediarios.

Una aplicación sobre UDP debe considerar tamaño, pérdida, duplicados, orden, amplificación y control de congestión. En servicios de petición-respuesta, respuestas mucho mayores que solicitudes pueden explotarse en ataques de reflexión si el origen se falsifica. Las medidas incluyen validación, limitación de tasa, configuración adecuada y prevención de spoofing en redes de origen.

9.2. ICMP e ICMPv6

ICMP acompaña a IP con mensajes de error y diagnóstico. No es un protocolo de transporte para aplicaciones generales. Entre sus funciones se encuentran Echo Request/Reply, Destination Unreachable, Time Exceeded y mensajes relacionados con parámetros o redirecciones. ICMPv6 tiene un papel aún más amplio: soporta Neighbor Discovery, descubrimiento de routers, Path MTU y multicast listener discovery.

Un mensaje ICMP informa de una condición, pero no garantiza que el emisor original lo reciba ni que cada fallo genere uno. Las políticas de seguridad, limitaciones de tasa y reglas del protocolo pueden impedir respuestas. Por eso una ausencia de eco no prueba que el destino esté apagado, y una respuesta de eco no prueba que el servicio de aplicación funcione.

9.3. Ping y trazado de ruta

ping utiliza mensajes Echo para medir alcance y tiempo de ida y vuelta aproximado. La latencia observada incluye procesamiento, colas y camino de retorno, y puede variar por priorización. Una pérdida de respuestas puede deberse a filtrado o rate limiting y no necesariamente a pérdida de tráfico de aplicación.

Las herramientas de trazado envían sondas con TTL o Hop Limit creciente. Cada router que agota el valor puede responder con Time Exceeded. Windows tracert utiliza por defecto sondas ICMP Echo; otras implementaciones pueden usar UDP o TCP según herramienta y opciones. Memorizar que «traceroute siempre usa UDP» o «siempre usa ICMP» es incorrecto sin especificar plataforma y modalidad.

Windows sin resolución de nombres intermedia:
tracert -d 10.20.30.40

Linux, consulta habitual de ruta:
ip route get 10.20.30.40

Linux, trazado sin resolver nombres:
traceroute -n 10.20.30.40

9.4. Multicast

IGMP gestiona pertenencia a grupos multicast en IPv4; en IPv6 se utiliza Multicast Listener Discovery dentro de ICMPv6. La pertenencia del receptor no crea por sí sola rutas multicast entre redes. Los routers necesitan protocolos y políticas específicos. Multicast puede ser eficiente para distribuir un flujo a múltiples receptores, pero añade complejidad de control, seguridad y diagnóstico.

9.5. IPsec

IPsec es una familia de mecanismos de seguridad en la capa IP. Puede proporcionar autenticación, integridad, protección frente a repetición y confidencialidad, especialmente mediante ESP. Funciona en modo transporte o túnel y se utiliza en VPN. Su presencia no elimina la necesidad de seguridad de aplicación: el cifrado del túnel protege un tramo o relación, mientras que autenticación, autorización y minimización de datos siguen siendo responsabilidades superiores.

10. SERVICIOS BASADOS EN TCP/IP Y PUERTOS

10.1. Puertos y registro IANA

TCP y UDP utilizan números de puerto de 16 bits. IANA mantiene el registro de nombres de servicio y puertos, dividido de forma general en puertos de sistema, de usuario y dinámicos o privados. Una asignación estándar facilita interoperabilidad, pero no obliga a que toda implementación use siempre ese puerto. Un servidor web puede escuchar en 8443 y una aplicación puede anunciar un puerto mediante configuración o DNS SRV.

El puerto no es una medida de seguridad. Cambiar SSH del 22 a otro valor puede reducir ruido automático, pero no sustituye autenticación fuerte, parcheado, filtrado y monitorización. Tampoco basta con observar un puerto abierto para identificar con certeza la aplicación: debe verificarse el protocolo real y el proceso asociado.

10.2. Servicios web y APIs

HTTP define un modelo de petición-respuesta con métodos, identificadores de recurso, cabeceras y códigos de estado. HTTPS añade protección TLS. HTTP/2 multiplexa múltiples flujos sobre una conexión y comprime cabeceras; HTTP/3 utiliza QUIC sobre UDP. Estas versiones no cambian la semántica básica de los métodos, pero sí el transporte y la gestión de concurrencia.

Las APIs clínicas y administrativas suelen usar HTTPS con JSON o XML. La conectividad de red es condición necesaria, no suficiente: deben validarse certificados, nombres, identidad del cliente, autorización, límites, integridad y trazabilidad. Una API accesible por IP puede fallar al usar HTTPS porque el certificado y el nombre esperado no coinciden; por eso DNS forma parte de la arquitectura de seguridad y no solo de la comodidad.

10.3. Correo

SMTP transfiere mensajes; IMAP permite acceder y sincronizar buzones; POP3 ofrece un modelo de recuperación más simple. Los puertos y perfiles de cifrado dependen de si se trata de transferencia entre servidores, envío autenticado o acceso del usuario. En examen debe evitarse la simplificación «el correo usa el puerto 25» como respuesta universal: el 25 es fundamental para SMTP entre servidores, pero la arquitectura completa incorpora otros servicios y puertos.

10.4. Administración y transferencia

SSH proporciona terminal segura, ejecución remota, copia mediante SCP/SFTP y túneles. Telnet transmite sin protección y no debe emplearse para credenciales en redes no confiables. FTP clásico utiliza conexiones separadas de control y datos, con modos activo y pasivo que complican cortafuegos y NAT. SFTP no es «FTP cifrado»: es un protocolo de transferencia sobre SSH.

10.5. Gestión, tiempo y observabilidad

SNMP permite consultar objetos de gestión y recibir notificaciones. Las versiones antiguas se apoyan en comunidades con protección limitada; SNMPv3 incorpora modelos de seguridad. NTP sincroniza relojes y es esencial para correlacionar eventos, validar certificados, aplicar Kerberos y reconstruir incidentes. Syslog transporta eventos, pero su fiabilidad y seguridad dependen del transporte y perfil utilizados.

La observabilidad debe combinar métricas, logs, trazas y pruebas sintéticas. Que un puerto responda no prueba que la operación de negocio sea correcta; que el DNS resuelva no prueba que el backend esté sano. Una monitorización madura verifica desde capas inferiores hasta transacciones representativas y registra dependencias.

10.6. Cliente-servidor y sockets

Un servidor enlaza un socket a una dirección local y puerto, y queda a la escucha o recibe datagramas. Enlazar a 0.0.0.0 o :: suele significar escuchar en todas las interfaces compatibles; enlazar a loopback limita el acceso al host local. Un servicio puede estar iniciado pero escuchar solo en una interfaz incorrecta, motivo por el que la inspección de sockets debe revisar dirección local, no únicamente puerto.

11. DNS: ARQUITECTURA, JERARQUÍA Y RESOLUCIÓN

11.1. Finalidad y modelo distribuido

El Domain Name System es una base de datos jerárquica y distribuida que permite asociar nombres con información. Su uso más visible es traducir un nombre de host a direcciones IPv4 o IPv6, pero DNS también publica servidores de correo, autoridades de zona, servicios, claves y políticas. La arquitectura evita una tabla mundial centralizada: la responsabilidad se delega por zonas y cada servidor autoritativo responde por los datos que administra.

El espacio de nombres forma un árbol cuya raíz se representa por un punto final. Bajo la raíz se encuentran dominios de primer nivel, como .es, .com u otros. Cada etiqueta descendente delimita un subdominio. Un nombre completo puede escribirse como FQDN con punto final, aunque las aplicaciones suelen omitirlo. La comparación DNS no distingue mayúsculas y minúsculas en las etiquetas ordinarias, pero los datos asociados pueden conservar su forma.

11.2. Resolver, servidor recursivo y servidor autoritativo

La biblioteca del sistema operativo o stub resolver envía la consulta a un resolutor recursivo configurado. Este resolutor busca la respuesta en caché y, si no la tiene, consulta a la jerarquía. Puede preguntar a un servidor raíz, seguir la referencia al TLD y después consultar al servidor autoritativo de la zona. El cliente final suele pedir recursión al resolutor; los servidores autoritativos responden sobre sus zonas y no necesitan realizar recursión pública.

Una consulta recursiva solicita una respuesta final o un error. Una consulta iterativa permite que el servidor devuelva la mejor información disponible, incluida una referencia. Los términos no describen dos redes distintas, sino modos de interacción. El resolutor recursivo realiza normalmente una secuencia iterativa en nombre del cliente.

11.3. Caché y TTL

Las respuestas incluyen un TTL que limita cuánto tiempo pueden conservarse en caché. La caché reduce latencia y carga, pero introduce un periodo durante el cual pueden coexistir datos antiguos y nuevos. Cambiar un registro no invalida mágicamente todas las cachés. La operación debe reducir el TTL con antelación cuando planifique una migración y restaurarlo después para evitar una carga innecesaria.

DNS también almacena respuestas negativas. Un resultado NXDOMAIN indica que el nombre no existe; una respuesta sin datos puede indicar que el nombre existe pero no tiene el tipo solicitado. Distinguir ambos casos es importante para aplicaciones, diagnóstico y DNSSEC. Las cachés negativas evitan repetir consultas fallidas, por lo que una corrección puede tardar en verse si el error ya fue almacenado.

11.4. Flujo de resolución

Aplicación
   ↓ solicita dirección de api.ejemplo.es
Stub resolver del sistema
   ↓ consulta al resolutor corporativo
Resolutor recursivo
   ├── comprueba caché
   ├── consulta raíz si es necesario
   ├── sigue delegación hacia .es
   ├── sigue delegación hacia ejemplo.es
   └── obtiene respuesta autoritativa
   ↓ devuelve A/AAAA y TTL
Aplicación conecta con la dirección seleccionada

La aplicación puede recibir varias direcciones y elegir según reglas del sistema, disponibilidad de IPv6 y políticas. El orden de respuesta no debe interpretarse siempre como prioridad estricta. En servicios distribuidos, DNS puede participar en balanceo, geolocalización o failover, pero carece de conocimiento transaccional completo y está condicionado por cachés.

11.5. Resolución directa e inversa

La resolución directa obtiene información a partir de un nombre. La inversa busca un nombre asociado a una dirección mediante registros PTR bajo in-addr.arpa para IPv4 e ip6.arpa para IPv6. La existencia de un PTR no demuestra identidad ni autorización, y una dirección puede carecer de resolución inversa. Algunos servicios de correo la utilizan como señal de reputación junto con otros controles.

12. REGISTROS, ZONAS, TRANSFERENCIAS Y SEGURIDAD DNS

12.1. Registros de recurso

Un CNAME introduce una indirection: el resolutor debe obtener después los datos del nombre canónico. Su uso en el vértice de una zona entra en conflicto con registros obligatorios como SOA y NS, por lo que proveedores ofrecen mecanismos propietarios con nombres diferentes para simular un alias. En examen debe distinguirse el estándar de las extensiones comerciales.

12.2. Zonas y delegación

Un dominio es una rama del espacio de nombres; una zona es la porción administrada por una autoridad concreta. Pueden coincidir, pero una organización puede delegar un subdominio y dividir la rama en varias zonas. La zona padre publica registros NS para el hijo y, cuando el nombre del servidor está dentro del dominio delegado, puede necesitar direcciones glue para evitar una dependencia circular.

La autoridad debe desplegar varios servidores en ubicaciones y redes independientes. La redundancia nominal no es suficiente si todos dependen del mismo centro, proveedor o enlace. Anycast puede anunciar una misma dirección desde múltiples nodos, permitiendo que el encaminamiento lleve la consulta a una instancia cercana y resistente.

12.3. Transferencias y actualización

AXFR transfiere una zona completa y IXFR permite transferencias incrementales cuando se soporta. DNS NOTIFY avisa a secundarios de que existe una nueva versión. Las transferencias deben restringirse a servidores autorizados y protegerse cuando corresponda mediante mecanismos como TSIG. Exponer AXFR a cualquiera facilita reconocimiento de la infraestructura.

DNS utiliza tanto UDP como TCP en el puerto 53. Las consultas ordinarias suelen comenzar por UDP por su menor coste, pero TCP se usa cuando la respuesta lo requiere, en transferencias de zona y en otros escenarios. Las implementaciones modernas deben soportar DNS sobre TCP; afirmar que TCP/53 «solo sirve para AXFR» es una simplificación excesiva.

Consulta con herramientas habituales:
nslookup -type=AAAA ejemplo.es

dig ejemplo.es A
dig ejemplo.es MX
dig -x 192.0.2.25

Los ejemplos utilizan dominios y redes reservadas para documentación. En producción deben consultarse servidores autorizados y evitar publicar datos internos en salidas no controladas.

12.4. DNSSEC

DNSSEC firma conjuntos de registros y crea una cadena de confianza desde una ancla configurada. Un resolutor validador puede distinguir datos auténticos, datos inseguros sin firma y respuestas inválidas. DNSSEC protege integridad y autenticidad de origen; no cifra las consultas ni oculta qué nombre se solicita.

La operación exige gestionar claves, firmas, renovaciones y registros DS en el padre. Un error de sincronización puede hacer que una zona correcta desde el punto de vista convencional resulte bogus para validadores. Por ello, el despliegue debe automatizarse, monitorizarse y probarse antes y después de cada cambio.

12.5. DNS cifrado y seguridad operacional

DNS over TLS utiliza el puerto 853 y DNS over HTTPS transporta DNS dentro de HTTPS, habitualmente por 443. Ambos protegen el tramo entre cliente y resolutor, pero no sustituyen DNSSEC ni cifran necesariamente las consultas posteriores del resolutor hacia servidores autoritativos. En una organización, resolutores externos no autorizados pueden eludir filtrado, registro y resolución de zonas internas; la política debe equilibrar privacidad, control y seguridad.

Las amenazas incluyen envenenamiento de caché, secuestro de cuentas del registrador, cambios no autorizados, amplificación, dominios parecidos y uso malicioso de registros. La defensa combina MFA, separación de funciones, bloqueo de transferencias, DNSSEC, monitorización de cambios, listas de acceso, rate limiting y planes de recuperación.

13. GESTIÓN DE NOMBRES DE DOMINIO EN ESPAÑA

13.1. El código de país .es

.es es el dominio de nivel superior geográfico correspondiente a España. La autoridad de registro está encomendada a la Entidad Pública Empresarial Red.es, que opera el Registro de nombres bajo el código de país y el servicio Dominios.es. La función comprende sistemas, bases de datos, procedimientos de asignación y coordinación con agentes registradores.

La gestión debe diferenciarse de la operación técnica del DNS de una organización. Red.es administra el registro del TLD y las delegaciones correspondientes; el titular de un dominio administra sus datos a través de un agente o canal habilitado y designa los servidores autoritativos que publican la zona. El registrador no es necesariamente el proveedor de hosting, DNS o correo, aunque puede ofrecer todos esos servicios.

13.2. Marco normativo

El sistema se apoya en la disposición adicional sexta de la Ley 34/2002, de servicios de la sociedad de la información y de comercio electrónico, y en el Plan Nacional de nombres de dominio bajo .es, aprobado por la Orden ITC/1542/2005. El Plan atribuye a Red.es la función de autoridad de asignación y establece principios de interés general, seguridad, calidad, eficacia, fiabilidad y accesibilidad. Las operaciones se concretan mediante instrucciones y procedimientos publicados por Red.es.

La normativa de dominios no concede al titular derechos absolutos sobre cualquier término. Existen nombres prohibidos o reservados, reglas para dominios especiales y mecanismos de cancelación o reasignación. Además, el registro puede entrar en conflicto con marcas, denominaciones sociales, nombres civiles u otros derechos. La asignación técnica no resuelve por sí sola todas las controversias jurídicas.

13.3. Categorías bajo .es

13.4. Agentes registradores y ciclo de vida

Los agentes registradores acreditados actúan como intermediarios para solicitud, renovación y gestión. Pueden ofrecer DNS, alojamiento, correo, certificados y protección de marca. La organización debe seleccionar proveedor por seguridad, soporte, trazabilidad, capacidades de API, segregación de funciones y recuperación, no solo por precio.

El ciclo incluye comprobación de disponibilidad, solicitud, asignación, configuración de contactos y servidores, renovación, modificación, transferencia entre agentes, transmisión de titularidad y baja. La pérdida de un dominio por no renovar puede interrumpir web, correo, APIs y validación de identidad. Los dominios corporativos deben tratarse como activos críticos con responsable, alertas, renovación automática controlada y procedimientos de emergencia.

13.5. Gobierno de dominios públicos

Una Administración debe mantener inventario de dominios y subdominios, justificar altas, eliminar registros obsoletos, aplicar MFA y limitar quién puede cambiar delegaciones. También debe controlar certificados, CAA, DNSSEC y exposición de servicios. Los subdominios abandonados que apuntan a recursos cloud eliminados pueden permitir secuestros; por ello la baja de una aplicación debe incluir la retirada coordinada de DNS.

La continuidad requiere diversidad de servidores autoritativos, copias de configuración, contactos actualizados y capacidad para cambiar delegaciones. La seguridad de la cuenta del registrador es tan importante como la de los servidores DNS: quien controla la delegación puede redirigir web y correo incluso sin comprometer los sistemas internos.

14. FUNDAMENTOS DEL ENCAMINAMIENTO IP

14.1. Reenvío frente a encaminamiento

El reenvío es la operación por paquete: leer el destino, buscar la entrada aplicable y transmitir por una interfaz o hacia un siguiente salto. El encaminamiento construye la información que hace posible ese reenvío. Puede provenir de redes conectadas, configuración estática, protocolos internos, BGP, túneles o políticas.

Un router no necesita conocer la ruta completa extremo a extremo. Conoce el siguiente paso para un conjunto de prefijos. Cada router repite la decisión hasta alcanzar una red conectada al destino. Este modelo distribuido permite escalar, pero puede producir bucles o agujeros si las tablas son inconsistentes.

14.2. Prefijo más largo

Cuando varias rutas coinciden con el destino, se elige la de prefijo más largo, es decir, la más específica. Una ruta /24 prevalece sobre una /16 que cubra el mismo destino, y esta sobre la ruta por defecto /0. La métrica o distancia se compara después entre rutas hacia el mismo prefijo o según las reglas de la plataforma; una ruta por defecto con mejor métrica no vence a una específica.

Destino: 10.144.2.5
Rutas coincidentes:
10.0.0.0/8
10.144.0.0/16
10.144.2.0/24   ← se elige por ser la más específica

14.3. Siguiente salto e interfaz

Una entrada puede indicar una interfaz directamente conectada o la dirección de un router vecino. Si utiliza siguiente salto, el equipo debe resolver cómo alcanzar ese vecino, lo que puede implicar una búsqueda recursiva en la tabla. Finalmente necesita una dirección de enlace o mecanismo del medio para transmitir.

La ruta por defecto se usa cuando no existe coincidencia más específica. En hosts suele apuntar a la puerta de enlace; en routers de borde puede apuntar al proveedor. Un núcleo corporativo grande puede operar sin default y exigir rutas explícitas para evitar salidas inesperadas.

14.4. Rutas conectadas, estáticas y dinámicas

Las rutas conectadas aparecen al configurar una interfaz operativa. Las estáticas ofrecen predictibilidad y bajo coste, pero requieren mantenimiento manual y no reaccionan solas salvo que se combinen con seguimiento. Las dinámicas intercambian información y convergen ante cambios, a costa de complejidad, consumo y necesidad de seguridad.

Una ruta estática «flotante» puede tener preferencia menor que la aprendida dinámicamente y actuar como respaldo. La preferencia se expresa mediante distancia administrativa u otro criterio local, no es un estándar universal entre fabricantes. Las métricas de protocolos diferentes tampoco se comparan directamente; primero se decide qué fuente es preferida.

14.5. Dominios y sistemas autónomos

Los protocolos IGP operan dentro de un dominio administrativo o sistema autónomo. BGP intercambia alcanzabilidad y política entre sistemas autónomos y también puede distribuir rutas internamente. Un AS representa un conjunto de prefijos y routers bajo una política común de encaminamiento, identificado por un número de sistema autónomo.

La distinción IGP/EGP no significa que BGP solo funcione «fuera» de una organización. iBGP se usa dentro del AS para propagar rutas externas y políticas. Del mismo modo, OSPF no está diseñado para anunciar la tabla global de Internet, aunque sea adecuado para una red corporativa.

14.6. Convergencia y estabilidad

La convergencia es el proceso por el que los routers alcanzan una visión coherente tras un cambio. Debe equilibrar rapidez y estabilidad: reaccionar demasiado despacio prolonga la caída; reaccionar a cada oscilación puede amplificar inestabilidad. Temporizadores, detección de fallos, resumen, áreas y políticas influyen en el resultado.

La convergencia del control no garantiza que toda aplicación se recupere al instante. Estados de NAT, sesiones TCP, DNS en caché, balanceadores y rutas asimétricas pueden mantener impacto. La continuidad debe probarse de extremo a extremo.

15. TABLA DE RUTAS, SELECCIÓN Y DIAGNÓSTICO

15.1. Contenido de una ruta

Una tabla contiene prefijo destino, longitud, siguiente salto o interfaz, métrica, origen y estado. Algunas plataformas mantienen una base de información de routing con varias candidatas y una tabla de reenvío optimizada con las rutas instaladas. La salida de un comando puede mostrar más datos de los que utiliza el plano de datos, por lo que debe interpretarse la columna y contexto correctos.

La ruta local hacia la propia dirección, la ruta conectada de la subred y la ruta por defecto cumplen funciones distintas. El hecho de que una interfaz esté «up» no garantiza que el enlace de extremo a extremo sea operativo. Protocolos de detección y pruebas activas pueden retirar rutas cuando falla un siguiente salto más allá del estado físico.

15.2. Rutas asimétricas y políticas

El tráfico de ida y vuelta puede seguir caminos distintos. IP lo permite, pero cortafuegos con estado, NAT, balanceadores y diagnósticos pueden requerir simetría. Un paquete puede llegar al servidor y la respuesta salir por otra puerta de enlace donde se descarta o no existe el estado correspondiente.

El routing basado en políticas puede considerar origen, marca, interfaz o clase de tráfico, no solo destino. Estas funciones son útiles para múltiples proveedores, segmentación o SD-WAN, pero complican el principio de «mirar la tabla principal». El diagnóstico debe comprobar reglas, tablas alternativas y túneles.

15.3. Herramientas

15.4. Método de diagnóstico

1. Confirmar alcance y síntoma: un usuario, una sede, un protocolo o toda la red.
2. Verificar interfaz, dirección, prefijo y estado.
3. Comprobar si el destino es local o remoto y qué ruta se selecciona.
4. Validar resolución de vecino para el siguiente salto.
5. Probar alcance IP y analizar ICMP sin convertirlo en prueba absoluta.
6. Comprobar DNS directo, inverso y servidor consultado.
7. Verificar puerto, socket, proceso, cortafuegos y balanceador.
8. Correlacionar logs, tiempos, cambios y rutas de retorno.

La comparación entre una prueba por IP y por nombre es especialmente útil. Si ping 10.20.30.40 funciona y ping servidor.interno no, la hipótesis DNS gana peso; si el nombre resuelve pero el puerto falla, deben revisarse servicio y filtrado. Sin embargo, la aplicación puede usar otro nombre, proxy o protocolo, por lo que la prueba debe reproducir el flujo real.

15.5. Errores recurrentes

Entre los fallos habituales figuran máscara incorrecta, gateway fuera de subred, rutas solapadas, VPN que instala una ruta más específica, DNS público en lugar de interno, MTU reducida por túnel, firewall que permite ida pero no retorno, servicio ligado a loopback, y selección inesperada entre IPv4 e IPv6.

Los cambios de red deben tener plan de reversión y validación. Una prueba de «ping al gateway» no basta para aprobar una migración: deben comprobarse servicios clínicos, DNS, rutas redundantes, trazabilidad, rendimiento y comportamiento ante fallo.

16. PROTOCOLOS DE ENCAMINAMIENTO: RIP, OSPF Y BGP

16.1. Clasificación

Los protocolos dinámicos pueden clasificarse por ámbito y algoritmo. RIP es un vector-distancia; OSPF es de estado de enlace; BGP se describe como path vector y orientado a política. La clasificación ayuda a entender qué información intercambian, cómo calculan caminos y qué problemas intentan resolver.

16.2. RIP

RIPv2 intercambia rutas periódicamente y utiliza el número de saltos como métrica. Quince saltos es el máximo alcanzable y dieciséis representa infinito. Su simplicidad facilita aprendizaje, pero limita escala y convergencia. Mecanismos como split horizon, poison reverse y triggered updates reducen bucles y aceleran cambios.

RIPv2 incluye máscara, siguiente salto, etiqueta de ruta y soporte de autenticación, a diferencia del diseño classful original. Aun así, no selecciona caminos por ancho de banda, latencia o política avanzada. En redes críticas grandes se prefiere normalmente un protocolo de estado de enlace.

16.3. OSPF

OSPF permite que cada router construya una base de estado de enlace y ejecute el algoritmo SPF para calcular caminos. Los routers descubren vecinos con mensajes Hello, forman adyacencias cuando procede, sincronizan bases y difunden LSAs. El resultado es una visión topológica del área, no solo una lista recibida del vecino.

La jerarquía en áreas reduce el alcance de la información. El área 0 actúa como backbone en el diseño OSPFv2 clásico y conecta áreas. Los routers pueden ser internos, de borde de área o de frontera con otros dominios. El resumen y la correcta división evitan una base excesiva, aunque una fragmentación artificial puede complicar operación.

El coste se deriva de una referencia de ancho de banda según implementación y configuración. Dos equipos deben usar criterios coherentes para evitar decisiones asimétricas inesperadas. OSPF no mide automáticamente calidad de aplicación; su métrica representa una preferencia de routing.

OSPFv2 se especifica para IPv4 en RFC 2328. OSPFv3 se definió para IPv6 en RFC 5340 y cambia tratamiento de direcciones y funcionamiento por enlace. No debe afirmarse que OSPFv3 es simplemente «OSPFv2 con direcciones más largas».

16.4. BGP

BGP anuncia prefijos junto con atributos que permiten aplicar política. AS_PATH registra sistemas autónomos atravesados y ayuda a evitar bucles. NEXT_HOP indica el siguiente salto; LOCAL_PREF se utiliza dentro de un AS para preferir salida; MED sugiere preferencia de entrada a un vecino, sujeto a política; comunidades etiquetan rutas para acciones coordinadas.

La selección BGP no se reduce a «el camino con menos saltos». Intervienen política local y múltiples atributos. Un AS puede preferir una ruta más larga por coste, seguridad o contrato. La tabla global escala mediante CIDR y agregación, pero los anuncios más específicos pueden atraer tráfico.

eBGP intercambia rutas entre AS; iBGP las distribuye dentro. iBGP requiere una topología lógica completa o mecanismos como route reflectors para escalar. BGP usa TCP para la sesión, pero la fiabilidad de TCP no valida la legitimidad de los anuncios. Filtros, registros de rutas y RPKI ayudan a reducir secuestros y fugas.

16.5. Redistribución y riesgos

Redistribuir rutas entre protocolos puede causar bucles, realimentación y pérdida de atributos. Debe aplicarse con filtros, etiquetas, métricas y puntos claros de control. No es recomendable «redistribuir todo en ambos sentidos» sin diseño. Las rutas por defecto y resúmenes deben anunciarse solo desde equipos capaces de prestar la conectividad prometida.

16.6. Alta disponibilidad

La redundancia de routers puede apoyarse en protocolos de primer salto para ofrecer una puerta de enlace virtual. El IGP calcula caminos alternativos y BGP gestiona proveedores o sedes. La detección rápida mediante BFD u otros mecanismos puede reducir tiempos, pero una sensibilidad excesiva ante microcortes genera inestabilidad.

La alta disponibilidad debe considerar estado de firewall, NAT, DNS y aplicación. Una ruta alternativa que lleva a un cortafuegos sin sesiones puede provocar reinicios de TCP. El objetivo no es solo que exista un camino, sino que el servicio mantenga una experiencia y consistencia aceptables.

17. APLICACIÓN EN EL SAS, SEGURIDAD Y MAPA CONCEPTUAL

17.1. Aplicación en una red sanitaria

Los sistemas asistenciales, administrativos y de infraestructura del SAS dependen de TCP/IP. Una estación clínica puede resolver nombres internos, acceder por HTTPS a servicios, consultar directorios, intercambiar mensajes de interoperabilidad y alcanzar bases de datos o sistemas de imagen a través de múltiples segmentos. La criticidad exige disponibilidad, rendimiento, segmentación y trazabilidad.

El direccionamiento debe coordinar sedes y centros para evitar solapamientos, especialmente en VPN, integraciones con proveedores y cloud. DNS interno debe publicar nombres estables sin exponer innecesariamente detalles. Los cambios de IP deben ocultarse tras nombres cuando sea posible, pero deben gestionarse TTL, certificados, listas de acceso y dependencias que todavía utilicen direcciones.

Los servicios no deben depender de resolutores públicos para zonas internas. Los clientes remotos deben recibir mediante la VPN rutas, DNS y sufijos apropiados. El split DNS puede devolver respuestas diferentes según el origen, pero requiere gobierno para evitar inconsistencias. Las direcciones y nombres de producción no deben incorporarse sin control a documentación pública.

17.2. Segmentación y mínimo privilegio

La segmentación separa puestos, servidores, dispositivos médicos, administración, invitados y gestión. Los routers, firewalls y controles de acceso aplican flujos autorizados. Una VLAN no es por sí sola una barrera de seguridad; necesita routing y política. Las ACL basadas solo en IP son insuficientes para identidad, pero siguen siendo útiles como una capa adicional.

Los servicios de infraestructura como DNS, DHCP, NTP y routing deben protegerse porque su compromiso puede redirigir o interrumpir múltiples aplicaciones. La administración debe realizarse desde redes de gestión, con autenticación fuerte, registro y copias. Los protocolos inseguros deben retirarse o encapsularse de forma controlada.

17.3. Disponibilidad y continuidad

La continuidad exige redundancia real de rutas, DNS, resolutores, enlaces y equipos. Dos servidores en el mismo dominio de fallo no ofrecen independencia. Deben probarse pérdida de un enlace, fallo de un resolutor, retirada de una ruta y caducidad de un certificado. Las pruebas deben medir tiempo de convergencia y efecto sobre sesiones.

La monitorización debe observar latencia, pérdida, errores, utilización, cambios de tabla, vecinos, consultas DNS, expiración de dominios y certificados. Las alertas deben correlacionarse con cambios planificados. El exceso de datos sin contexto no mejora la disponibilidad; se necesitan umbrales, líneas base y procedimientos.

17.4. Seguridad

Las amenazas incluyen suplantación, envenenamiento ARP, anuncios de router falsos, secuestro DNS, rutas erróneas, escaneo, denegación, exposición de puertos y credenciales débiles. La defensa es multicapa: NAC, segmentación, DHCP snooping, protección de ARP/NDP, firewalls, DNSSEC, MFA, cifrado, filtrado de rutas, RPKI en contextos BGP, parcheado y respuesta a incidentes.

El cifrado de aplicación protege extremo a extremo mejor que confiar únicamente en una VPN. La VPN reduce exposición y protege el tránsito, pero un usuario autorizado puede seguir accediendo indebidamente si la autorización es deficiente. La identidad debe acompañar a la conectividad.

17.5. Ideas clave

• TCP/IP agrupa cuatro capas y no se corresponde uno a uno con OSI.
• IPv4 usa 32 bits; IPv6 usa 128 bits y no tiene broadcast.
• El prefijo determina red; CIDR sustituye el diseño por clases.
• El host consulta rutas antes de resolver el vecino del siguiente salto.
• TCP aporta flujo fiable; UDP aporta datagramas con baja sobrecarga.
• DNS es jerárquico y distribuido; A resuelve IPv4 y AAAA IPv6.
• DNS utiliza UDP y TCP 53; AXFR utiliza TCP.
• Red.es es la autoridad del registro .es.
• El routing elige el prefijo más largo.
• RIP usa saltos, OSPF estado de enlace y BGP política.