Algunos problemas de conexi\u00f3n no son causados por la aplicaci\u00f3n que est\u00e1s utilizando. Provienen de la ruta de red entre dispositivos.<\/p>\n
Es posible que notes esto cuando una llamada se conecta instant\u00e1neamente en el Wi-Fi local pero tiene problemas en el Wi-Fi del hotel, cuando el lobby de un juego funciona para un jugador y falla para otro, o cuando una herramienta de privacidad se comporta de manera diferente despu\u00e9s de cambiar de datos m\u00f3viles a una red de oficina. Una raz\u00f3n com\u00fan es NAT: la capa de traducci\u00f3n de direcciones de red que permite que muchos dispositivos compartan una direcci\u00f3n p\u00fablica de Internet.<\/p>\n
Este art\u00edculo explica qu\u00e9 es el recorrido del NAT, por qu\u00e9 existe la perforaci\u00f3n del UDP, cu\u00e1ndo se vuelven \u00fatiles los retrocesos de los rel\u00e9s y por qu\u00e9 los lectores del VPN Satelites deben tratar estos conceptos como contexto de conexi\u00f3n en lugar de garant\u00edas m\u00e1gicas.<\/p>\n
La mayor\u00eda de la gente utiliza redes privadas sin pensar en ellas. Su computadora port\u00e1til, tel\u00e9fono, tableta y televisor pueden estar detr\u00e1s de un enrutador. Dentro de casa, cada dispositivo tiene su propia direcci\u00f3n privada. En Internet, a menudo parecen compartir una direcci\u00f3n p\u00fablica.<\/p>\n
Esa traducci\u00f3n es \u00fatil. Ayuda a las redes a conservar direcciones p\u00fablicas IPv4 y mantiene manejable el enrutamiento dom\u00e9stico normal. Pero tambi\u00e9n crea un problema pr\u00e1ctico: un dispositivo fuera de su red generalmente no puede simplemente abrir una conexi\u00f3n directa a un dispositivo dentro de su red a menos que el enrutador sepa a d\u00f3nde debe ir el tr\u00e1fico entrante.<\/p>\n
Para una navegaci\u00f3n web normal, esto suele estar bien. Su dispositivo inicia la conexi\u00f3n hacia afuera, el enrutador recuerda el mapeo y las respuestas regresan a trav\u00e9s de esa ruta temporal. Para las aplicaciones que necesitan dos puntos finales para comunicarse m\u00e1s directamente, especialmente a trav\u00e9s de UDP, la situaci\u00f3n puede ser menos predecible.<\/p>\n
Esa es la configuraci\u00f3n b\u00e1sica para el recorrido NAT.<\/p>\n
El recorrido NAT es un nombre general para las t\u00e9cnicas que ayudan a las aplicaciones a comunicarse a trav\u00e9s de redes donde uno o ambos puntos finales se encuentran detr\u00e1s de NAT.<\/p>\n
En t\u00e9rminos sencillos, la aplicaci\u00f3n intenta responder a una pregunta pr\u00e1ctica: \u00ab\u00bfPueden estos dos dispositivos encontrar una ruta funcional entre s\u00ed aunque sus enrutadores traduzcan direcciones y filtren el tr\u00e1fico entrante?\u00bb<\/p>\n
No existe una \u00fanica respuesta universal porque el comportamiento del NAT var\u00eda. Est\u00e1ndares como IETF RFC 4787 describen el comportamiento de NAT para UDP y explican por qu\u00e9 la coherencia es importante para aplicaciones en tiempo real, como comunicaci\u00f3n multimedia y juegos en l\u00ednea. El mismo problema amplio aparece en muchas categor\u00edas de aplicaciones modernas: las llamadas, las herramientas de colaboraci\u00f3n, los juegos, las herramientas de acceso remoto, los sistemas de estilo peer-to-peer y las aplicaciones tipo VPN pueden verse afectados por la forma en que las redes manejan el tr\u00e1fico.<\/p>\n
Para los lectores de VPN Satelites, la conclusi\u00f3n \u00fatil es simple: si una conexi\u00f3n se comporta de manera diferente entre redes, eso puede reflejar el comportamiento del enrutador, el NAT de nivel de operador, la pol\u00edtica de firewall, el filtrado de paquetes, la congesti\u00f3n u otras condiciones de la ruta. No debe leerse autom\u00e1ticamente como prueba de que la configuraci\u00f3n de una aplicaci\u00f3n no funciona.<\/p>\n
UDP se utiliza a menudo en aplicaciones en tiempo real porque puede evitar parte del retraso y la sobrecarga asociados con el tr\u00e1fico orientado a la conexi\u00f3n. Pero UDP no crea una sesi\u00f3n duradera de la misma manera que mucha gente imagina una conexi\u00f3n tradicional.<\/p>\n
La perforaci\u00f3n UDP es una t\u00e9cnica transversal de NAT en la que dos puntos finales env\u00edan cada uno paquetes UDP salientes para que sus dispositivos NAT creen asignaciones temporales. Si el tiempo y el comportamiento de NAT coinciden, el tr\u00e1fico del otro lado puede regresar a trav\u00e9s de esas asignaciones.<\/p>\n
La frase suena agresiva, pero el concepto es m\u00e1s com\u00fan de lo que sugiere el nombre. Se trata de trabajar con las reglas existentes del enrutador para el tr\u00e1fico saliente y de retorno. La investigaci\u00f3n fundamental de Bryan Ford, Pyda Srisuresh y Dan Kegel describe la perforaci\u00f3n como un enfoque pr\u00e1ctico utilizado por las aplicaciones basadas en UDP, al tiempo que enfatiza una limitaci\u00f3n clave: ninguna t\u00e9cnica transversal funciona en todas las configuraciones de NAT.<\/p>\n
Esa limitaci\u00f3n importa. Algunas redes reutilizan las asignaciones de forma \u00fatil. Otros crean asignaciones que est\u00e1n m\u00e1s estrechamente vinculadas a un destino espec\u00edfico. Algunas redes agregan un comportamiento de firewall adem\u00e1s de NAT. Algunas redes m\u00f3viles y de ISP colocan a los usuarios detr\u00e1s del NAT de nivel de operador, donde el usuario no controla en absoluto la capa de traducci\u00f3n ascendente.<\/p>\n
Entonces, cuando alguien pregunta qu\u00e9 es la perforaci\u00f3n UDP, la respuesta corta es: es una forma para que las aplicaciones intenten una ruta directa UDP a trav\u00e9s de asignaciones creadas por NAT. La respuesta cuidadosa es: puede funcionar bien en muchos entornos, pero no es una garant\u00eda.<\/p>\n
La conectividad directa puede fallar por varias razones comunes:<\/p>\n
Ninguno de estos casos significa que los usuarios deban intentar eludir reglas que no controlan. El punto pr\u00e1ctico es comprender que el comportamiento de la conexi\u00f3n depende de m\u00e1s de una preferencia de aplicaci\u00f3n. Si una red bloquea o limita intencionalmente un tipo de tr\u00e1fico, el siguiente paso suele ser utilizar una red permitida, consultar los t\u00e9rminos del servicio o hablar con el administrador de la red.<\/p>\n
Cuando la conectividad directa no es confiable, algunos sistemas utilizan un rel\u00e9: ambos puntos finales se conectan a un servidor intermedio y el servidor pasa el tr\u00e1fico entre ellos. IETF RFC 5766 describe TURN, abreviatura de recorrido usando rel\u00e9s alrededor de NAT, como un protocolo para comunicaci\u00f3n asistida por rel\u00e9 cuando la comunicaci\u00f3n directa entre pares no es posible en ciertas situaciones de NAT.<\/p>\n
Los rel\u00e9s resuelven un problema diferente al del recorrido directo del NAT. Una retransmisi\u00f3n puede mejorar la accesibilidad porque ambos dispositivos solo necesitan llegar al servicio de retransmisi\u00f3n. La desventaja es que el tr\u00e1fico toma una ruta adicional, lo que puede agregar latencia, costo de ancho de banda y complejidad operativa.<\/p>\n
Esta es la raz\u00f3n por la que muchos dise\u00f1os de conectividad prefieren probar primero una ruta directa y luego recurrir a ella cuando sea necesario. IETF RFC 8445 describe ICE como un enfoque de seguimiento de est\u00e1ndares para el recorrido de NAT para comunicaci\u00f3n basada en UDP que utiliza conceptos de STUN y TURN para descubrir y probar posibles rutas. Eso no significa que todas las herramientas relacionadas con VPN utilicen ICE, STUN o TURN. Simplemente muestra un patr\u00f3n de ingenier\u00eda com\u00fan: probar qu\u00e9 ruta funciona y luego usar una alternativa si la conectividad directa no est\u00e1 disponible.<\/p>\n
Para los lectores, la lecci\u00f3n importante es establecer expectativas realistas. Un retroceso de retransmisi\u00f3n puede hacer posible una conexi\u00f3n en situaciones en las que falla una ruta directa, pero no es lo mismo que hacer que desaparezcan todas las condiciones de la red.<\/p>\n
El contenido de VPN Satelites a menudo se centra en temas como privacidad, conectividad, enrutamiento de Internet y expectativas de los usuarios. El recorrido NAT pertenece al mismo vecindario educativo porque explica por qu\u00e9 la red alrededor de una aplicaci\u00f3n puede ser tan importante como la aplicaci\u00f3n misma.<\/p>\n
Para este tema, es importante mantener modesta la conexi\u00f3n del producto. Este art\u00edculo no afirma que VPN Satelites utilice ning\u00fan m\u00e9todo transversal espec\u00edfico de NAT, arquitectura de retransmisi\u00f3n, configuraci\u00f3n de reenv\u00edo de puertos, opci\u00f3n de IP est\u00e1tica o pila de protocolos. El valor aqu\u00ed es la alfabetizaci\u00f3n pr\u00e1ctica: comprender los t\u00e9rminos le ayuda a leer la gu\u00eda de soluci\u00f3n de problemas con m\u00e1s atenci\u00f3n y a evaluar los problemas de conexi\u00f3n sin esperar que ninguna aplicaci\u00f3n relacionada con VPN anule todas las reglas de la red.<\/p>\n
Si una conexi\u00f3n es inestable, algunas comprobaciones de bajo riesgo pueden ayudarle a separar el comportamiento de la aplicaci\u00f3n del comportamiento de la red:<\/p>\n
Estos pasos no eluden las restricciones. Ayudan a identificar de d\u00f3nde puede provenir el problema de conexi\u00f3n.<\/p>\n
Cuando vea que un producto, protocolo o aplicaci\u00f3n habla sobre el recorrido de NAT, lea el reclamo con precisi\u00f3n.<\/p>\n
Las preguntas \u00fatiles incluyen:<\/p>\n
Es f\u00e1cil pasar por alto ese \u00faltimo punto. Una funci\u00f3n que ayuda a que dos puntos finales se conecten no es autom\u00e1ticamente una garant\u00eda de privacidad. Una caracter\u00edstica de privacidad no es autom\u00e1ticamente una garant\u00eda de conectividad. Una buena documentaci\u00f3n deber\u00eda mantener esas ideas separadas.<\/p>\n
No. El recorrido NAT es un conjunto de t\u00e9cnicas de red para tratar la traducci\u00f3n de direcciones y el filtrado entre puntos finales. Un VPN es una categor\u00eda m\u00e1s amplia de tecnolog\u00eda para crear t\u00faneles de red protegidos. Es posible que algunas aplicaciones similares a VPN deban tener en cuenta el comportamiento de NAT, pero los conceptos no son los mismos.<\/p>\n
No. La perforaci\u00f3n del UDP depende del comportamiento del NAT, las reglas de filtrado, la sincronizaci\u00f3n y la topolog\u00eda de la red. Tanto las investigaciones como las discusiones sobre est\u00e1ndares apuntan a la misma realidad pr\u00e1ctica: el comportamiento del NAT es variado, por lo que es posible que se necesiten caminos alternativos.<\/p>\n
Son diferentes. Un rel\u00e9 puede ayudar cuando la comunicaci\u00f3n directa no es posible, pero puede agregar latencia, uso de ancho de banda y costo operativo. Una ruta directa puede ser m\u00e1s eficiente cuando funciona, pero puede fallar en redes m\u00e1s estrictas.<\/p>\n
No. Esos t\u00e9rminos se analizan como conceptos generales de redes y antecedentes de est\u00e1ndares. Este art\u00edculo no hace ninguna afirmaci\u00f3n de implementaci\u00f3n espec\u00edfica del producto sobre VPN Satelites.<\/p>\n
Este art\u00edculo no proporciona orientaci\u00f3n para evitarlo. El recorrido NAT puede ayudar a explicar el comportamiento de la conexi\u00f3n, pero los usuarios deben seguir las leyes, los t\u00e9rminos de servicio y las pol\u00edticas de red aplicables.<\/p>\n
El recorrido del NAT es importante porque la ruta de Internet entre dos dispositivos no siempre es directa o predecible. La perforaci\u00f3n del UDP puede ayudar a algunas aplicaciones a establecer una comunicaci\u00f3n directa a trav\u00e9s del NAT, mientras que los rel\u00e9s de respaldo pueden ayudar cuando fallan las rutas directas. Ambas ideas son \u00fatiles, pero ninguna es una soluci\u00f3n universal.<\/p>\n
Para los lectores de VPN Satelites, la lecci\u00f3n m\u00e1s pr\u00e1ctica es establecer expectativas realistas. La confiabilidad de la conexi\u00f3n depende de la aplicaci\u00f3n, el dispositivo, la red local, las pol\u00edticas de red ascendentes y la ruta m\u00e1s amplia entre los puntos finales. Comprender esas capas hace que la resoluci\u00f3n de problemas sea m\u00e1s sencilla y las afirmaciones del producto m\u00e1s f\u00e1ciles de leer de manera cr\u00edtica.<\/p>\n","protected":false},"excerpt":{"rendered":"
El recorrido de NAT, la perforaci\u00f3n de agujeros de UDP y los fallos de retransmisi\u00f3n explican por qu\u00e9 algunas aplicaciones se conectan f\u00e1cilmente en una red pero tienen problemas en otra. Aqu\u00ed est\u00e1 la versi\u00f3n en ingl\u00e9s sencillo, con expectativas realistas para los lectores de VPN Satelites.<\/p>\n","protected":false},"author":0,"featured_media":35,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[15],"tags":[43,40,42,41,20],"class_list":["post-34","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-vpn-education","tag-connection-reliability","tag-nat-traversal","tag-network-troubleshooting","tag-udp-hole-punching","tag-vpn-education"],"yoast_head":"\n