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](infrastructure-security.md#nlb-considerations) 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](sftp-for-transfer-family.md#endpoint-matrix) y [Crea un SFTP-enabled servidor](create-server-sftp.md) 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)](https://datatracker.ietf.org/doc/html/rfc4253#section-4.2) en el sitio web de IETF Datatracker.
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](cw-structure-logs.md#json-log-entries). 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](https://docs.aws.amazon.com/transfer/latest/APIReference/API_ProtocolDetails.html) 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](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/edit-target-group-attributes.html#proxy-protocol) 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](#nlb-sftp-client-compatibility).
### 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 `ignored` cuando la conexión incluía un encabezado PPv2 mientras `SftpMode` es `NONE`.
+ El valor es `applied` cuando la conexión incluía un encabezado PPv2 y el servidor lo respetaba `PROXY_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](cw-structure-logs.md#json-log-entries) y [Registros antiguos de Transfer Family](cw-structure-logs.md#legacy-log-entries).
### 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`.
------
#### [ Console ]
En el **Detalles del servidor** página, elija **Editar** junto a **Detalles adicionales**y, a continuación, encienda el **configuración del protocolo PROXY** opción. Para ver el procedimiento completo del servidor de edición, consulte [Editar detalles del servidor](edit-server-config.md).
------
#### [ AWS CLI ]
Ejecute el siguiente comando para aplicar el protocolo PROXY v2 en su servidor.
```
aws transfer update-server --server-id {{your-server-id}} --protocol-details ProxyConfig={SftpMode=PROXY_PROTOCOL_V2_ENFORCED}
```
Si se ejecuta correctamente, el comando devuelve el siguiente código y actualiza el servidor.
```
{
"ServerId": "{{your-server-id}}"
}
```
------