Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Trabajando con balanceadores de carga de red
Si debes colocar un balanceador de carga de red (NLB) delante de un AWS Transfer Family el servidor depende del protocolo que utilice su servidor. Revise la siguiente guía antes de agregar un NLB a su arquitectura.
-
FTP y FTPS — Recomendamos no colocar un NLB delante del servidor. Un NLB en esta ruta aumenta los costos y reduce la cantidad de conexiones simultáneas que acepta el servidor. Si su implementación de FTP o FTPS requiere un NLB, consulte Evite colocar los NLB y los NAT frente a AWS Transfer Family servidores para obtener recomendaciones de configuración.
-
SFTP — Se admite un NLB para los servidores que utilizan un VPC-hosted punto final, aunque recomendamos evitar un NLB siempre que sea posible. Cuando se requiera un NLB, puede conservar la dirección IP de origen del cliente con el protocolo PROXY v2 (PPv2).
Un motivo habitual para colocar un NLB delante de un AWS Transfer Family el servidor es ofrecer un puerto de escucha personalizado. AWS Transfer Family ya ofrece varios puertos, así que revise AWS Transfer Family matriz de tipos de punto final y Crea un SFTP-enabled servidor para los puertos compatibles antes de añadir un NLB para mostrar un puerto de escucha personalizado.
Preservar la IP de origen del cliente para SFTP con el protocolo PROXY v2
Esta función se aplica a los servidores SFTP que utilizan un VPC-hosted punto final. Cuando hay un NLB en la ruta entre su cliente y su servidor SFTP, AWS Transfer Family ve la dirección IP privada del NLB en lugar de la dirección IP de origen del cliente. El protocolo PROXY v2 (PPv2) resuelve este problema. El NLB agrega un encabezado PPv2 que contiene la dirección IP de origen del cliente y AWS Transfer Family lee ese encabezado.
Al habilitar PPv2, la dirección IP de origen del cliente pasa a estar disponible en los siguientes lugares:
-
La autenticación solicita que AWS Transfer Family envía a tu proveedor de identidad personalizado. A continuación, puede escribir IP-based políticas de acceso.
-
Entradas de registro en Amazon CloudWatch Registros.
Compatibilidad del cliente SSH con el protocolo PROXY v2
Una vez establecida la conexión TCP, tanto el cliente como el servidor envían una cadena de identificación SSH como sus primeros datos. Esta cadena identifica su protocolo SSH y sus versiones de software, por ejemplo SSH-2.0-OpenSSH_10.3. Para obtener más información, consulte Protocolo de capa de transporte SSH (RFC 4253)
Algunos clientes SSH antiguos esperan a recibir la cadena de identificación SSH del servidor antes de enviar la suya propia. Los clientes que aún admiten la versión 1 del protocolo SSH lo hacen para poder elegir una versión del protocolo en función de la cadena de identificación del servidor. Cuando el protocolo PROXY v2 está habilitado en un grupo objetivo de NLB, el NLB no entrega la cadena de identificación del servidor al cliente hasta que el cliente envía los datos. Estos clientes se conectan y esperan la cadena de identificación del servidor, por lo que nunca envían la suya propia y la conexión se detiene hasta que se agota el tiempo de espera.
En la siguiente tabla se enumeran los clientes SSH más comunes y la versión mínima de cada uno que se sabe que es compatible con el protocolo PROXY v2 en su configuración predeterminada. Esta lista no es exhaustiva. Una versión anterior también podría funcionar si la configuras para usar solo la versión 2 del protocolo SSH. Si usas un cliente que no aparece en esta tabla, comprueba su compatibilidad antes de habilitar el protocolo PROXY v2.
Cliente |
Versión mínima |
|---|---|
WinSCP |
5.8.1 |
OpenSSH |
6.2 |
JSch |
0.1.34 |
Paramiko |
Todas las versiones |
SSH.NET |
2020.0.0 |
FileZilla |
3.14,0 |
ssh2 (Node.js) |
Todas las versiones |
Apache MINA SSHD |
Todas las versiones |
libssh2 |
0.6 |
SSHJ |
Todas las versiones |
Cyberduck |
2.2 |
Para encontrar los clientes SSH que se conectan a tu servidor, habilita el registro estructurado para tu servidor. El client el campo contiene la cadena de identificación del cliente, por ejemplo SSH-2.0-OpenSSH_10.3. Para obtener más información, consulte Registros estructurados en JSON para Transfer Family. Si un cliente espera la cadena de identificación SSH del servidor antes de enviar la suya propia, o no aparece en esta tabla, pida a esos usuarios que la actualicen antes de habilitar el protocolo PROXY v2 para su NLB.
Habilita la aplicación del protocolo PROXY v2 en un servidor existente
El SftpMode miembro de ProxyConfig controla la forma en que el servidor gestiona el encabezado PPv2. Tiene exactamente dos valores: NONE (predeterminado) y PROXY_PROTOCOL_V2_ENFORCED. Para obtener más información, consulta ProtocolDetails en la AWS Transfer Family Referencia de la API de .
importante
Con PROXY_PROTOCOL_V2_ENFORCED, debe restringir el grupo de seguridad de puntos finales de la VPC del servidor para permitir el tráfico entrante únicamente a través del NLB de confianza. Como el servidor confía en la dirección IP de origen del encabezado PPv2, esto evita que un cliente omita el NLB y presente una dirección IP de origen falsa.
Complete los tres pasos siguientes para habilitar la aplicación sin rechazar ninguna conexión. Esta orden evita el tiempo de inactividad de la migración.
Paso 1: Habilite el protocolo PROXY v2 en el grupo objetivo de NLB
Habilite el proxy_protocol_v2.enabled atributo del grupo objetivo de NLB que apunta al punto final de la VPC de su servidor. Este atributo indica al NLB que anteponga un encabezado PPv2 a cada conexión. Para obtener instrucciones, consulte Protocolo de proxy para su balanceador de carga de red en el Guía del usuario de Elastic Load Balancing.
Mientras el servidor esté configurado en SftpMode=NONE, acepta conexiones con o sin un encabezado PPv2.
nota
Algunos clientes SSH esperan a recibir la cadena de identificación SSH del servidor antes de enviar la suya propia. Al habilitar el protocolo PROXY v2, estos clientes no pueden completar la conexión. Antes de habilitar el protocolo PROXY v2, confirme que los clientes de sus usuarios envíen primero su cadena de identificación. Para obtener más información, consulte Compatibilidad del cliente SSH con el protocolo PROXY v2.
Paso 2: Verifique que el encabezado llegue a todas las conexiones
Antes de aplicar el PPv2, confirme que el servidor recibe un encabezado del PPv2 en cada conexión. Inspeccione los registros de su servidor para ver si CONNECTED tipo de actividad. En los registros estructurados (JSON) de Amazon CloudWatch Registros, consulta el proxy-protocol-v2-header campo para el valor ignored. En los registros antiguos, consulta el ProxyProtocolV2Header campo para el mismo valor.
El campo tiene la semántica siguiente:
-
El campo está ausente cuando la conexión no incluye ningún encabezado PPv2.
-
El valor es
ignoredcuando la conexión incluía un encabezado PPv2 mientrasSftpModeesNONE. -
El valor es
appliedcuando la conexión incluía un encabezado PPv2 y el servidor lo respetabaPROXY_PROTOCOL_V2_ENFORCED.
Siga revisando los registros hasta que cada CONNECTED la entrada contiene el campo con el valor ignored. Un campo ausente significa que alguna ruta aún llega al servidor sin un encabezado PPv2. Si aplica el encabezado mientras falta alguna ruta, el servidor rechazará esas conexiones. Para obtener más información acerca de estos campos de registro, consulte Registros estructurados en JSON para Transfer Family y Registros antiguos de Transfer Family.
Paso 3: Aplicar el protocolo PROXY v2
Actualice el servidor para que SftpMode miembro de ProxyConfig es PROXY_PROTOCOL_V2_ENFORCED. A continuación, el servidor requiere un encabezado PPv2 válido en cada conexión SFTP entrante. El servidor rechaza las conexiones que llegan sin un encabezado PPv2 válido y registra un error en Amazon CloudWatch Registros. Para retroceder, configure SftpMode a NONE.
