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à.
Ascoltatori per Application Load Balancer
Un ascoltatore è un processo che controlla le richieste di connessione utilizzando il protocollo e la porta configurata. Prima di iniziare a utilizzare l'Application Load Balancer, è necessario aggiungere almeno un ascoltatore. Se il sistema di bilanciamento del carico non ha un ascoltatore, non può ricevere traffico dai client. Le regole che definisci per i tuoi listener determinano il modo in cui il load balancer indirizza le richieste alle destinazioni registrate, ad esempio le EC2 istanze.
Indice
- Configurazione dei listener
- Regole dei listener
- Tipi di operazioni delle regole
- Tipi di condizioni della regola
- Intestazioni X-Forwarded
- Crea un ascoltatore HTTP
- SSLcertificati
- Policy di sicurezza
- Crea un ascoltatore HTTPS
- Aggiornare le regole dell'ascoltatore
- Aggiorna un listener HTTPS
- Autenticazione reciproca TLS
- Configurazione dell'autenticazione utente
- Assegna un tag a un ascoltatore
- Eliminazione di un listener
Configurazione dei listener
I listener supportano i seguenti protocolli e porte:
-
Protocolli:, HTTP HTTPS
-
Porte: 1-65535
È possibile utilizzare un HTTPS listener per affidare il lavoro di crittografia e decrittografia al sistema di bilanciamento del carico, in modo che le applicazioni possano concentrarsi sulla propria logica di business. Se il protocollo listener lo èHTTPS, è necessario distribuire almeno un certificato server sul listener. SSL Per ulteriori informazioni, consulta Crea un HTTPS listener per il tuo Application Load Balancer.
Se devi assicurarti che le destinazioni decrittografino il HTTPS traffico anziché il load balancer, puoi creare un Network Load Balancer con TCP un listener sulla porta 443. Con un TCP listener, il load balancer trasmette il traffico crittografato alle destinazioni senza decrittografarlo. Per ulteriori informazioni, consulta la Guida per l'utente dei Network Load Balancer.
Gli Application Load Balancer forniscono supporto nativo per. WebSockets È possibile aggiornare una connessione HTTP /1.1 esistente in una WebSocket (ws
owss
) connessione utilizzando un HTTP aggiornamento della connessione. Quando si esegue l'aggiornamento, la TCP connessione utilizzata per le richieste (al sistema di bilanciamento del carico e alla destinazione) diventa una WebSocket connessione persistente tra il client e la destinazione tramite il sistema di bilanciamento del carico. È possibile utilizzare sia WebSockets con gli ascoltatori che con gli HTTP ascoltatoriHTTPS. Le opzioni che scegli per il tuo listener si applicano sia alle WebSocket connessioni che al HTTP traffico. Per ulteriori informazioni, consulta How the WebSocket Protocol Works nella Amazon CloudFront Developer Guide.
Gli Application Load Balancer forniscono supporto nativo per HTTP /2 con listener. HTTPS È possibile inviare fino a 128 richieste in parallelo utilizzando una connessione HTTP /2. È possibile utilizzare la versione del protocollo per inviare la richiesta alle destinazioni utilizzando /2. HTTP Per ulteriori informazioni, consulta Versione del protocollo. Poiché HTTP /2 utilizza le connessioni front-end in modo più efficiente, potresti notare un minor numero di connessioni tra i client e il sistema di bilanciamento del carico. Non è possibile utilizzare la funzionalità server-push di /2. HTTP
Per ulteriori informazioni, consulta Routing della richiesta nella Guida per l'utente di Elastic Load Balancing.
Regole dei listener
Ogni ascoltatore ha un'operazione predefinita, nota anche come regola predefinita. La regola predefinita non può essere eliminata ed è sempre eseguita per ultima. È possibile creare regole aggiuntive e consistono in una priorità, una o più operazioni e una o più condizioni. Puoi aggiungere o modificare le regole in qualsiasi momento. Per ulteriori informazioni, consulta Modificare una regola.
Regole predefinite
Le operazioni per la regola predefinita vengono definite al momento della creazione del listener. Le regole predefinite non possono avere condizioni. Se non viene soddisfatta nessuna condizione per qualsiasi regola del listener, viene eseguita l'operazione per la regola predefinita.
Di seguito è riportato un esempio di una regola predefinita come illustrato nella console:
Priorità regola
Ogni regola ha una priorità. Le regole vengono valutate in base all'ordine di priorità, dal valore più basso a quello più alto. La regola predefinita è valutata per ultima. È possibile modificare la priorità di una regola non predefinita in qualsiasi momento. Non è possibile modificare la priorità della regola di default. Per ulteriori informazioni, consulta Aggiornare la priorità delle regole.
Operazioni delle regole
Ogni operazione della regola dispone di un tipo, di una priorità e delle informazioni necessarie per eseguire l'operazione. Per ulteriori informazioni, consulta Tipi di operazioni delle regole.
Condizioni della regola
Ogni condizione della regola ha informazioni su tipo e configurazione. Quando le condizioni di una regola vengono soddisfatte, l'operazione viene eseguita. Per ulteriori informazioni, consulta Tipi di condizioni della regola.
Tipi di operazioni delle regole
I tipi di operazione supportati per una regola dell'ascoltatore sono i seguenti:
authenticate-cognito
-
[HTTPSascoltatori] Usa Amazon Cognito per autenticare gli utenti. Per ulteriori informazioni, consulta Autenticazione degli utenti tramite Application Load Balancer.
authenticate-oidc
-
[HTTPSlisteners] Utilizzate un provider di identità conforme a OpenID Connect OIDC () per autenticare gli utenti.
fixed-response
-
Restituisce una risposta personalizzata. HTTP Per ulteriori informazioni, consulta Operazioni con risposta fissa.
forward
-
Inoltrare le richieste verso il gruppo di destinazioni indicato. Per ulteriori informazioni, consulta Operazioni di inoltro.
redirect
-
Reindirizza le richieste da una URL all'altra. Per ulteriori informazioni, consulta Operazioni di reindirizzamento.
Viene eseguita per prima l'operazione con priorità minore. Ogni regola deve includere esattamente una delle seguenti operazioni: forward
, redirect
o fixed-response
e deve essere l’ultima operazione da eseguire.
Se la versione del protocollo è g RPC o HTTP /2, le uniche azioni supportate sono forward
le azioni.
Operazioni con risposta fissa
È possibile utilizzare fixed-response
le azioni per eliminare le richieste dei client e restituire una HTTP risposta personalizzata. È possibile utilizzare questa operazione per inviare un codice di risposta 2XX, 4XX o 5XX e un messaggio opzionale.
Quando viene intrapresa un'fixed-response
azione, l'azione e la destinazione URL del reindirizzamento vengono registrate nei log di accesso. Per ulteriori informazioni, consulta Voci dei log di accesso. Il conteggio delle operazioni fixed-response
avvenute con successo viene segnalato dal parametro HTTP_Fixed_Response_Count
. Per ulteriori informazioni, consulta Parametri di Application Load Balancer.
Esempio di azione a risposta fissa per AWS CLI
Puoi specificare un’operazione quando crei o modifichi una regola. Per ulteriori informazioni consulta i comandi create-rule e modify-rule. Le seguenti operazioni inviano una risposta fissa con il codice di stato specificato e il corpo del messaggio.
[ { "Type": "fixed-response", "FixedResponseConfig": { "StatusCode": "200", "ContentType": "text/plain", "MessageBody": "Hello world" } } ]
Operazioni di inoltro
È possibile utilizzare le operazioni forward
per instradare le richieste a uno o più gruppi di destinazioni. Se si specificano più gruppi di destinazioni per un'operazione forward
, è necessario specificare un peso per ciascun gruppo di destinazioni. Ogni peso del gruppo di destinazioni è un valore compreso tra 0 e 999. Le richieste che corrispondono a una regola del listener con gruppi di destinazioni ponderati vengono distribuite a questi gruppi di destinazioni in base ai rispettivi pesi. Ad esempio, se specifichi due gruppi di destinazioni, ciascuno con un peso di 10, ogni gruppo di destinazioni riceve la metà delle richieste. Se specifichi due gruppi di destinazioni, uno con un peso di 10 e l'altro con un peso di 20, il gruppo di destinazioni con un peso di 20 riceve il doppio delle richieste rispetto all'altro gruppo di destinazioni.
Per impostazione predefinita, la configurazione di una regola per distribuire il traffico tra gruppi di destinazioni ponderati non garantisce che le sticky session vengano rispettate. Per garantire che le sticky session siano rispettate, abilitare la persistenza del gruppo di destinazioni per la regola. Quando il load balancer indirizza per la prima volta una richiesta a un gruppo target ponderato, genera un cookie denominato AWSALBTG che codifica le informazioni sul gruppo target selezionato, crittografa il cookie e include il cookie nella risposta al client. Il client deve includere il cookie ricevuto nelle richieste successive al sistema di bilanciamento del carico. Quando il sistema di bilanciamento del carico riceve una richiesta che corrisponde a una regola con la persistenza del gruppo di destinazioni abilitata e contiene il cookie, la richiesta viene instradata al gruppo di destinazioni specificato nel cookie.
Gli Application Load Balancer non supportano i valori dei cookie codificati. URL
Con le richieste CORS (condivisione di risorse tra origini), alcuni browser richiedono SameSite=None; Secure
l'attivazione della viscosità. In questo caso, Elastic Load Balancing genera un secondo cookie AWSALBTGCORS, che include le stesse informazioni dello stickiness cookie originale più questo attributo. SameSite
I clienti ricevono entrambi i cookie.
Esempio di operazione di inoltro con un gruppo di destinazioni
Puoi specificare un’operazione quando crei o modifichi una regola. Per ulteriori informazioni consulta i comandi create-rule e modify-rule. La seguente operazione inoltra le richieste al gruppo di destinazioni specificato.
[ { "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": "arn:aws:elasticloadbalancing:
us-west-2
:123456789012
:targetgroup/my-targets
/73e2d6bc24d8a067
" } ] } } ]
Esempio di operazione di inoltro con due gruppi di destinazioni ponderati
L'operazione seguente inoltra le richieste ai due gruppi di destinazioni specificati, in base al peso di ciascun gruppo di destinazioni.
[ { "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": "arn:aws:elasticloadbalancing:
us-west-2
:123456789012
:targetgroup/blue-targets
/73e2d6bc24d8a067
", "Weight": 10 }, { "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2
:123456789012
:targetgroup/green-targets
/09966783158cda59
", "Weight": 20 } ] } } ]
Esempio di operazione di inoltro con persistenza abilitata
Se si dispone di un'operazione di inoltro con più gruppi di destinazioni e per uno o più gruppi di destinazioni sono abilitate le sessioni permanenti, è necessario abilitare la persistenza del gruppo di destinazioni.
L'operazione seguente inoltra le richieste ai due gruppi di destinazioni specificati, con la persistenza del gruppo di destinazioni abilitata. Le richieste che non contengono il cookie AWSALBTG vengono instradate in base al peso di ciascun gruppo di destinazioni.
[ { "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": "arn:aws:elasticloadbalancing:
us-west-2
:123456789012
:targetgroup/blue-targets
/73e2d6bc24d8a067
", "Weight": 10 }, { "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2
:123456789012
:targetgroup/green-targets
/09966783158cda59
", "Weight": 20 } ], "TargetGroupStickinessConfig": { "Enabled": true, "DurationSeconds": 1000 } } } ]
Operazioni di reindirizzamento
È possibile utilizzare redirect
le azioni per reindirizzare le richieste dei client da una all'altraURL. Puoi configurare i reindirizzamenti come temporanei (HTTP302) o permanenti (HTTP301) in base alle tue esigenze.
A URI è costituito dai seguenti componenti:
protocol
://hostname
:port
/path
?query
È necessario modificare almeno uno dei componenti seguenti per evitare un reindirizzamento loop: protocollo, nome host, porta o percorso. I componenti che non vengono modificati mantengono i loro valori originali.
- protocol
-
Il protocollo (HTTPoHTTPS). È possibile HTTP reindirizzare verso HTTPHTTPS, HTTP verso e HTTPS versoHTTPS. Non è possibile reindirizzare HTTPS a. HTTP
- hostname
-
Il nome host. Il nome host non prevede la distinzione tra lettere maiuscole e minuscole, può contenere fino a 128 caratteri di lunghezza e può contenere caratteri alfanumerici, caratteri jolly (* e ?) e trattini (-).
- port
-
La porta (da 1 a 65535).
- path
-
Il percorso assoluto, partendo da "/". Il percorso prevede la distinzione tra lettere maiuscole e minuscole, può contenere fino a 128 caratteri di lunghezza e può contenere caratteri alfanumerici, caratteri jolly (* e ?), & (con &) e i seguenti caratteri speciali: _-.$/~"'@:+
- query
-
I parametri di query La lunghezza massima è 128 caratteri.
È possibile riutilizzare URI i componenti dell'originale URL nella destinazione URL utilizzando le seguenti parole chiave riservate:
-
#{protocol}
- Mantiene il protocollo. Utilizzare nel protocollo e nei componenti query. -
#{host}
- Mantiene il dominio. Utilizzare nel nome host, nel percorso e nei componenti query. -
#{port}
- Mantiene la porta. Utilizzare nella porta, nel percorso e nei componenti query. -
#{path}
- Mantiene il percorso. Utilizzare nel percorso e nei componenti query. -
#{query}
- Mantiene i parametri di query. Utilizzare nel componente query.
Quando viene eseguita un'operazione redirect
, l'operazione viene registrata nei log di accesso. Per ulteriori informazioni, consulta Voci dei log di accesso. Il conteggio delle operazioni redirect
avvenute con successo viene segnalato dal parametro HTTP_Redirect_Count
. Per ulteriori informazioni, consulta Parametri di Application Load Balancer.
Esempio di operazioni di reindirizzamento tramite la console
La regola seguente imposta un reindirizzamento permanente a un URL che utilizza il HTTPS protocollo e la porta specificata (40443), ma mantiene il nome host, il percorso e i parametri di query originali. Questa schermata è equivalente a "https://#{host}:40443/#{path}?#{query}".
La regola seguente imposta un reindirizzamento permanente a un URL che mantiene il protocollo, la porta, il nome host e i parametri di query originali e utilizza la parola chiave per creare un percorso modificato. #{path}
Questa schermata è equivalente a "#{protocol}://#{host}:#{port}/new/#{path}?#{query}".
Esempio di azione di reindirizzamento per AWS CLI
Puoi specificare un’operazione quando crei o modifichi una regola. Per ulteriori informazioni consulta i comandi create-rule e modify-rule. L'azione seguente reindirizza una HTTP richiesta a una HTTPS richiesta sulla porta 443, con lo stesso nome host, percorso e stringa di query della richiesta. HTTP
[ { "Type": "redirect", "RedirectConfig": { "Protocol": "HTTPS", "Port": "443", "Host": "#{host}", "Path": "/#{path}", "Query": "#{query}", "StatusCode": "HTTP_301" } } ]
Tipi di condizioni della regola
I tipi di operazione supportati per una regola sono i seguenti:
host-header
-
Instradamento basato sul nome host di ogni richiesta. Per ulteriori informazioni, consulta Condizioni host.
http-header
-
Percorso basato sulle HTTP intestazioni di ogni richiesta. Per ulteriori informazioni, consulta HTTPcondizioni dell'intestazione.
http-request-method
-
Percorso basato sul metodo di HTTP richiesta di ogni richiesta. Per ulteriori informazioni, consulta HTTPcondizioni del metodo di richiesta.
path-pattern
-
Percorso basato sui modelli di percorso della richiestaURLs. Per ulteriori informazioni, consulta Condizioni percorso.
query-string
-
Instradamento basato su coppie chiave/valore nelle stringhe di query. Per ulteriori informazioni, consulta Condizioni delle stringhe di query.
source-ip
-
Instradamento basato sull’indirizzo IP di origine di ogni richiesta. Per ulteriori informazioni, consulta Condizioni indirizzo IP di origine.
Ogni regola può facoltativamente includere al massimo una delle seguenti condizioni: host-header
, http-request-method
, path-pattern
e source-ip
. Ogni regola può anche includere facoltativamente una o più delle seguenti condizioni: http-header
e query-string
.
Puoi specificare fino a tre valutazioni di corrispondenze per condizione. Ad esempio, per ogni http-header
condizione, puoi specificare fino a tre stringhe da confrontare con il valore dell'HTTPintestazione nella richiesta. La condizione è soddisfatta se una delle stringhe corrisponde al valore dell'intestazione. HTTP Per fare in modo che tutte le stringhe siano una corrispondenza, crea una condizione per valutazione di corrispondenza.
Puoi specificare fino a cinque valutazioni di corrispondenze per regola. Ad esempio, puoi creare una regola con cinque condizioni in cui ogni condizione ha una valutazione di corrispondenza.
Nelel valutazioni di corripondenza è possibile includere caratteri jolly per le condizioni http-header
,host-header
, path-pattern
e query-string
. Esiste un limite di cinque caratteri jolly per regola.
Le regole vengono applicate solo ai ASCII caratteri visibili; i caratteri di controllo (da 0x00 a 0x1f e 0x7f) sono esclusi.
Per le demo, consulta Instradamento avanzato delle richieste
HTTPcondizioni dell'intestazione
È possibile utilizzare le condizioni di HTTP intestazione per configurare le regole che instradano le richieste in base alle HTTP intestazioni della richiesta. È possibile specificare i nomi dei campi di HTTP intestazione standard o personalizzati. Il nome dell'intestazione e la valutazione della corrispondenza non fanno distinzione tra lettere maiuscole e minuscole. I seguenti caratteri jolly sono supportati nelle stringhe di confronto: * (corrisponde a 0 o a più caratteri) e ? (corrisponde esattamente a 1 carattere). I caratteri jolly non sono supportati nel nome dell’intestazione.
Esempio di condizione di HTTP intestazione per AWS CLI
Puoi specificare le condizioni quando crei o modifichi una regola. Per ulteriori informazioni consulta i comandi create-rule e modify-rule. La seguente condizione è soddisfatta dalle richieste con un’intestazione Utente-Agente che corrisponde a una delle stringhe specificate.
[ { "Field": "http-header", "HttpHeaderConfig": { "HttpHeaderName": "User-Agent", "Values": ["*Chrome*", "*Safari*"] } } ]
HTTPcondizioni del metodo di richiesta
È possibile utilizzare le condizioni del metodo di HTTP richiesta per configurare le regole che instradano le richieste in base al HTTP metodo di richiesta della richiesta. È possibile specificare HTTP metodi standard o personalizzati. La valutazione della corrispondenza prevede la distinzione tra lettere maiuscole e minuscole. I caratteri jolly non sono supportati; pertanto, il nome del metodo deve essere una corrispondenza esatta.
È consigliabile effettuare l'instradamento GET e HEAD le richieste nello stesso modo, poiché la risposta a una HEAD richiesta può essere memorizzata nella cache.
Esempio HTTP di condizione del metodo per AWS CLI
Puoi specificare le condizioni quando crei o modifichi una regola. Per ulteriori informazioni consulta i comandi create-rule e modify-rule. La condizione seguente è soddisfatta dalle richieste che utilizzano il metodo specificato.
[ { "Field": "http-request-method", "HttpRequestMethodConfig": { "Values": ["CUSTOM-METHOD"] } } ]
Condizioni host
È possibile utilizzare le condizioni host per definire regole in grado di inoltrare le richieste in base al nome host nell'intestazione host (noto anche come instradamento basato su host). In questo modo è possibile supportare più sottodomini e domini di primo livello diversi utilizzando un singolo sistema di bilanciamento del carico.
Un nome host non distingue tra maiuscole e minuscole, può avere una lunghezza massima di 128 caratteri e contenere qualsiasi carattere tra i seguenti:
-
A-Z, a-z, 0-9
-
- .
-
* (corrisponde a 0 o più caratteri)
-
? (corrisponde esattamente a 1 carattere)
Si deve includere il carattere "." almeno una volta. Dopo l'ultimo carattere "." è possibile includere solo caratteri alfabetici.
Esempio di nomi host
-
example.com
-
test.example.com
-
*.example.com
La regola *.example.com
si applica a test.example.com
ma non a example.com
.
Esempio di condizione di intestazione dell'host per AWS CLI
Puoi specificare le condizioni quando crei o modifichi una regola. Per ulteriori informazioni consulta i comandi create-rule e modify-rule. La seguente condizione è soddisfatta dalle richieste con un’intestazione host che corrisponde alla stringa specificata.
[ { "Field": "host-header", "HostHeaderConfig": { "Values": ["*.example.com"] } } ]
Condizioni percorso
È possibile utilizzare le condizioni del percorso per definire regole che instradano le richieste in base a quanto URL contenuto nella richiesta (noto anche come routing basato sul percorso).
Il modello di percorso viene applicato solo al percorso diURL, non ai relativi parametri di query. Viene applicato solo ai ASCII caratteri visibili; i caratteri di controllo (da 0x00 a 0x1f e 0x7f) sono esclusi.
La valutazione della regola viene eseguita solo dopo la normalizzazione. URI
Un modello di percorso non distingue tra maiuscole e minuscole, può avere una lunghezza massima di 128 caratteri e contenere qualsiasi carattere tra i seguenti.
-
A-Z, a-z, 0-9
-
_ - . $ / ~ " ' @ : +
-
& (utilizzo di &)
-
* (corrisponde a 0 o più caratteri)
-
? (corrisponde esattamente a 1 carattere)
Se la versione del protocollo è gRPC, le condizioni possono essere specifiche di un pacchetto, servizio o metodo.
Esempi di modelli di HTTP percorso
-
/img/*
-
/img/*/pics
Esempio di modelli di RPC percorso g
-
/package
-
/package.service
-
/package.service/method
Il modello di percorso viene utilizzato per instradare le richieste, ma non le modifica. Ad esempio, se una regola ha un modello di percorso /img/*
, la regola inoltra una richiesta per /img/picture.jpg
al gruppo target specificato come una richiesta per /img/picture.jpg
.
Esempio di condizione del modello di percorso per AWS CLI
Puoi specificare le condizioni quando crei o modifichi una regola. Per ulteriori informazioni consulta i comandi create-rule e modify-rule. La seguente condizione è soddisfatta dalle richieste con un URL che contiene la stringa specificata.
[ { "Field": "path-pattern", "PathPatternConfig": { "Values": ["/img/*"] } } ]
Condizioni delle stringhe di query
Puoi usare le condizioni delle stringhe di query per configurare le regole che instradano le richeste in base alle coppie chiave/valore o i valori nella stringa di query. La valutazione della corrispondenza non prevede la distinzione tra lettere maiuscole e minuscole. I seguenti caratteri jolly sono supportati: * (corrisponde a 0 o a più caratteri) e ? (corrisponde esattamente a 1 carattere).
Esempio di condizione della stringa di query per AWS CLI
Puoi specificare le condizioni quando crei o modifichi una regola. Per ulteriori informazioni consulta i comandi create-rule e modify-rule. La seguente condizione è soddisfatta dalle richieste con una stringa di query che include una coppia chiave/valore di "version=v1" o un set di chiavi impostato su “example”.
[ { "Field": "query-string", "QueryStringConfig": { "Values": [ { "Key": "version", "Value": "v1" }, { "Value": "*example*" } ] } } ]
Condizioni indirizzo IP di origine
Puoi usare le condizioni dell’indirizzo IP di origine per configurare le regole che instradano le richieste in base all’indirizzo IP di origine della richiesta. L'indirizzo IP deve essere specificato nel CIDR formato. È possibile utilizzare entrambi IPv4 gli IPv6 indirizzi. I caratteri jolly non sono supportati. Non è possibile specificare 255.255.255.255/32
CIDR la condizione della regola IP di origine.
Se un client è al di là di un proxy, si tratta dell'indirizzo IP del proxy, non dell'indirizzo IP del client.
Questa condizione non è soddisfatta dagli indirizzi nell' X-Forwarded-Forintestazione. Per cercare gli indirizzi nell' X-Forwarded-Forintestazione, utilizza una http-header
condizione.
Esempio di condizione IP di origine per AWS CLI
Puoi specificare le condizioni quando crei o modifichi una regola. Per ulteriori informazioni consulta i comandi create-rule e modify-rule. La seguente condizione è soddisfatta dalle richieste con un indirizzo IP di origine in uno dei CIDR blocchi specificati.
[ { "Field": "source-ip", "SourceIpConfig": { "Values": ["192.0.2.0/24", "198.51.100.10/32"] } } ]
HTTPheader e Application Load Balancer
HTTPle richieste e HTTP le risposte utilizzano i campi di intestazione per inviare informazioni sui messaggi. HTTP HTTPle intestazioni vengono aggiunte automaticamente. I campi intestazione sono costituti da coppie nome-valore separati da due punti e intervallati da un ritorno a capo e un avanzamento riga. Un set standard di campi di HTTP intestazione è definito in RFC 2616, Message Headers.X-Forwarded
Gli Application Load Balancer supportano le seguenti intestazioni X-Forwarded
.
Per ulteriori informazioni sulle HTTP connessioni, consulta Request routing nella Elastic Load Balancing User Guide.
Intestazioni X-Forwarded
X-Forwarded-For
L'intestazione della X-Forwarded-For
richiesta consente di identificare l'indirizzo IP di un client quando si utilizza un sistema di bilanciamento del carico HTTP oHTTPS. Poiché i sistemi di bilanciamento del carico intercettano il traffico tra client e server, i log di accesso al server contengono solo l'indirizzo IP del sistema di bilanciamento del carico. Per visualizzare l'indirizzo IP del client, utilizza l'attributo routing.http.xff_header_processing.mode
. Questo attributo consente di modificare, conservare o rimuovere l'X-Forwarded-For
intestazione nella HTTP richiesta prima che Application Load Balancer invii la richiesta alla destinazione. I valori possibili per questo attributo sono append
, preserve
e remove
. Il valore predefinito per questo attributo è append
.
Importante
L'X-Forwarded-For
intestazione deve essere utilizzata con cautela a causa dei potenziali rischi per la sicurezza. Le voci possono essere considerate affidabili solo se aggiunte da sistemi adeguatamente protetti all'interno della rete.
Append
Per impostazione predefinita, Application Load Balancer memorizza l'indirizzo IP del client nell'intestazione della richiesta X-Forwarded-For
e passa l'intestazione al server. Se l'intestazione della richiesta X-Forwarded-For
non è inclusa nella richiesta originale, il sistema di bilanciamento del carico ne crea una con l'indirizzo IP del client come valore della richiesta. In caso contrario, il load balancer aggiunge l'indirizzo IP del client all'intestazione esistente e quindi passa l'intestazione al server. L'intestazione della richiesta X-Forwarded-For
può contenere più indirizzi IP separati da virgole.
L'intestazione della richiesta X-Forwarded-For
assume la seguente forma:
X-Forwarded-For: client-ip-address
Di seguito è riportata un'intestazione della richiesta X-Forwarded-For
di esempio per un client con l'indirizzo IP 203.0.113.7
.
X-Forwarded-For: 203.0.113.7
Di seguito è riportato un esempio di intestazione di X-Forwarded-For
richiesta per un client con un indirizzo di. IPv6 2001:DB8::21f:5bff:febf:ce22:8a2e
X-Forwarded-For: 2001:DB8::21f:5bff:febf:ce22:8a2e
Quando l'attributo di conservazione della porta del client (routing.http.xff_client_port.enabled
) è abilitato nel sistema di bilanciamento del carico, l'intestazione della richiesta X-Forwarded-For
include il client-port-number
aggiunto al client-ip-address
, separato da due punti. L'intestazione assume così la seguente forma:
IPv4 -- X-Forwarded-For: client-ip-address
:client-port-number
IPv6 -- X-Forwarded-For: [client-ip-address]
:client-port-number
Si noti IPv6 infatti che quando il sistema di bilanciamento del carico aggiunge il client-ip-address
all'intestazione esistente, racchiude l'indirizzo tra parentesi quadre.
Di seguito è riportato un esempio di intestazione di X-Forwarded-For
richiesta per un client con un IPv4 indirizzo e un numero di porta di. 12.34.56.78
8080
X-Forwarded-For: 12.34.56.78:8080
Di seguito è riportato un esempio di intestazione di X-Forwarded-For
richiesta per un client con un IPv6 indirizzo 2001:db8:85a3:8d3:1319:8a2e:370:7348
e un numero di porta di. 8080
X-Forwarded-For: [2001:db8:85a3:8d3:1319:8a2e:370:7348]:8080
Preserve
La preserve
modalità dell'attributo garantisce che l'X-Forwarded-For
intestazione della HTTP richiesta non venga modificata in alcun modo prima di essere inviata alle destinazioni.
Rimuovi
La remove
modalità dell'attributo rimuove l'X-Forwarded-For
intestazione nella HTTP richiesta prima che venga inviata ai target.
Nota
Se si abilita l'attributo di conservazione della porta del client (routing.http.xff_client_port.enabled
) e inoltre si seleziona preserve
o remove
per l'attributo routing.http.xff_header_processing.mode
, l'Application Load Balancer sovrascrive l'attributo di conservazione della porta del client. Mantiene l'intestazione X-Forwarded-For
invariata o la rimuove, a seconda della modalità selezionata, prima di inviarla alle destinazioni.
La tabella seguente mostra esempi dell'intestazione X-Forwarded-For
che la destinazione riceve quando si seleziona la modalità append
, preserve
o remove
. In questo esempio, l'indirizzo IP dell'ultimo hop è 127.0.0.1
.
Descrizione della richiesta |
Richiesta di esempio |
XFFin modalità append |
XFFin preserve modalità |
XFFin remove modalità |
---|---|---|---|---|
La richiesta viene inviata senza XFF intestazione | GET /index.html HTTP/1.1 Host: example.com |
X-Forwarded-For: 127.0.0.1 |
Non presente | Non presente |
La richiesta viene inviata con un'XFFintestazione e un indirizzo IP del client. | GET /index.html HTTP/1.1 Host: example.com X-Forwarded-For:
127.0.0.4 |
X-Forwarded-For: 127.0.0.4, 127.0.0.1 |
X-Forwarded-For: 127.0.0.4 |
Non presente |
La richiesta viene inviata con un'XFFintestazione con più indirizzi IP del client. | GET /index.html HTTP/1.1 Host: example.com X-Forwarded-For:
127.0.0.4, 127.0.0.8 |
X-Forwarded-For: 127.0.0.4, 127.0.0.8,
127.0.0.1 |
X-Forwarded-For: 127.0.0.4, 127.0.0.8 |
Non presente |
Per modificare, conservare o rimuovere X-Forwarded-For header utilizzando la console
Apri la EC2 console Amazon all'indirizzo https://console.aws.amazon.com/ec2/
. -
Seleziona Sistemi di bilanciamento del carico nel riquadro di navigazione.
-
Selezionare il load balancer.
-
Nella scheda Attributi, scegli Modifica.
-
Nella sezione Configurazione del traffico, in Gestione dei pacchetti, per l'X-Forwarded-For intestazione scegli Aggiungi (impostazione predefinita), Conserva o Rimuovi.
-
Scegli Save changes (Salva modifiche).
Per modificare, conservare o rimuovere X-Forwarded-For intestazione utilizzando il AWS CLI
Usa il modify-load-balancer-attributescomando con l'routing.http.xff_header_processing.mode
attributo.
X-Forwarded-Proto
L'intestazione della X-Forwarded-Proto
richiesta consente di identificare il protocollo (HTTPoHTTPS) utilizzato da un client per connettersi al sistema di bilanciamento del carico. I log di accesso al server contengono solo il protocollo utilizzato tra il server e il load balancer; non contengono informazioni sul protocollo utilizzato tra il client e il load balancer. Per determinare il protocollo utilizzato tra il client e il load balancer, utilizzare l'intestazione della richiesta X-Forwarded-Proto
. Elastic Load Balancing archivia il protocollo utilizzato tra il client e il load balancer nell'intestazione della richiesta X-Forwarded-Proto
e passa l'intestazione al server.
L'applicazione o il sito Web possono utilizzare il protocollo memorizzato nell'intestazione della X-Forwarded-Proto
richiesta per fornire una risposta che reindirizza a quella appropriata. URL
L'intestazione della richiesta X-Forwarded-Proto
assume la seguente forma:
X-Forwarded-Proto: originatingProtocol
L'esempio seguente contiene un'intestazione di X-Forwarded-Proto
richiesta per una richiesta proveniente dal client come richiesta: HTTPS
X-Forwarded-Proto: https
X-Forwarded-Port
L'intestazione della richiesta X-Forwarded-Port
consente di identificare la porta di destinazione utilizzata dal client per connettersi al load balancer.