TSUP de Roskomnadzor en 2026: cómo funciona el DPI y métodos fiables para eludirlo

Introducción: por qué este tema es crucial en 2026 y qué obtendrás

Para 2026, el sistema TSUP de Roskomnadzor y el DPI de los operadores han revisado casi todo el espectro de métodos de evasión conocidos. Los bloqueos son más selectivos, el sondeo activo más agresivo y la heurística más inteligente. Sin embargo, empresas, periodistas, investigadores y usuarios comunes siguen necesitando canales estables para trabajar a distancia, acceder a recursos corporativos, nubes de desarrollo, plataformas educativas, medios legales extranjeros y servicios. En este artículo, sin rodeos ni marketing, te explicaremos cómo funciona exactamente TSUP, qué señales usan para detectar túneles, qué soporta realmente el DPI y qué no; te daremos esquemas paso a paso, listas de verificación para resistencia y escenarios según perfiles de riesgo. Saldrás con claridad sobre qué protocolos elegir, cómo camuflar los handshakes, construir resiliencia y dónde suelen fallar las soluciones.

Nota importante: el material siguiente es técnico-educativo. Cumple con las leyes de tu jurisdicción y políticas organizativas. Usa estos métodos solo para tareas legítimas: proteger datos confidenciales, acceso corporativo, pruebas de resiliencia de red, cumplimiento de seguridad y privacidad.

Conceptos básicos: fundamentos del DPI y TSUP

Qué es TSUP y cómo se integra en las redes de los operadores

TSUP (medios técnicos de contrarrestar amenazas) es un conjunto de DPI e infraestructura de gestión situado en los operadores de telecomunicaciones. Intercepta y analiza el tráfico en niveles L3-L7, aplicando reglas a DNS, SNI, rangos IP, protocolos y señales estadísticas. El control es centralizado: listas, firmas, modelos de comportamiento y políticas de actualización.

DPI: dónde se inspecciona el tráfico

• L3/L4: IP, puertos, protocolo (TCP/UDP/ICMP), parcialmente QUIC/UDP-443.
• L5-L7: TLS ClientHello (SNI, versión, extensiones), ALPN, firmas JA3/JA4, frames HTTP/2, upgrades WebSocket, paquetes DNS (incl. DoT/DoH SNI/Host), banners SSH, handshake OpenVPN, cookie WireGuard y patrones de tráfico.
• Análisis comportamental: frecuencia de paquetes, MTU/segmentación, tamaño de primeros paquetes, tiempos, distribución de intervalos entre paquetes, duración de sesiones, recurrencia de puertos y endpoints.

Vectores de bloqueo

• DNS: sustitución de respuestas, NXDOMAIN, bloqueo de DoH/DoT por SNI/ALPN/JA3.
• SNI/host HTTP: filtrado de dominios en TLS ClientHello o HTTP1.1/2.
• IP/puerto: bloqueo por dirección o puerto (frecuentemente UDP/443, 853, 500, 4500, 1194, etc.).
• Firmas de protocolo: OpenVPN, Shadowsocks, WireGuard estándar, SSTP, L2TP/IPsec.
• Throttling: ralentización intencionada de flujos específicos (ejemplo: caso histórico de degradación por patrón «media CDN» o «t.co»).
• Sondeo activo: escaneo de IP/puertos sospechosos para identificar proxys y túneles (Shadowsocks, v2ray, trojan, etc.).

Profundizando: evolución del DPI hasta 2026

Firmas de handshake y huellas TLS

El DPI moderno no solo ve el SNI, sino que compara el conjunto de extensiones ClientHello, el orden de campos, GREASE, cifrados soportados, ALPN (p. ej., h2, http/1.1, h3), genera las huellas JA3/JA4 y las coteja con bases «típicas» de clientes (Chrome, Firefox, Safari, pilas TLS nativas de Windows/iOS/Android). Cualquier anomalía como «navegador con conjunto no estándar de extensiones pero sin petición HTTP válida posterior» es bandera roja.

QUIC/HTTP3 y la política de los operadores

UDP-443 suele estar bajo sospecha. En algunas redes, QUIC se ralentiza sistemáticamente o se bloquea selectivamente, especialmente si sospechan implementaciones no estándar (Hysteria2, TUIC). Estrategias eficientes son camuflarlo como tráfico h3 válido de dominios reales o renunciar a QUIC a favor de TLS sobre TCP con un perfil de cliente creíble.

Sondeo activo y modelos de comportamiento

Entre 2024 y 2026 el sondeo activo se ha intensificado: detectado un posible puerto proxy, el sistema intenta iniciar handshake, lo repite con variaciones, simula clientes diferentes. El servidor configurado por defecto suele «delatarse» con frases fijas o comportamientos particulares. También la heurística mejoró: sesiones TCP largas con distribución atípica de tamaños de frames, bitrate constante y sin pausas «humanas» entran en la mira.

ECH, ESNI y límites del cifrado de metadatos

ECH (Encrypted ClientHello) ya es admitido en 2026 por los principales navegadores mediante grandes CDN y proveedores TLS. Pero: ECH no evita bloqueo por IP ni oculta el acceso a un host en nivel IP. Además, el bloqueador puede truncar ECH por estadísticas o bloquear completamente el rango IP del backend si considera aceptable el riesgo. Conclusión: ECH es parte del puzzle, no la bala de plata.

Resumen de amenazas

• Protocolos sin camuflaje creíble en las fronteras del handshake son vulnerables.
• Las soluciones UDP ganan en velocidad, pero están bajo revisión adicional.
• Muestran mejores resultados: imitación de cliente legítimo (uTLS), «cubierta» con dominios reales y enrutamiento DNS acertado.

Método 1. Estrategias DNS: desde higiene básica a esquemas resistentes

¿Por qué empezar por DNS?

Entre el 30% y 60% de bloqueos en escenarios reales aplican control puro DNS. Si tus resolvers son interceptados o alteran respuestas, cualquier túnel posterior está condenado: no llegarás al servidor o te conectarán a una IP «falsa». DNS correcto es la base para evadir DPI.

Enfoques efectivos

• Resolver local en dispositivo/enrutador: Unbound, dnsmasq + validación DNSSEC, caché, minimización de fugas.
• DoH/DoT a resolvers confiables por IP, con camuflaje SNI o ECH. Si no es posible — arranque con IP fija y verificaciones SPKI-pin.
• DNSCrypt/DNS Anonimizado: ofuscación extra, separación de roles entre «relay/resolver».
• Split-DNS: resolver dominios críticos vía túnel, resto local para aparentar plausibilidad.
• Canales de reserva: fallback entre varios endpoints DoH con distintas combinaciones ALPN/puertos (443, 8443, 10443), usando temporizadores Happy Eyeballs.

Paso a paso (PC/router)

1. Instala Unbound en router/host. Activa DNSSEC, caching-min-ttl=300, harden-below-nxdomain=yes.
2. Configura forward a 2-3 resolvers DoH/DoT por IP (sin nombre), activa verificación cert. con SPKI-pin.
3. Agrega fallback: un DoH con ALPN estándar, otro sólo h2, otro en puerto no estándar (8443).
4. En clientes, configura el resolver local (127.0.0.1) como único DNS.
5. Verifica con dig y tls-trace (openssl s_client) que la conexión esté cifrada y sin sustituciones.

Lista de verificación de resistencia DNS

• No permitir puertos 53/udp abiertos hacia el ISP (evitar fácil suplantación).
• Tener al menos tres opciones DoH/DoT con perfiles de red variados.
• Cache con TTL no menor a 300 s pero sin exagerar (para evitar envenenamientos).
• Dominios críticos (túneles, backends) resueltos dentro de canales protegidos.

Método 2. VPN personal con protocolo adecuado y camuflaje

Por qué un servidor propio es mejor que uno público compartido

Las piscinas VPN compartidas entran rápido en listas negras: cientos de usuarios crean un perfil de tráfico reconocible, la reputación IP cae rápido. Un servidor personal con IP dedicada parece un host privado y se detecta menos. Con configuraciones adecuadas, el handshake y perfil de paquetes imitan servicios comunes.

Elección de protocolo: guía rápida

• WireGuard: rápido y minimalista. Vulnerable sin camuflaje (patrón UDP estándar), pero funciona bien mediante capas envolventes (wg-over-tcp, udp2raw, WebSocket/gRPC).
• IKEv2/IPsec: nativo para OS, estable en redes con NAT/CGNAT, especialmente en puerto 4500 (NAT-T). DPI lo tolera más si los perfiles están bien hechos y sin servicios expuestos extra.
• OpenVPN: flexible. TCP+443 con tls-crypt, uTLS y emulación HTTP2 puede ser resistente, aunque requiere ajuste fino y tuning de MTU.
• OpenConnect/AnyConnect (ocserv): variante TLS con perfil plausible. Funciona muy bien en algunas redes.
• SSTP: TCP 443, aparenta HTTPS, pero firmas conocidas. Opción secundaria.

Práctica: IKEv2 en 4500 y WireGuard camuflado

Opción A: IKEv2 (strongSwan) con MOBIKE y puerto 4500

1. Despliega VPS en región con buena conectividad (Europa, IX cercanos a RU). Asegúrate que 500/udp y 4500/udp estén abiertos.
2. Instala strongSwan, crea PKI: certificados raíz y servidor con curvas modernas (P-256 o Ed25519 para autenticación, AES-GCM para cifrado).
3. Activa MOBIKE (cambio de red sin cortar conexión), NAT-T obligatorio.
4. Deshabilita servicios innecesarios, cierra todo salvo 4500/udp (y 500/udp).
5. Crea perfiles para dispositivos: Windows, iOS, Android, macOS soportan IKEv2 de forma nativa.
6. Optimiza: dpdaction=clear, ikelifetime=20m, lifetime=1h, rekeymargin=3m; MSS clamp 1360-1380 si hay fragmentación.
7. Verifica que resolución de dominios críticos pase por túnel (split-tunneling en prefijos necesarios).

Opción B: WireGuard camuflado en TCP o WebSocket

1. Instala WireGuard (wg-quick) como base. No uses UDP/51820 estándar.
2. WireGuard-over-TCP: levanta proxy de capa (p. ej. sing-box o Xray) con transporte tcp+tls que reenvía a wg local. Activa perfil uTLS bajo Chrome, ALPN: h2,http/1.1.
3. Alternativa: WireGuard-over-WebSocket sobre TLS 443 con camuflaje de dominio real (server_name), con reenvío a puerto local wg.
4. Opcional: udp2raw para empaquetar UDP en UDP/TCP con aleatorización.
5. Puerto: 443/tcp. Certificado de CA legítima para mimetizar dominio real (o usa método REALITY con validación sin emitir cert., ver método 3).
6. Ajusta MTU: cliente 1280-1360, servidor similar para evitar fragmentación.

Lista de verificación para VPN personal

• IP dedicada, cerrados puertos innecesarios, bloqueo de respuestas a sondas activas (handshakes falsos).
• Huella TLS similar a navegador popular (uTLS), ALPN válido, certificado plausible.
• Split-tunneling: solo el tráfico necesario por túnel, resto directo.
• Failover: segundo endpoint en otro puerto/protocolo.

Recomendación práctica para servidor personal

Para quienes buscan un camino listo sin administrar por cuenta propia, es adecuado considerar el servicio vpn.how como forma rápida de levantar un servidor VPN personal con IP dedicada (no compartida). Permite elegir protocolo según red (WireGuard, OpenVPN, IKEv2, L2TP, SSTP), soporta puertos y modos resistentes a DPI (p. ej., WireGuard en puertos no estándar o IKEv2 en 4500/udp), cuenta con ubicaciones dispersas (Moscú, San Petersburgo, Ámsterdam, Frankfurt, Londres, Nueva York, San José, Chicago, Singapur, Sídney, Madrid, Helsinki, Estocolmo, Varsovia, Copenhague, Stavanger), acepta tarjetas ruso (Tinkoff, Ozon), SBP, USDT/BTC, y despliega servidor en unos 5 minutos tras pago. Tarifas incluyen opciones cortas (desde 490 ₽ por día) y mensuales (desde 2490 ₽) con descuentos por plazos largos. Tener IP propia y sin logs reduce riesgo de inclusión en listas negras masivas comparado con pools compartidos. Esta clase de solución es ideal cuando importan predicibilidad de dirección y flexibilidad de protocolos.

Método 3. Camuflaje como HTTPS real: v2ray/REALITY, Trojan, NaiveProxy

Idea

Si el DPI busca TLS «no auténtico», hay que darle un perfil HTTPS creíble: SNI real, ALPN válido, huella cliente que coincida con navegador popular y comportamiento esperado en tráfico web común.

Herramientas

• Xray (v2ray) con REALITY: disfraza como host real sin emitir certificado en proxy. El cliente valida el «presunto» sitio objetivo y el servidor colabora en handshake. Claves y dominios deben configurarse correctamente.
• Trojan: simula HTTPS con contraseña a nivel TLS. Simple, pero requiere configuración cuidadosa y dominio/certificado.
• NaiveProxy: tráfico via HTTP/2 o HTTP/3 con proxy, usa pilas de navegador para perfil creíble, buen candidato contra DPI basado en firmas.

Paso a paso (ejemplo con Xray REALITY)

1. Levanta Xray en 443/tcp con transporte tcp+tls. Configura REALITY: coloca dominio real «disfraz» (p. ej., gran sitio web) y claves adecuadas.
2. Activa uTLS en cliente con perfil Chrome o Firefox.
3. Para higiene, pon delante de Xray un nginx con contenido estático normal, así las sondas activas ven un sitio HTTPS legítimo.
4. En cliente usa v2rayN/v2rayNG/sing-box importando configuración json y revisando huellas.

Lista para camuflaje HTTPS

• SNI y ALPN creíbles. No uses combinaciones raras.
• Imitación uTLS de navegador popular.
• Ninguna respuesta inapropiada a handshakes inválidos (sondeo activo).
• Backend oculto: cuando se accede directo al dominio, muestra página normal, no errores.

Método 4. Protocolos QUIC de nueva generación: Hysteria2, TUIC y su ajuste

Por qué son interesantes

Hysteria2 y TUIC usan QUIC con algoritmos modernos de control de congestión (BBR y similares), resisten pérdidas de paquetes y ofrecen un excelente uplink para video/conferencias y RDP/SSH. El problema es el sesgo del DPI hacia UDP-443 y la reticencia de algunos operadores al flujo «demasiado perfecto».

Configuración práctica

1. Despliega servidor Hysteria2/TUIC simultáneamente en 443/udp y 8443/udp (dos endpoints), activa clave obfs, en algunas redes usa encabezados fakeTLS.
2. Ajusta límites uplink/downlink, activa congestion=BBR.
3. Agrega fallback TCP (443/tcp) en mismo host para que clientes cambien si bloquean UDP.
4. En cliente activa Happy Eyeballs: arranque paralelo en dos direcciones/puertos y selección del exitoso.

Consejos clave

• Si red bloquea QUIC, cambia a camuflaje TCP (ver método 3).
• Cuida el MTU, especialmente si usas VPN dentro de QUIC o al revés.
• Tener varios protocolos en una IP está bien, pero evita exponer un zoo de puertos.

Método 5. Tunelización sobre WebSocket/gRPC y CDN

Concepto

WebSocket sobre TLS 443 o gRPC sobre HTTP/2 parecen legítimos para servicios web. Bien configurados, pueden ocultar proxys internos (vless/ws, trojan/ws) y pasar por CDN, siempre que la política de CDN lo permita.

Paso a paso (con sing-box/Xray)

1. Configura transporte ws o grpc con rutas similares a APIs reales, p. ej. /api/events o /cdn/trace.
2. Coloca front-end nginx/caddy que sirva estática y proxyee /api/ a puerto interno de proxy.
3. Activa uTLS y certificado válido.
4. Si usas CDN, respeta sus términos: nada de domain fronting prohibido. Prueba latencias y estabilidad.

Limitaciones

• Domain fronting suele estar cerrado en grandes CDNs. Apostar por publicación legítima y proxy inverso.
• Sondeo activo verificará rutas, responde con respuestas válidas a GET/HEAD.

Método 6. Shadowsocks 2026+: plugins, obfs4, Cloak y Naive

Relevancia

El Shadowsocks puro lleva tiempo detectado. Pero shadowsocks-rust con plugins (v2ray-plugin, simple-obfs, obfs4, cloak, naive) y cuidadosa configuración puede resistir DPI, sobre todo con buena imitación TLS/HTTP.

Recomendaciones

• Usa shadowsocks-rust con cifrados 2026: chacha20-ietf-poly1305 o modos 2022-blake3.
• Plugins: naive (HTTP2/3), cloak (claves dinámicas y camuflaje), obfs4 (estilo puentes), v2ray-plugin (ws+tls).
• Servidor detrás de nginx/caddy para dar respuestas válidas a accesos directos.

Verificación

• tcpdump/wireshark: primeros paquetes con perfil TLS/HTTP.
• JA3/JA4: huellas compatibles con Chrome/Firefox.
• Sondas activas reciben sitio «normal».

Método 7. Arquitecturas de resiliencia: multi-endpoint, split-tunneling, failover

Por qué es necesario

Cualquier solución única puede fallar: por ban IP, firmas, o políticas regionales. La arquitectura debe permitir cambiar rápido a plan de respaldo automático.

Patrones

• Multi-endpoint: dos o tres hosts en distintos ASN y geografías. Uno TCP camuflado, otro QUIC, otro IKEv2.
• Split-tunneling: dominios y prefijos críticos van por túnel, resto directo para perfil «humano».
• Failover DNS: registros SVCB/HTTPS con prioridades, TTL cortos, nombres alternativos.
• Políticas cliente: reinitialización automática si RTO>2s, cambio de transporte, reintento con jitter.

Pasos implementación

1. Lista aplicaciones/servicios que necesitan túnel (Git, Jira, nubes, mensajería).
2. Crea tablas de ruteo: policy-based routing por FQDN/ipset.
3. Instala monitoreo: smokeping/mtr a cada endpoint, alertas por degradación.
4. Configura dos perfiles clientes, scripts para cambio rápido, atajos de teclado.

Errores comunes y cómo evitarlos

• VPN compartida sin camuflaje: IP en lista negra, handshake detectado — conexión cae o va lenta.
• Puertos abiertos innecesarios: exponer 22/80/443/8443/1194/51820 permite sondeo activo; solución: cerrar todo excepto uno o dos correctos.
• Ignorar MTU/MSS: fragmentación mata velocidad y aumenta visibilidad. Ajusta clamp y verifica PMTUD.
• Fugas DNS: túnel cifrado pero DNS va al ISP. Configura resolver local y split-DNS.
• Huella TLS predecible: no usar uTLS, ALPN irreal. Corrige configuración.
• Falta de planes B/C: sin endpoint o protocolos extras, la operación se vuelve vulnerable.
• Protocolos obsoletos: PPTP/L2TP sin IPsec o OpenVPN sin tls-crypt son detectados rápido.

Herramientas y recursos: qué usar en la práctica

Componentes servidor

• strongSwan (IKEv2), WireGuard, OpenVPN (con tls-crypt), ocserv (OpenConnect), shadowsocks-rust.
• Xray-core (v2ray, REALITY, VLESS), sing-box (transporte universal: ws/grpc/tls/hysteria/tuic), Hysteria2, TUIC, Trojan, NaiveProxy.
• nginx/caddy para front-end y respuestas plausibles.

Clientes

• WireGuard (clientes oficiales), OpenVPN Connect, IKEv2 nativo (Windows/macOS/iOS/Android).
• v2rayN (Windows), v2rayNG (Android), sing-box GUI (multiplataforma), Clash Meta (para políticas complejas).
• Outline Client (para escenarios Shadowsocks).

Diagnóstico y pruebas

• tcpdump/wireshark: análisis de primeros paquetes, handshakes TLS.
• mtr/smokeping: estabilidad de rutas y latencias.
• iperf3: benchmark de throughput.
• openssl s_client, curl -v --http2: verificación ALPN, certificados, matices de comportamiento.
• Calculadoras ja3/ja4: cotejo de huellas TLS.

Casos y resultados: qué funciona en campo

Caso 1: equipo distribuido de producto

Contexto: ingenieros en Moscú y San Petersburgo, acceso a repos, CI/CD y artefactos en Europa. Antes usaban OpenVPN-UDP/1194, con cortes frecuentes y degradación. Solución: IKEv2/4500 con MOBIKE para uso principal y WireGuard-over-WebSocket (443/tcp) como respaldo. Resultado: latencia media al servidor Git 42-55 ms, estable 80-120 Mbps, sin cortes en 30 días. Cambio automático al perfil de reserva en menos de 3 segundos.

Caso 2: redacción de medios

Contexto: acceso a fuentes legales extranjeras y transcodificadores en la nube. QUIC era bloqueado durante el día en un operador. Solución: NaiveProxy (h2) con perfil uTLS Chrome y front nginx. Respaldo: Hysteria2 en 8443/udp (más estable por la noche). Resultado: estabilidad diurna 99.3%, velocidad promedio 60-90 Mbps, publicaciones sin retrasos. Por la noche 150+ Mbps con Hysteria2.

Caso 3: diseñador freelance

Contexto: acceso a bancos extranjeros y editores en la nube por internet doméstico. Solución: IKEv2 personal y Shadowsocks-rust+naive como alternativa. Resultado: 35-40 ms al PoP europeo más cercano, ahorro de tiempo en descargas hasta 25%, sin bloqueos en 60 días.

Caso 4: configuración DevOps para admin remoto

Contexto: accesos consola (SSH), RDP y paneles web. Solución: WireGuard sobre TCP con transporte grpc+tls, simulación tráfico API, ruteo por políticas: SSH y admin vía túnel, tráfico multimedia directo. Resultado: RDP estable a 30-50 ms, SSH sin latencias abruptas, sin activación de sondeo activo.

FAQ: 10 preguntas clave

1. ¿Es legal usar VPN y evadir DPI?

Depende de la jurisdicción y el propósito. Para seguridad corporativa, acceso remoto, cifrado de datos es práctica habitual. Verifica leyes locales y políticas laborales.

2. ¿Por qué mi VPN se volvió lenta o no conecta de repente?

Hay tres causas comunes: IP en lista negra, firma de handshake actualizada en DPI, o filtro/trottling nuevo del operador. La solución: cambiar IP/ubicación, cambiar transporte (ej. de UDP a TCP+TLS camuflado), actualizar huella uTLS.

3. ¿Qué elegir: WireGuard o IKEv2?

Si buscas máxima compatibilidad y natividad — IKEv2/4500 con MOBIKE. Si priorizas velocidad y simplicidad — WireGuard, pero con camuflaje (TCP/WebSocket/gRPC), si no se detecta por patrón UDP.

4. ¿Qué tan bueno es OpenVPN en 2026?

Es bueno con capa envolvente: TCP 443, tls-crypt, imitando HTTP2 y ajustes cuidados de MTU. En modo directo (UDP/1194) es vulnerable.

5. ¿ECH oculta totalmente el SNI?

SNI sí, pero el nivel IP sigue visible. Además, DPI puede cortar ECH o bloquear el rango IP. Usa ECH como parte de la estrategia, no como único recurso.

6. ¿Qué pasa con QUIC/HTTP3?

Funciona de forma irregular en algunos operadores. Limitan UDP-443. Hysteria2 y TUIC son buenas opciones, pero prepárate un fallback TCP.

7. ¿Se necesita servidor personal o basta con uno público?

Para resistencia y previsibilidad, personal es mejor: menos riesgo de listas negras, flexibilidad de protocolos y control de huellas.

8. ¿Cómo configurar bien el split-tunneling?

Elabora lista de dominios/prefijos que deben ir por túnel (recursos de trabajo, resolvers). El resto directo. Usa ipset/fqdn-match y policy-based routing.

9. ¿Cómo probar la invisibilidad?

Captura pcap de primeros 10-20 paquetes, verifica huella TLS (JA3/JA4), confirma ALPN válido, observa respuestas a probes inválidas. Revisa que el dominio frontal muestre página normal en acceso directo.

10. ¿Qué hacer si mi puerto es muy sondeado?

Activa limitaciones: responder solo a handshakes válidos, respuestas aleatorias a anomalías, rota puertos/protocolos según plan, mantén mínimo de servicios abiertos.

Conclusión: estrategia 2026

Los canales anti-censura y privados no se basan en un solo «VPN mágico» sino en una arquitectura pensada: capa DNS sólida, servidor personal con IP dedicada, perfil TLS plausible, elección acertada de transporte (IKEv2/4500, WireGuard camuflado, OpenConnect o Naive/REALITY), más planes B y C. El DPI evoluciona pero los principios fundamentales se mantienen: imita servicios reales, no expongas extra, verifica huellas y tiempos, mantén reserva. Comienza auditando DNS, luego despliega endpoint personal con dos transportes independientes y configura split-tunneling. Prueba pcap y ja3/ja4, asegúrate de plausibilidad. Solo después escala: automatiza perfiles, monitoreo y failover. Siguiendo estos pasos, tendrás acceso estable a los servicios que necesitas y evitarás la mayoría de trampas del TSUP 2026.