[No.42] Reenvío de puertos

101 0 0 0

El uso compartido de archivos y los proxies web pueden satisfacer la mayoría de las necesidades de los usuarios remotos para acceder a recursos internos, sin embargo, en algunas circunstancias (por ejemplo, para el acceso a aplicaciones no web basadas en TCP como Telnet, SSH, correo electrónico, etc.), El uso compartido de archivos y los proxies web parecen estar indefensos. Sin embargo, no es así en la práctica, y en esta sección presentaré el reenvío de puertos, la tercera función notable de SSL VPN, para todos.

El reenvío de puertos, en pocas palabras, es el uso de un programa cliente especial de reenvío de puertos en el lado del usuario remoto para obtener las solicitudes de acceso de un usuario, y luego reenviarlas al servidor correspondiente de la red interna a través de la puerta de enlace virtual. A continuación, usaremos el acceso a Telnet, la aplicación más utilizada, como ejemplo para introducir la configuración y los procesos involucrados en el acceso de clientes remotos a las redes internas a través de SSL VPN.

1 Configurando el reenvío de puertos

En la Figura 1-1 se muestra un escenario de uso de reenvío de puertos.

Figura 1-1 Escenario de uso de reenvío de puertos


055220mdso77e6m797zuz6.png?image.png


Al igual que con las otras funciones de VPN SSL introducidas anteriormente, independientemente del tipo de aplicación al que se acceda, los recursos correspondientes deben agregarse primero a la puerta de enlace virtual. Para Telnet, todo lo que se requiere es configurar la dirección IP y el puerto de un servidor Telnet en la puerta de enlace virtual, como se muestra en la Figura 1-2.

Figura 1-2 Reenvío de puertos: agregar un nuevo recurso.


055236t9udf2pplou9yoy2.png?image.png



Hay dos métodos para habilitar la función de reenvío de puertos. La primera es que el usuario remoto elija habilitar manualmente la función de reenvío de puertos en la interfaz de la puerta de enlace virtual que aparece después del inicio de sesión. La segunda es que el administrador establezca la configuración como habilitada automáticamente en el cliente después de iniciar sesión, como se muestra en la Figura 1-3. Además de poder habilitar automáticamente la función de reenvío de puertos, el administrador también puede elegir si desea mantener largas conexiones de reenvío de puertos. Esto es importante porque a medida que el acceso de algunas aplicaciones continúa durante un tiempo relativamente largo (por ejemplo, si el usuario remoto necesita salir repentinamente durante un período de tiempo mientras opera Telnet), después de seleccionarlo, puede evitar la interrupción del reenvío de puertos. Servicio debido al tiempo de espera de la conexión SSL y desconectado.

Figura 1-3 Configurando el reenvío de puertos


055259tf52vmx4xxxxuxu2.png?image.png


El proceso de manejo de datos para el reenvío de puertos es comparativamente complejo. Aquí, daré una figura simple (Figura 1-4), y recorreré cada paso de este bit a bit de abajo.

Figura 1-4 Proceso de manejo de reenvío de puertos

055329y787k7zfzl7kofkc.png?image.png


NOTA: El cliente de reenvío de puertos aquí contiene la función de cliente VPN SSL, y solo se llama con este nombre para enfatizar su servicio de reenvío de puertos.

2 Etapa Preparatoria

1. Inicie sesión en la SSL VPN

Este proceso ya se ha introducido en "8.1.2 Escenarios de uso de SSL VPN" y no se explicará más aquí.

Además, todos deben tener en cuenta que en las secciones anteriores me he centrado en las URL al comienzo de mis *** ysis, pero nuestros *** ysis de reenvío de puertos serán diferentes. Aunque una vez más hemos iniciado sesión en la puerta de enlace virtual, ya que este acceso no es de aplicación web, la web ya no se usa para el acceso a recursos correspondiente, y en lugar de otras aplicaciones, como Putty (una herramienta de Telnet / SSH), Se utilizan Filezilla (una herramienta de FTP) y Foxmail (un programa de correo electrónico). Esto da lugar a una pregunta: ¿cómo puede una aplicación no web hacer uso de una VPN SSL ya iniciada para conectarse?

2. El cliente de reenvío de puerto entra en el estado de "escucha".

Parece que el uso de una aplicación no web para el acceso a datos no debería implicar una VPN SSL, pero en realidad, el punto tecnológico clave del reenvío de puertos se muestra aquí: después de que un usuario utiliza el navegador IE del sistema operativo Windows para iniciar sesión En la puerta de enlace virtual, el navegador IE de su PC local ejecutará automáticamente el cliente de reenvío de puertos (control Active X). La función de este cliente es "escuchar" constantemente todas las solicitudes de otros programas (lo que hace que el cliente sea un "oyente de audición total"; lo llamaremos el "oyente" en los momentos a continuación), "interceptar" las solicitudes que envían los usuarios remotos al servidor de la red interna en momentos importantes, y luego enviarlos a la puerta de enlace virtual a través de la conexión SSL. De las solicitudes que "escucha", el Oyente no elige unilateralmente qué solicitudes interceptar, sino que implementa estrictamente las instrucciones que le da su "oficial superior", la puerta de enlace virtual. Ahora, ¿qué órdenes se dan?

El recurso de reenvío de puerto configurado anteriormente es en realidad el pedido emitido al cliente de reenvío de puerto por la puerta de enlace virtual: "si un usuario desea acceder a este recurso, ayúdelo a completar sus tareas de acceso". En la función de reenvío de puertos, las órdenes dadas son la dirección IP del host de destino + el puerto de destino, y solo la información antes mencionada puede confirmar la información de la aplicación a la que el usuario remoto desea acceder.

Como se muestra en la Figura 1-5, después de que un usuario remoto habilite manualmente la función de reenvío de puertos, el cliente de reenvío de puertos solicitará automáticamente información de recursos desde la puerta de enlace virtual. La información de recursos solicitada con éxito por el cliente se guardará en la memoria de la PC del usuario remoto y esperará más pedidos, para ayudar en la selección posterior de las solicitudes que se "interceptarán".

Figura 1-5 Reenvío de puertos: iniciación


055347wzan354ww3taw65w.png?image.png



Para que la dirección del servidor de la red interna no se divulgue, la información de recursos específicos no se puede ver en el cliente de reenvío de puertos, y los recursos en el menú no se pueden hacer clic directamente y, por lo tanto, solo sirven un simple rol de notificación.

3 Etapa de establecimiento de conexión Telnet

1. Intercepción precisa por parte del Oyente y visualización de sus habilidades de proxy

La "mente" del oyente ahora está clara en cuanto a qué solicitudes necesita "interceptar", y lo siguiente que debe hacer es usar sus "oídos" y escuchar el contenido que le preocupa. Cuando un usuario utiliza el protocolo Telnet para solicitar una conexión al puerto 23 de 10.1.1.1 (un paquete TCP SYN), el Oyente descubre que coincide con la información del recurso (IP de destino + dirección de destino) emitida por su oficial al mando (la dirección virtual). gateway), e inmediatamente "intercepta" este paquete TCP SYN. Si se usó el método normal, en este momento el paquete de solicitud se enviaría a la puerta de enlace virtual por el Oyente según su deber, pero aquí el Agente de escucha considera que si se envía a la puerta de enlace virtual sin procesamiento adicional, esto resultará en cada La solicitud de Telnet (es decir, cada conexión TCP) establece una nueva conexión SSL, que no solo ocuparía muchos recursos del sistema, sino que también retrasaría la velocidad de respuesta.

Para conservar la sesión de la puerta de enlace virtual y los recursos de memoria y mejorar la experiencia del usuario, el Oyente decide disfrazarse primero como receptor y simular la recepción de una solicitud de servicio Telnet (conexión TCP) para determinar exactamente qué tipo de recursos desea el usuario. Para acceder, la estrategia que está utilizando aquí es un método de proxy centralizado que busca una solución de conexión SSL para disminuir la presión sobre su oficial superior (la puerta de enlace virtual). ¿Cómo se puede simular la recepción de los servicios de Telnet? ¿Y cómo pueden proporcionarse servicios proxy centralizados? El Oyente, este destacado proxy, tiene un ingenioso plan:

Después de que el cliente de reenvío de puerto recibe una solicitud de Telnet, modifica el paquete, cambiando la solicitud original que debía enviarse a 10.1.1.1 para que se envíe a sí mismo (127.0.0.1). Esto es equivalente a sustituirse en lugar del servidor Telnet al recibir la solicitud. Sin embargo, una simulación sigue siendo solo una simulación y, al mismo tiempo que la simulación, debe registrar la relación de modificación previa y posterior a la modificación correspondiente, de modo que pueda responder posteriormente al usuario real (4.1.64.179) en lugar del servidor telnet

El cliente de reenvío de puertos establece la conexión TCP 1 (también llamada conexión de bucle de retorno local) consigo misma. El uso del comando netstat proporciona la siguiente verificación de esto:


C:\> netstat -anp tcp

 

Active Connections

 

  Protocol Local address          External Address          Status

  TCP    127.0.0.1:1047        0.0.0.0:0              LISTENING

  TCP    127.0.0.1:1047        127.0.0.1:7319        ESTABLISHED

  TCP    127.0.0.1:7319        127.0.0.1:1047        ESTABLISHED



2. Crear un encabezado de paquete privado y enviar la "lista de servicios de reenvío de puertos".

Después de la recepción simulada de una solicitud de servicio de Telnet, el cliente de reenvío de puertos tiene una comprensión completa de la solicitud del usuario y necesita completar la "lista de servicios de reenvío de puertos" y enviarla a la puerta de enlace virtual de acuerdo con los requisitos de procedimiento. La lista de servicios debe incluir la dirección de destino (10.1.1.1) y el puerto (23) solicitados por el usuario, así como una palabra de comando (para establecer una conexión, transferir paquetes de datos o cerrar la conexión, etc.) para que La pasarela virtual puede llevar a cabo el procesamiento posterior.

Aquí debemos tener en cuenta que, como el propio cliente de reenvío de puertos simuló el establecimiento de TCP Connection 1 del receptor, debe haber un marcador (ID de socket de TCP Connection 1, denominado ID de socket de cliente) en la lista de servicios de esta conexión TCP. Solo de esta manera, el cliente de reenvío de puertos puede usar el marcador para encontrar la conexión TCP 1 cuando el oficial superior devuelve los resultados del servicio administrado y luego envía los resultados de la devolución al cliente Telnet correspondiente.

La lista del servicio de reenvío de puertos se denomina encabezado de paquete privado (o simplemente un encabezado privado) durante el servicio de reenvío de puertos, como se muestra en la Tabla 1-1. Aquí, solo veremos los paquetes de conexión de solicitud de Telnet y explicaremos los campos primarios en el encabezado del paquete privado. En la etapa de establecimiento de la conexión Telnet, la carga útil del paquete está vacía, por lo que durante la transmisión solo hay un encabezado de paquete privado; el paquete no tiene una carga útil hasta la etapa de transferencia de datos.

Tabla 1-1 encabezado de paquete privado de reenvío de puertos


Nombre del campo

Detalles del campo

Marcador de usuario

Marca la identidad del usuario, y se asigna automáticamente para el usuario   por la puerta de enlace virtual. Esto puede entenderse como el número de la   lista de servicios de reenvío de puertos.

Palabra de comando

Open- crear una nueva conexión

Data- comando de datos

Close-cerrar   conexión

Tipo de servicio

Reenvío de puertos

Web-Link es en realidad el servicio de reenvío de puertos HTTP /   HTTPS. O, para decirlo de otra manera, los recursos de enlace web también   pueden configurarse como recursos de reenvío de puertos. Pero recuerde que no   es necesario designar un puerto conocido para los recursos de enlace web, por   ejemplo, http://www.huawei.com/, pero al configurar el reenvío de puertos, el   número de puerto es obligatorio, por ejemplo, el pozo HTTP. -conocido número   de puerto 80 y HTTPS's 443.

Dirección IP origen

La dirección IP de origen para la solicitud original. En este ejemplo,   esta es la dirección del cliente del usuario remoto: 4.1.64.179.

Dirección IP de   destino.

La dirección IP de destino de la solicitud original. En este ejemplo,   esta es la dirección Telnet de la red interna: 10.1.1.1.

Tipo de protocolo

Por el momento solo se soporta el protocolo TCP.

Puerto de destino

El puerto de destino en la solicitud original. En este ejemplo, este   es el puerto Telnet 23 de la red interna.

ID de socket del cliente.

El ID de socket utilizado para establecer una conexión entre el   usuario remoto y el firewall. Esto se utiliza para identificar esta sesión;   Los paquetes subsiguientes continuarán utilizando este ID de socket.

ID de socket del servidor

La ID de socket utilizada para establecer una conexión entre el   servidor de seguridad (que funciona como el cliente Telnet) y el servidor de   red interno. Esto tiene la misma función que el ID de socket del cliente:   ambos se utilizan para identificar la sesión.

Una vez finalizada la organización de la lista de transacciones de reenvío de puertos, se cifra y se envía a la puerta de enlace virtual mediante la conexión SSL.

Es importante tener en cuenta que aquí se establece una conexión SSL especialmente utilizada para el servicio de reenvío de puertos, no la conexión SSL que se estableció durante el inicio de sesión. Cuando Telnet inicia solicitudes de acceso similares a otros recursos, y después de establecer una nueva conexión TCP, el cliente de reenvío de puertos también completará una lista de servicios de reenvío de puertos y la enviará a través de esta conexión SSL. De esta manera, siempre se mantendrá una conexión SSL exclusiva entre el cliente y la puerta de enlace virtual. Para resumir, todas las listas de servicios de reenvío de puertos se enviarán primero a esta conexión SSL, y luego se enviarán a la puerta de enlace virtual después del cifrado, reduciendo en gran medida la carga de trabajo de la puerta de enlace virtual.

3. Establecimiento de una conexión entre la puerta de enlace virtual y el servidor de red interno

La puerta de enlace virtual recibe el paquete cifrado, lo descifra y obtiene la dirección IP y el puerto de destino de Telnet reales, la clave de comando y otra información de la lista del servicio de reenvío de puertos. En este punto, la puerta de enlace virtual servirá como el cliente Telnet e interactuará con el servidor de red interno para establecer una conexión Telnet. Una comprobación de la tabla de sesión del firewall muestra que el firewall habilitó al azar el puerto 10010 para iniciar una solicitud de acceso a 10.1.1.1:23, estableciendo la conexión TCP 2:

telnet  VPN:public --> public 10.1.1.2:10010-->10.1.1.1:23

4. El paquete de respuesta del servidor de red interno vuelve al cliente Telnet.

La puerta de enlace virtual recibe el paquete de respuesta del servidor de red interno (interfaz de inicio de sesión) y, antes de enviarlo al cliente remoto, la puerta de enlace virtual aún construirá un encabezado de paquete privado y completará la ID de socket de TCP Connection 2 (la ID de socket del servidor); esto le permite establecer una relación con la conexión TCP 1. Finalmente, la puerta de enlace virtual envía el encabezado del paquete privado cifrado SSL + los datos al cliente de reenvío de puertos a través del SSL; el cliente de reenvío de puertos encuentra la conexión TCP 1 según el ID de socket del cliente en el encabezado privado, luego encuentra la dirección IP real del cliente Telnet y finalmente devuelve los datos reales.

Los datos descifrados de SSL recibidos por el cliente de reenvío de puertos se muestran a continuación. En la parte resaltada en la captura de pantalla, el texto de la página de inicio de sesión ya se puede ver vagamente (este es el paquete de datos de Telnet), y el contenido en el contenido superior es el contenido del encabezado privado.



055422dfbg0gi9000repny.png?image.png


4 Etapa de comunicación de datos

Los paquetes de datos subsiguientes de Telnet continuarán utilizando la conexión TCP 1 y TCP 2 establecidas previamente, y asociarán las dos conexiones utilizando encabezados de paquetes privados, finalmente abriendo un canal de transmisión de puerto Telnet de cliente-puerto cliente-virtual-gateway-servidor Telnet, permitiendo La comunicación de datos a alcanzar.

La introducción al proceso de reenvío de puertos de la aplicación Telnet concluye aquí. El protocolo Telnet es solo un protocolo de un solo canal, el tipo de protocolo más simple. Además de esto, el reenvío de puertos también admite los siguientes tipos de aplicaciones:

·         Protocolos de múltiples canales, soportando FTP y Oracle SQL Net. Durante la configuración real, solo se debe designar el puerto 21 del canal de control para el protocolo FTP; los puertos de datos negociados serán pasivamente "escuchados" y no se requiere configuración adicional.

·         Múltiples aplicaciones de protocolo. Algunas aplicaciones requieren el soporte de múltiples protocolos. Tome el correo electrónico, por ejemplo: antes de configurar el servicio de reenvío de puertos, deben configurarse los números de puerto del protocolo de envío (SMTP: 25) y el protocolo de recepción (POP3: 110 o IMAP: 143), así como un recurso de reenvío de puertos para cada uno. Tipo de protocolo.

·         Múltiples aplicaciones de puerto fijo IP. Utilizando IBM Lotus Notes como ejemplo, sus bases de datos correspondientes están en varios servidores, sin embargo, al proporcionar un servicio externo, solo se usa el puerto 1352. Cuando este tipo de aplicación configura el servicio de reenvío de puertos, no es necesario realizar una configuración transversal para todos los servidores. En su lugar, simplemente podemos seleccionar "Cualquier dirección IP" de "Tipo de dirección de host".

En situaciones reales, la configuración y el uso del reenvío de puertos es extremadamente simple (¡por supuesto que lo es! Después de todo, ¡se trata de una VPN SSL!), Pero lo que no se ve es la cantidad de trabajo detrás de escena. Creando esta maravillosa funcionalidad. Es posible que no utilices ese contenido abstracto con frecuencia, pero confía en que cuando llegue la necesidad, aparecerán mis palabras nuevamente y te ayudaré a descubrir formas de mejorar aún más tu conexión VPN.


  • x
  • convención:

Responder

Responder
Debe iniciar sesión para responder la publicación Inicio de sesión | Registrarse

Aviso Aviso: Para garantizar sus legítimos derechos e intereses, la comunidad y los terceros no publicarán contenido que pueda generar riesgos legales a las partes, por ejemplo, pornografía, contenido político, contenido sobre juego, consumo y tráfico de drogas, así como contenido que viole los derechos de propiedad intelectual de terceros, por ejemplo, secretos comerciales, marcas, derechos de autor, patentes y privacidad personal. No comparta su cuenta ni su contraseña con terceros. Todas las operaciones realizadas usando su cuenta se considerarán como sus acciones y todas las consecuencias que estas acciones generen serán responsabilidad suya. Para obtener información detallada, consulte la “ Política de privacidad.”
Si el botón para adjuntar no está disponible, actualice Adobe Flash Player con la versión más reciente
¡Ingresa y disfruta de todos los beneficios para los miembros!

¡Ingresa y disfruta de todos los beneficios para los miembros!

Aterrizaje