View a markdown version of this page

Utilisation des équilibreurs de charge réseau - AWS Transfer Family
Préserver l'adresse IP source du clientCompatibilité avec les clientsActiver l'application du protocole PPv2

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Utilisation des équilibreurs de charge réseau

Si vous devez placer un Network Load Balancer (NLB) devant un AWS Transfer Family Le serveur dépend du protocole utilisé par votre serveur. Consultez les instructions suivantes avant d'ajouter un NLB à votre architecture.

  • FTP et FTPS — Nous vous recommandons de ne pas placer un NLB devant le serveur. Un NLB sur ce chemin augmente les coûts et réduit le nombre de connexions simultanées acceptées par le serveur. Si votre implémentation FTP ou FTPS nécessite un NLB, consultez Évitez de placer les NLB et les NAT devant AWS Transfer Family serveurs pour des recommandations de configuration.

  • SFTP — Un NLB est pris en charge pour les serveurs qui utilisent un VPC-hosted point final, bien que nous vous recommandons d'éviter un NLB dans la mesure du possible. Lorsqu'un NLB est requis, vous pouvez conserver l'adresse IP source du client à l'aide du protocole PROXY v2 (PPv2).

Une raison courante de placer un NLB devant un AWS Transfer Family le serveur doit proposer un port d'écouteur personnalisé. AWS Transfer Family propose déjà plusieurs ports, alors passez en revue AWS Transfer Family matrice des types de terminaux et Créez un SFTP-enabled serveur pour les ports pris en charge avant d'ajouter un NLB pour exposer un port d'écouteur personnalisé.

Préservation de l'adresse IP source du client pour SFTP avec le protocole PROXY v2

Cette fonctionnalité s'applique aux serveurs SFTP qui utilisent un VPC-hosted point final. Lorsqu'un NLB se trouve sur le chemin entre votre client et votre serveur SFTP, AWS Transfer Family voit l'adresse IP privée du NLB au lieu de l'adresse IP source du client. Le protocole PROXY v2 (PPv2) résout ce problème. Le NLB ajoute un en-tête PPv2 qui contient l'adresse IP source du client, et AWS Transfer Family lit cet en-tête.

Lorsque vous activez PPv2, l'adresse IP source du client devient disponible aux emplacements suivants :

  • Demandes d'authentification qui AWS Transfer Family envoie à votre fournisseur d'identité personnalisé. Vous pouvez ensuite écrire IP-based politiques d'accès.

  • Entrées de journal dans Amazon CloudWatch Journaux.

Compatibilité du client SSH avec le protocole PROXY v2

Une fois la connexion TCP établie, le client et le serveur envoient une chaîne d'identification SSH comme premières données. Cette chaîne identifie leur protocole SSH et leurs versions logicielles, par exemple SSH-2.0-OpenSSH_10.3. Pour plus d'informations, voir Protocole de couche de transport SSH (RFC 4253) sur le site web de l'IETF Datatracker.

Certains anciens clients SSH attendent de recevoir la chaîne d'identification SSH du serveur avant d'envoyer la leur. Les clients qui prennent toujours en charge la version 1 du protocole SSH le font afin de pouvoir choisir une version du protocole en fonction de la chaîne d'identification du serveur. Lorsque le protocole PROXY v2 est activé sur un groupe cible NLB, le NLB ne transmet pas la chaîne d'identification du serveur au client tant que celui-ci n'a pas envoyé de données. Ces clients se connectent et attendent la chaîne d'identification du serveur pour ne jamais envoyer la leur, et la connexion se bloque jusqu'à son expiration.

Le tableau suivant répertorie les clients SSH courants et la version minimale de chacun d'entre eux qui est connue pour être compatible avec le protocole PROXY v2 dans sa configuration par défaut. Cette liste n'est pas exhaustive. Une ancienne version peut également fonctionner si vous la configurez pour n'utiliser que la version 2 du protocole SSH. Si vous utilisez un client qui ne figure pas dans ce tableau, testez sa compatibilité avant d'activer le protocole PROXY v2.

Client

Version minimale

WinSCP

5.8.1

OpenSSH

6.2

JSch

0,1,34

Paramiko

Toutes les versions

SSH.NET

2020,0,0

FileZilla

3,14,0

ssh 2 (Node.js)

Toutes les versions

Apache MINA SSHD

Toutes les versions

libssh2

0.6

SSHJ

Toutes les versions

Cyberduck

2.2

Pour trouver les clients SSH qui se connectent à votre serveur, activez la journalisation structurée pour votre serveur. Le client le champ contient la chaîne d'identification du client, par exemple SSH-2.0-OpenSSH_10.3. Pour plus d’informations, consultez Journaux structurés JSON pour Transfer Family. Si un client attend la chaîne d'identification SSH du serveur avant d'envoyer la sienne, ou si elle n'apparaît pas dans ce tableau, demandez à ces utilisateurs de procéder à une mise à niveau avant d'activer le protocole PROXY v2 pour votre NLB.

Activer l'application du protocole PROXY v2 sur un serveur existant

Le SftpMode membre de ProxyConfig contrôle la façon dont votre serveur gère l'en-tête PPv2. Il a exactement deux valeurs : NONE (valeur par défaut) et PROXY_PROTOCOL_V2_ENFORCED. Pour plus d’informations, consultez ProtocolDetails dans la Référence d’API AWS Transfer Family .

Important

Avec PROXY_PROTOCOL_V2_ENFORCED, vous devez restreindre le groupe de sécurité des terminaux VPC du serveur pour autoriser le trafic entrant uniquement via le NLB sécurisé. Comme le serveur fait confiance à l'adresse IP source dans l'en-tête PPv2, cela empêche un client de contourner le NLB et de présenter une adresse IP source usurpée.

Effectuez les trois étapes suivantes afin d'activer l'application sans refuser aucune connexion. Cette commande permet d'éviter toute interruption de la migration.

Étape 1 : activer le protocole PROXY v2 sur le groupe cible NLB

Activez le proxy_protocol_v2.enabled attribut sur le groupe cible NLB qui pointe vers le point de terminaison VPC de votre serveur. Cet attribut indique au NLB d'ajouter un en-tête PPv2 à chaque connexion. Pour obtenir des instructions, voir Protocole proxy pour votre Network Load Balancer dans le Guide de l'utilisateur d'Elastic Load Balancing.

Lorsque le serveur est réglé sur SftpMode=NONE, il accepte les connexions avec ou sans en-tête PPv2.

Note

Certains clients SSH attendent de recevoir la chaîne d'identification SSH du serveur avant d'envoyer la leur. Lorsque vous activez le protocole PROXY v2, ces clients ne parviennent pas à établir la connexion. Avant d'activer le protocole PROXY v2, vérifiez que les clients de vos utilisateurs envoient d'abord leur chaîne d'identification. Pour plus de détails, consultez Compatibilité du client SSH avec le protocole PROXY v2.

Étape 2 : Vérifiez que l'en-tête arrive à chaque connexion

Avant d'appliquer le protocole PPv2, vérifiez que le serveur reçoit un en-tête PPv2 à chaque connexion. Inspectez les journaux de votre serveur pour CONNECTED type d'activité. Dans les journaux structurés (JSON) d'Amazon CloudWatch Journaux, vérifiez proxy-protocol-v2-header champ pour la valeur ignored. Dans les anciens journaux, vérifiez ProxyProtocolV2Header champ pour la même valeur.

La sémantique du champ est la suivante :

  • Le champ est absent lorsque la connexion ne comporte aucun en-tête PPv2.

  • La valeur est ignored lorsque la connexion incluait un en-tête PPv2 alors que SftpMode est NONE.

  • La valeur est applied lorsque la connexion incluait un en-tête PPv2 et que le serveur l'a honoré sous PROXY_PROTOCOL_V2_ENFORCED.

Continuez à vérifier les journaux jusqu'à chaque CONNECTED l'entrée contient le champ avec la valeur ignored. Un champ absent signifie qu'un chemin atteint toujours le serveur sans en-tête PPv2. Si vous appliquez alors qu'un chemin n'a pas d'en-tête, le serveur refuse ces connexions. Pour plus d'informations sur ces champs de journal, voir Journaux structurés JSON pour Transfer Family et Journaux hérités pour Transfer Family.

Étape 3 : Appliquer le protocole PROXY v2

Mettez à jour le serveur afin que SftpMode membre de ProxyConfig est PROXY_PROTOCOL_V2_ENFORCED. Le serveur a alors besoin d'un en-tête PPv2 valide sur chaque connexion SFTP entrante. Le serveur refuse les connexions qui arrivent sans en-tête PPv2 valide et enregistre une erreur sur Amazon CloudWatch Journaux. Pour revenir en arrière, réglez SftpMode pour NONE.

Console

Sur le Informations sur le serveur page, choisissez Modifier à côté de Informations supplémentaires, puis activez Configuration du protocole PROXY option. Pour la procédure complète d'édition sur le serveur, voir Modifier les informations du serveur.

AWS CLI

Exécutez la commande suivante pour appliquer le protocole PROXY v2 sur votre serveur.

aws transfer update-server --server-id your-server-id --protocol-details ProxyConfig={SftpMode=PROXY_PROTOCOL_V2_ENFORCED}

En cas de succès, la commande renvoie le code suivant et met à jour votre serveur.

{
    "ServerId": "your-server-id"
}