View a markdown version of this page

Utilizzo dei Network Load Balancer - AWS Transfer Family
Conserva l'IP di origine del clientCompatibilità con i clientAbilita l'applicazione del protocollo PPv2

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Utilizzo dei Network Load Balancer

Se collocare un Network Load Balancer (NLB) davanti a un AWS Transfer Family il server dipende dal protocollo utilizzato dal server. Consulta le seguenti linee guida prima di aggiungere un NLB alla tua architettura.

  • FTP e FTPS — Si consiglia di non posizionare un NLB davanti al server. Un NLB in questo percorso aumenta i costi e riduce il numero di connessioni simultanee accettate dal server. Se l'implementazione FTP o FTPS richiede un NLB, vedi Evitare di posizionare NLB e NAT davanti a AWS Transfer Family server per consigli sulla configurazione.

  • SFTP — Un NLB è supportato per i server che utilizzano un VPC-hosted endpoint, tuttavia consigliamo di evitare un NLB ove possibile. Dove è richiesto un NLB, è possibile conservare l'indirizzo IP di origine del client con il protocollo PROXY v2 (PPv2).

Un motivo comune per mettere un NLB davanti a un AWS Transfer Family il server deve offrire una porta listener personalizzata. AWS Transfer Family offre già diverse porte, quindi recensisci AWS Transfer Family matrice del tipo di endpoint e Crea un SFTP-enabled server per le porte supportate prima di aggiungere un NLB per esporre una porta listener personalizzata.

Preservazione dell'IP di origine del client per SFTP con il protocollo PROXY v2

Questa funzionalità si applica ai server SFTP che utilizzano un VPC-hosted endpoint. Quando un NLB si trova nel percorso tra il client e il server SFTP, AWS Transfer Family vede l'indirizzo IP privato dell'NLB anziché l'indirizzo IP di origine del client. Il protocollo PROXY v2 (PPv2) risolve questo problema. L'NLB aggiunge un'intestazione PPv2 che riporta l'indirizzo IP di origine del client e AWS Transfer Family legge quell'intestazione.

Quando si abilita PPv2, l'indirizzo IP di origine del client diventa disponibile nelle seguenti posizioni:

  • L'autenticazione richiede che AWS Transfer Family invia al tuo provider di identità personalizzato. Puoi quindi scrivere IP-based politiche di accesso.

  • Inserimenti di registro in Amazon CloudWatch Registri.

Compatibilità del client SSH con il protocollo PROXY v2

Dopo aver stabilito la connessione TCP, sia il client che il server inviano una stringa di identificazione SSH come primi dati. Questa stringa identifica il protocollo SSH e le versioni del software, ad esempio SSH-2.0-OpenSSH_10.3. Per ulteriori informazioni, vedere Protocollo SSH Transport Layer (RFC 4253) sul sito web IETF Datatracker.

Alcuni client SSH meno recenti attendono di ricevere la stringa di identificazione SSH del server prima di inviare la propria. I client che supportano ancora la versione 1 del protocollo SSH lo fanno in modo da poter scegliere una versione del protocollo basata sulla stringa di identificazione del server. Quando il protocollo PROXY v2 è abilitato su un gruppo target NLB, l'NLB non fornisce la stringa di identificazione del server al client finché il client non invia i dati. Questi client si connettono e attendono la stringa di identificazione del server, quindi non inviano mai la propria e la connessione si blocca fino allo scadere del timeout.

La tabella seguente elenca i client SSH comuni e la versione minima di ciascuno nota per essere compatibile con il protocollo PROXY v2 nella sua configurazione predefinita. Questo elenco non è completo. Una versione precedente potrebbe funzionare anche se la configuri per utilizzare solo la versione 2 del protocollo SSH. Se utilizzi un client non presente in questa tabella, verificane la compatibilità prima di abilitare il protocollo PROXY v2.

Client

Versione minima

WinSCP

5.8.1

OpenSSH

6.2

JSch

0.1.34

Paramiko

Tutte le versioni

SSH.NET

2020.0.0

FileZilla

3,14,0

ssh 2 (Node.js)

Tutte le versioni

Apache MINA SSHD

Tutte le versioni

libssh2

0.6

SSHJ

Tutte le versioni

Cyberduck

2.2

Per trovare i client SSH che si connettono al tuo server, abilita la registrazione strutturata per il tuo server. Il client il campo contiene la stringa di identificazione del cliente, ad esempio SSH-2.0-OpenSSH_10.3. Per ulteriori informazioni, consulta Log strutturati JSON per Transfer Family. Se un client attende la stringa di identificazione SSH del server prima di inviare la propria, o non compare in questa tabella, chiedi agli utenti di eseguire l'aggiornamento prima di abilitare il protocollo PROXY v2 per il tuo NLB.

Abilita l'applicazione del protocollo PROXY v2 su un server esistente

Il SftpMode membro di ProxyConfig controlla il modo in cui il server gestisce l'header PPv2. Ha esattamente due valori: NONE (impostazione predefinita) e PROXY_PROTOCOL_V2_ENFORCED. Per ulteriori informazioni, consulta ProtocolDetails nella documentazione di riferimento dell’API AWS Transfer Family .

Importante

Con PROXY_PROTOCOL_V2_ENFORCED, è necessario limitare il gruppo di sicurezza degli endpoint VPC del server in modo da consentire il traffico in entrata solo attraverso l'NLB affidabile. Poiché il server si fida dell'indirizzo IP di origine nell'intestazione PPv2, ciò impedisce a un client di aggirare l'NLB e di presentare un indirizzo IP di origine falsificato.

Completa i tre passaggi seguenti per abilitare l'applicazione senza rifiutare alcuna connessione. Questo ordine evita i tempi di inattività della migrazione.

Passaggio 1: abilitare il protocollo PROXY v2 sul gruppo target NLB

Attivare il proxy_protocol_v2.enabled attributo sul gruppo target NLB che punta all'endpoint VPC del server. Questo attributo indica all'NLB di anteporre un'intestazione PPv2 a ogni connessione. Per istruzioni, vedere Protocollo proxy per il Network Load Balancer nel Guida per l'utente di Elastic Load Balancing.

Mentre il server è impostato su SftpMode=NONE, accetta connessioni con o senza un'intestazione PPv2.

Nota

Alcuni client SSH attendono di ricevere la stringa di identificazione SSH del server prima di inviare la propria. Quando si abilita il protocollo PROXY v2, questi client non riescono a completare la connessione. Prima di abilitare il protocollo PROXY v2, verificate che i client degli utenti inviino prima la stringa di identificazione. Per informazioni dettagliate, vedi Compatibilità del client SSH con il protocollo PROXY v2.

Passaggio 2: verifica che l'intestazione arrivi a ogni connessione

Prima di applicare il protocollo PPv2, verificate che il server riceva un'intestazione PPv2 su ogni connessione. Controllate i log del vostro server per verificare la presenza di CONNECTED tipo di attività. Nei log strutturati (JSON) in Amazon CloudWatch Registri, controlla proxy-protocol-v2-header campo per il valore ignored. Nei registri precedenti, seleziona ProxyProtocolV2Header campo con lo stesso valore.

Il campo ha la seguente semantica:

  • Il campo è assente quando la connessione non include un'intestazione PPv2.

  • Il valore è ignored quando la connessione includeva un'intestazione PPv2 mentre SftpMode è NONE.

  • Il valore è applied quando la connessione includeva un'intestazione PPv2 e il server l'ha rispettata PROXY_PROTOCOL_V2_ENFORCED.

Continua a controllare i registri fino a ogni CONNECTED entry riporta il campo con il valore ignored. Un campo assente indica che un percorso raggiunge ancora il server senza un'intestazione PPv2. Se lo applichi mentre manca l'intestazione in un percorso, il server rifiuta tali connessioni. Per ulteriori informazioni su questi campi di registro, consulta Log strutturati JSON per Transfer Family e Log precedenti per Transfer Family.

Fase 3: Applica il protocollo PROXY v2

Aggiorna il server in modo che SftpMode membro di ProxyConfig è PROXY_PROTOCOL_V2_ENFORCED. Il server richiede quindi un'intestazione PPv2 valida su ogni connessione SFTP in entrata. Il server rifiuta le connessioni che arrivano senza un'intestazione PPv2 valida e registra un errore su Amazon CloudWatch Registri. Per eseguire il rollback, imposta SftpMode a NONE.

Console

Sul Dettagli del server pagina, scegli Modifica accanto a Dettagli aggiuntivi, quindi accendi il configurazione del protocollo PROXY opzione. Per la procedura completa di modifica del server, vedere Modifica i dettagli del server.

AWS CLI

Esegui il seguente comando per applicare il protocollo PROXY v2 sul tuo server.

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

In caso di successo, il comando restituisce il codice seguente e aggiorna il server.

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