BIBLIOTECA ASTRACode Cyber

CAPÍTULO 35 · PARTE III

Proxies, VPN, túneles y redes superpuestas

Distinguir intermediarios de aplicación, terminación y túneles; modelar VPN de acceso y site-to-site mediante rutas, DNS, identidad y autorización; y diagnosticar overlays, MTU y PMTU sin convertir la conectividad en confianza.

Nivel N2–N3 · Estado published

La misma petición puede atravesar varias fronteras

Cuando una persona dice «la VPN funciona, pero la aplicación no», todavía no ha identificado un fallo. Puede existir una ruta hasta el gateway pero no hasta el servicio; el túnel puede transportar sólo algunos prefijos; el resolver DNS puede seguir fuera de la política; un reverse proxy puede terminar una conexión y abrir otra; un paquete grande puede exceder la MTU efectiva; o el servicio puede recibir la petición y denegarla por autorización. Una etiqueta como proxy, VPN o red privada no sustituye la reconstrucción del flujo.

Este capítulo estudia esas fronteras. Un proxy es un intermediario que recibe tráfico de un lado y puede reenviarlo, transformarlo, responder o almacenarlo. Un túnel transporta una unidad interna dentro de una representación exterior entre endpoints del túnel. Una VPN es una arquitectura de conectividad y protección de ciertos flujos, no una propiedad global de confianza. Una red superpuesta (overlay) ofrece una topología lógica sobre un underlay que aporta el transporte exterior.

La pregunta profesional es siempre compuesta: ¿qué unidad se observa?, ¿qué conexión termina?, ¿qué rutas y resolutores se aplican?, ¿qué identidad se autenticó?, ¿qué decisión de autorización ocurrió?, ¿qué tamaño puede atravesar el camino? Las respuestas cambian según el punto de observación y la configuración.

Caso conductor: Northstar fuera de la oficina

Northstar mantiene una API de facturación en api.int.northstar.test. Elena trabaja desde un portátil administrado. El agente del equipo usa una VPN de acceso hasta vpn.northstar.test; el gateway asigna una dirección de cliente y anuncia rutas para 10.40.0.0/16. La API está detrás de un reverse proxy que termina TLS del cliente y abre otra sesión TLS hacia el origin. Para salir a internet, el portátil usa un forward proxy corporativo. Dos centros de datos extienden una red de máquinas virtuales mediante un overlay VXLAN sobre un underlay IP; la API vive en ese overlay.

El equipo formula cuatro afirmaciones:

  1. «Como Elena está en la VPN, la API ve a Elena». El gateway puede autenticar un dispositivo o una credencial de acceso; el origin ve, en primera instancia, al reverse proxy. La aplicación necesita su propia sesión, mapeo de principal y autorización.
  2. «Como la VPN está arriba, todo el tráfico está protegido». Sólo están cubiertos los prefijos y protocolos que la política y la tabla de rutas seleccionan. Una ruta más específica, una exclusión o un fallo de DNS puede enviar tráfico por fuera.
  3. «Como el overlay funciona, los hosts están aislados». El VNI separa un segmento lógico según la configuración; no reemplaza ACL, control de acceso, autenticación ni una comprobación del underlay.
  4. «Los paquetes pequeños pasan, así que la red está sana». La encapsulación reduce la MTU. Un flujo pequeño puede funcionar mientras una respuesta grande tropieza con PMTUD, fragmentación o ICMP bloqueado.

La investigación seguirá una petición sintética de Elena y separará cada claim en observación, inferencia, impacto posible y evidencia pendiente.

Proxy, gateway y terminación no son sinónimos

Comparación de proxy que termina legs separados frente a CONNECT, que transporta un túnel TLS extremo a extremo sin plaintext en el proxy.
Proxy: terminación o CONNECT

La visibilidad y la identidad se determinan por leg; CONNECT no implica terminación.

RFC 9110 describe a un intermediary como un componente que puede recibir una petición, actuar sobre ella y reenviarla; el intermediario puede tener varias conexiones y generar un response local. RFC 9110, §3.7 En el lenguaje operativo, forward proxy y reverse proxy describen dónde se coloca el intermediario respecto del cliente y del origin, no dos protocolos incompatibles.

Un forward proxy es elegido o configurado por el cliente para alcanzar destinos externos. El cliente puede enviarle un request HTTP en la forma esperada por el proxy, o pedirle un túnel con CONNECT. El proxy aplica una política de egress, registra al principal que conoce, resuelve el destino según su configuración y abre una conexión posterior. El origin no debe asumir que la dirección del socket es la dirección del cliente. Tampoco debe asumir que el proxy vio el contenido de aplicación: con CONNECT, puede transportar bytes de una conexión posterior sin terminar su TLS. RFC 9110, §9.3.6

Un reverse proxy publica un servicio para clientes y protege o compone uno o más origins. Puede terminar TLS, aplicar límites, autenticar un certificado de cliente, seleccionar un backend, traducir HTTP/2 a HTTP/1.1 o responder desde caché. Si termina TLS, la sesión del cliente y la del origin son legs distintos. Un certificado o cookie que el edge validó no se convierte por arte de magia en la identidad que el origin debe autorizar. Si el edge re-cifra hacia el origin, el origin autentica al edge en ese leg; hace falta un contrato de propagación para cualquier identidad de usuario.

Gateway es un término funcional más amplio. Puede enrutar entre protocolos o dominios de confianza, no sólo reenviar HTTP. Un API gateway puede terminar TLS y emitir otra petición HTTP; un gateway de VPN puede terminar un protocolo de túnel y entregar paquetes a una interfaz virtual. «Gateway» describe una función de frontera, no garantiza inspección, cifrado, autenticación o autorización.

Terminar significa ser un extremo de una conexión o asociación concreta. Terminar un túnel IPsec no implica terminar TLS dentro del paquete; terminar un proxy HTTP no implica descifrar una sesión transportada por CONNECT; terminar TLS del cliente no autentica automáticamente al usuario frente al origin. Antes de afirmar «el proxy ve plaintext», hay que nombrar el leg, el protocolo y el material de claves o parser que sustentan la observación.

Qué se conserva entre legs

Un intermediario puede conservar semántica y reconstruir bytes distintos. El método HTTP, el target y el resultado pueden correlacionarse mediante un request-id, pero no se debe afirmar que la misma conexión, el mismo orden de bytes o los mismos campos viajaron sin transformación. Una cabecera como X-Client-Identity sólo es útil si el componente elimina valores suministrados por el cliente, crea uno tras autenticar y el origin confía en la procedencia del canal que lo transporta. La cabecera no es una credencial por su nombre.

En Northstar, la evidencia correcta es una secuencia: handshake cliente–reverse proxy; decisión de terminación; handshake reverse proxy–origin; request-id en ambos logs; principal que cada componente conoce; decisión de autorización en el origin; y respuesta en sentido inverso. Un log del edge no prueba que el origin haya aceptado el mismo principal ni que haya creado el efecto de negocio.

Túnel, encapsulación, underlay y overlay

Paquete interior completo encapsulado con H_tunnel, outer IP/UDP/GRE, tránsito underlay y decapsulación; incluye límite de MTU y ausencia de cifrado propio en GRE/VXLAN.
Encapsulación y MTU

El overhead se suma una vez por leg: L_inner + H_tunnel debe caber en la MTU del underlay.

Un túnel crea un canal lógico entre dos endpoints. El endpoint de entrada toma una unidad interna y añade una cabecera o envoltura exterior; routers del underlay encaminan esa representación exterior; el endpoint de salida valida, desencapsula y entrega la unidad interna al overlay. El router del underlay no necesita comprender la dirección interna para encaminar el paquete exterior. Esta separación explica por qué una captura exterior puede mostrar dos IP de endpoints del túnel mientras el flujo interno usa otras direcciones.

Encapsulación es la transformación concreta; underlay es la red que transporta la envoltura; overlay es la topología lógica que se obtiene al entregar la unidad interna. Ninguno de esos términos implica cifrado. La protección —confidencialidad, integridad o autenticación— depende del protocolo y de su política.

GRE ilustra la distinción. RFC 2784 define una cabecera para encapsular un protocolo de carga; RFC 2890 añade extensiones opcionales de key y sequence number. RFC 2784, §§2–3 RFC 2890, §§2–3 Esas extensiones pueden ayudar a identificar o ordenar una carga según el despliegue, pero GRE no aporta por sí solo confidencialidad ni autenticación criptográfica. Si Northstar necesita esas propiedades, debe componer GRE con un mecanismo que las defina y verificar la política resultante.

VXLAN ilustra una red superpuesta de otra clase: encapsula una trama Ethernet dentro de UDP/IP y usa un VNI para distinguir segmentos lógicos sobre un underlay IP. RFC 7348, §§3–5 El VNI ayuda a seleccionar el dominio de overlay; no decide qué usuario puede hablar con qué servicio, no prueba aislamiento administrativo y no cifra la trama. Los VTEP son endpoints de esa encapsulación. La salud de las IP exteriores no demuestra que la tabla MAC/ARP/ND, el VNI, la MTU o las ACL del overlay sean correctos.

La diferencia con un proxy es semántica. Un túnel puede transportar una unidad interna para que sus extremos originales sigan siendo los extremos de TCP o TLS; un proxy de aplicación es extremo de la sesión de aplicación que termina. Hay composiciones: un reverse proxy puede llegar al origin por una VPN; una VPN puede transportar una conexión a un forward proxy; un proxy puede usar CONNECT para transportar otra sesión. El diagrama debe mostrar cada frontera en lugar de colapsarlas en una flecha «privada».

VPN de acceso y VPN site-to-site

Una VPN de acceso conecta un endpoint remoto con un gateway. El gateway puede autenticar a una persona, un dispositivo, una máquina o una combinación; puede asignar una dirección virtual, anunciar rutas, aplicar postura y registrar sesiones. La conectividad resultante permite llegar a ciertos destinos, pero no concede automáticamente permisos de aplicación. El endpoint puede ser un portátil comprometido, la credencial puede tener alcance limitado y el servicio puede requerir una autenticación diferente.

Una VPN site-to-site conecta dos gateways o dominios de red. Su política suele expresarse mediante prefijos, protocolos, puertos y endpoints de túnel. El gateway A puede proteger tráfico hacia 10.40.0.0/16 a través del gateway B sin que cada host tenga una asociación o una identidad de usuario individual. Una ruta entre sitios tampoco vuelve confiable cada servicio del sitio remoto: el servicio debe autenticar y autorizar a su propio principal.

IPsec proporciona un lenguaje normativo para este razonamiento. RFC 4301 separa la Security Policy Database (qué hacer con el tráfico), las Security Associations (cómo protegerlo) y los traffic selectors que ayudan a determinar qué tráfico queda cubierto. RFC 4301, §§3.2–3.3, 4 y 5 En modo túnel se protege una unidad IP interior dentro de otra representación IP, pero la cobertura efectiva sigue siendo la política instalada en los endpoints. «Hay una SA» no equivale a «todo el tráfico de este host está cifrado» ni a «el usuario está autorizado para esta operación».

WireGuard sirve aquí sólo como ejemplo acotado de otro túnel criptográfico. La documentación oficial separa el protocolo criptográfico de la asociación entre peers y prefijos: la página de Protocol describe el handshake y el transporte, mientras Cryptokey Routing explica cómo AllowedIPs participa en la selección y aceptación de tráfico por peer. Esa asociación no es autorización de API. El ejemplo no pretende comparar catálogos ni recomendar una implementación: sólo muestra que «peer autenticado» y «acción autorizada» son preguntas distintas.

Rutas: full tunnel, split tunnel y excepciones

Full tunnel es una política de forwarding en la que el tráfico relevante —habitualmente la ruta por defecto, con excepciones explícitas— se dirige al gateway VPN. Split tunnel dirige sólo algunos prefijos por el túnel y deja otros por la interfaz local o por otra ruta. Son descripciones de alcance, no sinónimos de «cifrado total» o «sin riesgo».

En el modelo de forwarding IPv4 de RFC 1812, la búsqueda conserva las rutas cuyo prefijo coincide con el destino y prefiere la de prefijo más largo; por eso, dentro de ese modelo, una ruta /32 candidata puede prevalecer sobre una ruta por defecto. RFC 1812, §5.2.4.3 Eso no especifica por sí solo el comportamiento completo de un host moderno: métricas, múltiples tablas, policy routing, instalación de rutas y reacción a la caída dependen del sistema, el agente y su versión. Pueden intervenir configuración del cliente, opciones de red o gestión central, pero deben comprobarse en la documentación correspondiente y en la tabla/reglas efectivas. La política puede bloquear, degradar o hacer fail open mediante otra interfaz; esa transición no se deduce de IPsec ni del rótulo «full tunnel», sino que debe probarse.

El destino también puede variar antes de que exista una conexión: DNS resuelve nombres a información que la aplicación puede usar y el forwarding posterior selecciona cómo alcanzar una dirección. RFC 1034 describe la primera función; no define qué interfaz, resolver efectivo o política de split DNS elegirá un sistema concreto. RFC 1034, §§2–4 Por ello, que el DNS path no coincida con el path de datos es una inferencia de despliegue que debe comprobarse, no una garantía del protocolo. Una VPN puede cubrir 10.40.0.0/16 y, según la configuración observada, dejar consultas al resolver del ISP; también puede enviar consultas a un resolver corporativo pero permitir que una dirección pública se alcance por la red local. La confidencialidad y política del DNS deben analizarse como flujo propio, registrando versión y configuración del agente/sistema, resolver efectivo, transporte, caché, interfaz y trust boundary.

En Northstar, una prueba útil no pregunta sólo «¿está conectada la VPN?». Para cada nombre y destino sintético se registra: respuesta DNS, servidor que respondió, interfaz elegida, ruta más específica, gateway, dirección de origen, decisión de egress y log del servicio. Un nombre interno que falla puede indicar DNS fuera del túnel, no una ruta rota; un nombre que resuelve pero conecta por Wi-Fi puede indicar split tunnel; ambos pueden coexistir.

MTU, PMTU y fragmentación

Árbol de diagnóstico con ramas independientes para ruta/policy, DNS efectivo, MTU IPv4 con fragmentation needed y MTU IPv6 con Packet Too Big.
Diagnóstico de proxy y túnel

Un timeout no identifica por sí solo MTU, ruta o DNS; hay que correlacionar observaciones.

Cada cabecera exterior consume bytes. Definamos L_inner como el tamaño del paquete IP interior completo —incluidas sus cabeceras IP y de transporte— y H_tunnel como la suma de todas las cabeceras que la encapsulación añade fuera de ese paquete, incluida la IP exterior que cruza el underlay. Para un leg sin fragmentación ni segmentación adicional debe cumplirse L_inner + H_tunnel <= MTU_underlay. Con túneles anidados, H_tunnel incorpora cada envoltura una sola vez; no se vuelven a sumar cabeceras ya incluidas en L_inner o en otra capa de H_tunnel. La MTU utilizable es el mínimo del camino y puede variar por leg y familia IP. Por eso, que un ping pequeño funcione no establece que una respuesta grande pueda cruzar.

Path MTU Discovery (PMTUD) permite que los endpoints ajusten el tamaño a partir de la menor MTU del camino. IPv4 puede usar mensajes ICMP de «fragmentation needed» para informar un límite; IPv6 usa ICMPv6 «Packet Too Big» y reserva la fragmentación para el origen con un Fragment Header. RFC 1191, §§2–4 RFC 8200, §4.5 RFC 8201, §§4–5 Si un firewall descarta esos mensajes, PMTUD puede quedar sin señal y producir un black hole: pequeños segmentos pasan, otros se pierden sin una explicación visible en el cliente.

La fragmentación no es una reparación universal. En IPv4 puede ocurrir en routers bajo reglas del protocolo; en IPv6 el router intermedio no fragmenta. El reensamblado ocurre en un endpoint definido por la familia y el paquete. Un capturador que ve un fragmento no puede inferir que la aplicación recibió la unidad completa. La fragmentación también cambia consumo de estado, filtrado, reensamblado y superficie para discrepancias entre dispositivos.

Los controles operativos incluyen anunciar una MTU interior conservadora, ajustar MSS para TCP cuando corresponda, permitir y observar ICMP/ICMPv6 necesario, medir cada leg y repetir con cargas de tamaño creciente. Un MSS clamp puede ayudar a TCP, pero no resuelve automáticamente UDP, QUIC ni todo protocolo que produzca datagramas grandes. La corrección depende de la familia IP, del túnel, de la implementación y de qué endpoint controle la fragmentación.

En Northstar, si GET /invoice pequeño funciona y la exportación grande queda en timeout, las hipótesis mínimas son: overhead del VXLAN más VPN, PMTUD roto, MSS no ajustado, fragmentos descartados, ACL de ICMP o captura en una interfaz que no ve el error. La evidencia debe incluir MTU por leg, tamaños, DF o equivalente, mensajes ICMP, reensamblado, contadores de drops y logs del origin. «El servidor no respondió» es una observación; no es todavía una causa.

Identidad y autorización antes y después de terminar

Una arquitectura de redes puede involucrar al menos cuatro identidades:

  1. Peer del túnel: endpoint que demuestra una clave o una asociación al gateway.
  2. Dispositivo o sesión de acceso: portátil, workload o credencial que recibe una configuración de VPN.
  3. Principal de aplicación: usuario, servicio o workload que TLS, HTTP o un protocolo de aplicación mapea.
  4. Sujeto autorizado para la acción: principal, recurso, acción y contexto que la política de negocio permite.

No son sustitutos. Un peer IPsec autenticado puede ser un gateway; un gateway puede aceptar un dispositivo; el reverse proxy puede autenticar un certificado del cliente; el origin puede mapear una sesión a Elena; y una política puede seguir denegando DELETE /invoices/17. Cada transición necesita una decisión y una evidencia.

La terminación cambia la pregunta «¿quién es el peer?». Antes de la terminación, un router del underlay puede observar IP exterior, puertos, tamaños y endpoints del túnel. El gateway de VPN puede validar una asociación y una política. Después, el servicio ve el paquete interior o una nueva conexión del reverse proxy. El reverse proxy puede ser el peer TLS del cliente, mientras el origin autentica al proxy. Un mTLS edge–origin prueba esa relación, no la identidad del usuario que inició la petición, salvo un protocolo de propagación verificable.

La autorización debe estar cerca del recurso y de la acción que protege. Un ACL de ruta responde «¿puede este flujo llegar a ese prefijo?». Un firewall responde «¿se permite este origen/destino/protocolo bajo esta política?». La aplicación responde «¿puede este principal ejecutar esta acción sobre este recurso en este estado?». Un resultado positivo en la primera pregunta no resuelve las dos siguientes.

Reconstruir el caso con evidencia

Para la petición de Elena, una línea temporal mínima es:

  1. El agente resuelve vpn.northstar.test y selecciona la interfaz local.
  2. El endpoint autentica al gateway y recibe la configuración de rutas, DNS y MTU.
  3. La aplicación resuelve api.int.northstar.test; se registra resolver y respuesta.
  4. La tabla elige el prefijo VPN; el paquete interior se encapsula y cruza el underlay.
  5. El gateway desencapsula y entrega al reverse proxy o al VTEP/overlay correspondiente.
  6. El reverse proxy termina la sesión cliente y crea la leg hacia el origin.
  7. El origin autentica el principal de aplicación y decide autorización.
  8. La respuesta recorre las legs inversas; cada componente registra su propia observación.

Cada evento debe conservar reloj, interfaz, dirección, identificador, versión, configuración y alcance. Una captura exterior prueba una representación exterior en ese punto. Un contador del VTEP prueba actividad del overlay sólo según la semántica de ese contador. Un log del origin prueba que su parser recibió una solicitud; no prueba que haya visto el mismo socket, certificado o ruta que el cliente.

Controles positivos, negativos y de regresión

El objetivo de estos controles no es demostrar que «la VPN protege», sino demostrar cobertura concreta: qué flujo, qué extremo, qué propiedad y qué comportamiento ante fallo.

Límites y contraejemplos

«Una VPN cifra todo». Sólo si la política encamina todo el tráfico relevante por un mecanismo criptográfico y se demuestra ausencia de bypass; full tunnel declarado no basta, y DNS, rutas alternativas, tráfico de host y excepciones pueden quedar fuera.

«Un proxy siempre ve plaintext». Un forward proxy puede usar CONNECT; un reverse proxy puede operar en passthrough; una captura exterior puede mostrar sólo ciphertext y metadata. La terminación debe probarse por claves, logs, configuración y comportamiento del leg.

«Una VPN autentica al usuario». Puede autenticar un gateway, dispositivo, certificado o credencial de acceso. Eso no reemplaza la autenticación y autorización del protocolo de aplicación ni una política por recurso.

«Site-to-site vuelve privada una red». Protege ciertos flujos entre gateways según selectores y rutas; no elimina el riesgo de hosts comprometidos, servicios expuestos, errores de ACL, DNS fuera de política o autorización ausente.

«Un overlay es aislamiento». Un VNI, una tabla virtual o una interfaz de túnel describen segmentación lógica. El aislamiento efectivo requiere límites de control, ACL, autenticación, política de forwarding y evidencia de que el underlay no permite una ruta no prevista.

«GRE es una VPN». GRE es encapsulación. Puede transportar tráfico que luego se protege con otro mecanismo, pero la cabecera GRE por sí sola no confiere confidencialidad ni autenticidad criptográfica.

«No veo ICMP, por tanto el servidor está caído». El mensaje pudo perderse, filtrarse o producirse en otro leg; la MTU, la interfaz de captura y la política determinan la observabilidad. Hay que comparar tamaños, contadores, rutas y puntos de terminación.

Transferencia: revisar una propuesta de acceso remoto

Un equipo propone que todo trabajador remoto use una VPN de acceso; que la ruta por defecto sea el túnel; que el DNS se resuelva en la sede; y que cualquier cliente con dirección virtual 10.20.8.0/24 pueda llamar a la API interna. La propuesta puede mejorar cobertura, pero deja preguntas decisivas:

Un dictamen defendible no diría «la VPN está segura». Diría, por ejemplo: «Durante la ventana y configuración observadas, el gateway autenticó el dispositivo D y seleccionó el prefijo P para la interfaz V; el resolver R recibió la consulta Q; el reverse proxy terminó TLS y el origin autorizó la operación O para el principal U. No se observó cobertura para el destino E ni se validó el comportamiento con el túnel caído o con payloads superiores a M bytes». Esa forma de escribir conserva lo que se sabe y hace visible lo que falta.

Síntesis

Un proxy es un intermediario con conexiones y políticas propias; forward y reverse nombran su posición relativa, mientras gateway nombra una función de frontera. Terminar un leg no transfiere automáticamente plaintext ni identidad al siguiente. Un túnel encapsula una unidad interna sobre un underlay y entrega un overlay; encapsulación no es cifrado. VPN de acceso y site-to-site expresan arquitecturas distintas de endpoints, rutas y políticas, pero ninguna convierte reachability en confianza o autorización. Full y split tunnel se adjudican con tabla de rutas y excepciones; DNS tiene su propio camino. La encapsulación reduce MTU y hace de PMTUD, ICMP, MSS y fragmentación parte del diseño. La evidencia correcta sigue cada leg, cada identidad y cada decisión.

Comprobación de comprensión

  1. Distingue una petición HTTP hacia un forward proxy, una sesión cliente–reverse proxy y una sesión reverse proxy–origin. ¿Qué extremo termina cada una?
  2. Explica por qué CONNECT puede transportar una sesión TLS sin que el proxy vea sus consultas de aplicación.
  3. Compara underlay, overlay, GRE y VXLAN sin atribuir cifrado o autorización a la encapsulación.
  4. Redacta la diferencia entre una VPN de acceso y una VPN site-to-site en términos de endpoints, rutas, identidad y autorización.
  5. Dada una ruta /32 fuera de la VPN y un resolver ISP, formula un claim acotado sobre full tunnel y DNS.
  6. Explica por qué un flujo pequeño puede pasar y uno grande fallar después de añadir VPN y VXLAN.
  7. Separa peer del túnel, dispositivo, principal de aplicación y sujeto autorizado para DELETE /invoices/17.
  8. Diseña un control negativo para demostrar que un VNI o una cabecera de identidad no concede acceso por sí solo.

Fuentes principales