Questa pagina descrive il funzionamento delle intestazioni personalizzate nelle mappe URL utilizzate dai bilanciatori del carico delle applicazioni interni a livello di regione e dai bilanciatori del carico delle applicazioni interni tra regioni.
Le intestazioni delle richieste e delle risposte personalizzate ti consentono di specificare intestazioni aggiuntive che il bilanciatore del carico può aggiungere alle richieste e alle risposte HTTP(S). A seconda delle informazioni rilevate dal bilanciatore del carico, queste intestazioni possono includere le seguenti informazioni:
- Latenza del client
Parametri della connessione TLS
Prima di iniziare
Se necessario, esegui l'aggiornamento all'ultima versione di Google Cloud CLI:
gcloud components update
Come funzionano le intestazioni personalizzate
Le intestazioni personalizzate funzionano nel seguente modo:
Quando il bilanciatore del carico effettua una richiesta al backend, aggiunge le intestazioni della richiesta.
Il bilanciatore del carico aggiunge intestazioni delle richieste personalizzate solo alle richieste dei client, non ai probe di controllo di integrità. Se il backend richiede un'intestazione specifica per l'autorizzazione che non è presente nel pacchetto di controllo di integrità, il controllo di integrità potrebbe non riuscire.
Il bilanciatore del carico imposta le intestazioni delle risposte prima di restituire una risposta al client.
Per attivare le intestazioni personalizzate per i bilanciatori del carico delle applicazioni interni a livello di regione e i bilanciatori del carico delle applicazioni interni tra regioni, devi specificare un elenco di nomi e valori di intestazione nel file di configurazione della mappa URL.
I nomi delle intestazioni devono avere le seguenti proprietà:
- Il nome dell'intestazione deve essere una definizione valida del nome del campo di intestazione HTTP secondo RFC 7230.
- Il nome dell'intestazione non deve essere
X-User-IP. - Il nome dell'intestazione non deve iniziare con
X-Google,X-Goog-,X-GFEoX-Amz-. - Non devono essere utilizzate le seguenti intestazioni hop-by-hop:
Keep-Alive,Transfer-Encoding,TE,Connection,TrailereUpgrade. In conformità con RFC 2616, queste intestazioni non vengono archiviate dalle cache né propagate dai proxy di destinazione. - Il nome dell'intestazione non deve essere
Hostoauthority. SiaHostcheauthoritysono parole chiave speciali riservate da Google Cloud. Non puoi modificare queste intestazioni per i bilanciatori del carico basati su Envoy. Ti consigliamo invece di creare altre intestazioni personalizzate (ad esempio,MyHost) in modo da non interferire con i nomi delle intestazioni riservate. - Un nome di intestazione non deve essere visualizzato più di una volta nell'elenco delle intestazioni.
I nomi delle intestazioni non fanno distinzione tra maiuscole e minuscole. Quando i nomi delle intestazioni vengono passati a un backend HTTP/2, il protocollo HTTP/2 li codifica in lettere minuscole.
I valori delle intestazioni devono avere le seguenti proprietà:
- Il valore dell'intestazione deve essere una definizione valida del campo di intestazione HTTP secondo RFC 7230, con le forme obsolete non consentite.
- Il valore dell'intestazione non può essere vuoto. Le intestazioni vuote vengono rifiutate.
- Il valore dell'intestazione può includere una o più variabili, racchiuse tra parentesi graffe, che si espandono ai valori forniti dal bilanciatore del carico. Per un elenco completo delle variabili consentite nel valore dell'intestazione, consulta Variabili che possono essere visualizzate nel valore dell'intestazione.
Nei valori delle intestazioni, gli spazi vuoti iniziali e finali non sono significativi e non vengono passati al backend. Per consentire le parentesi graffe nei valori delle intestazioni,
il bilanciatore del carico interpreta due parentesi graffe aperte ({{) come
una singola parentesi graffa aperta ({) e due parentesi graffe chiuse (}}) come una singola
parentesi graffa chiusa (}).
Aggiungere intestazioni delle richieste o delle risposte
Per aggiungere intestazioni delle richieste o delle risposte, utilizza gcloud CLI per modificare la mappa URL nel seguente modo:
Regionale
gcloud compute url-maps edit URL_MAP_NAME \
--region=REGION
Di seguito è riportato un file YAML di esempio che mostra come utilizzare le variabili nelle intestazioni personalizzate:
defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: URL_MAP_NAME
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
headerAction:
requestHeadersToAdd:
- headerName: X-header-1-client-region
headerValue: "{client_region}"
- headerName: X-header-2-client-ip-port
headerValue: "{client_ip_address}, {client_port}"
replace: True
requestHeadersToRemove:
- header-3-name
responseHeadersToAdd:
- headerName: X-header-4-server-ip-port
headerValue: "{server_ip_address}, {server_port}"
replace: True
responseHeadersToRemove:
- header-5-name
- header-6-name
Tra regioni
gcloud compute url-maps edit URL_MAP_NAME \
--global
Di seguito è riportato un file YAML di esempio che mostra come utilizzare le variabili nelle intestazioni personalizzate:
defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
name: URL_MAP_NAME
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
weight: 100
headerAction:
requestHeadersToAdd:
- headerName: X-header-1-client-region
headerValue: "{client_region}"
- headerName: X-header-2-client-ip-port
headerValue: "{client_ip_address}, {client_port}"
replace: True
requestHeadersToRemove:
- header-3-name
responseHeadersToAdd:
- headerName: X-header-4-server-ip-port
headerValue: "{server_ip_address}, {server_port}"
replace: True
responseHeadersToRemove:
- header-5-name
- header-6-name
Tieni presente i seguenti comportamenti:
- Se un'intestazione della risposta con variabili personalizzate viene risolta in una stringa vuota, viene rimossa.
- Se un'intestazione della richiesta con variabili personalizzate viene risolta in una stringa vuota, viene mantenuta con un segnaposto di stringa vuota.
- Se un'intestazione della richiesta personalizzata include una variabile personalizzata e una richiesta client in entrata include anche la stessa intestazione, il valore dell'intestazione della richiesta client verrà sostituito con il nuovo valore fornito dall'intestazione personalizzata del bilanciatore del carico.
Variabili che possono essere visualizzate nel valore dell'intestazione
Le seguenti variabili possono essere visualizzate nei valori delle intestazioni personalizzate.
| Variabile | Descrizione |
|---|---|
client_rtt_msec |
Tempo di trasmissione di round trip stimato tra il bilanciatore del carico e il client HTTP(S), in millisecondi. Si tratta del parametro del tempo di round trip uniforme (SRTT) misurato dallo stack TCP del bilanciatore del carico, secondo RFC 2988. Il tempo di round trip uniforme è un algoritmo che gestisce le variazioni e le anomalie che possono verificarsi nelle misurazioni RTT. |
client_ip_address |
L'indirizzo IP del client. In genere è lo stesso dell'indirizzo IP del client
che è il penultimo indirizzo nell'
X-Forwarded-For
intestazione, a meno che il client non utilizzi un proxy o l'
X-Forwarded-For intestazione non sia stata manomessa. |
client_port |
La porta di origine del client. |
client_encrypted |
true se la connessione tra il client e il
bilanciatore del carico è criptata (utilizzando HTTPS, HTTP/2 o HTTP/3); in caso contrario,
false.
|
client_protocol |
Il protocollo HTTP utilizzato per la comunicazione tra il client e il
bilanciatore del carico. Uno tra HTTP/1.0, HTTP/1.1,
HTTP/2, o HTTP/3.
|
origin_request_header |
Riflette il valore dell'intestazione Origin nella richiesta
per i casi d'uso di condivisione delle risorse tra origini (CORS).
|
server_ip_address |
L'indirizzo IP del bilanciatore del carico a cui si connette il client. Può essere utile quando più bilanciatori del carico condividono backend comuni. È lo stesso dell'ultimo indirizzo IP nell'
X-Forwarded-For
intestazione.
|
server_port |
Il numero della porta di destinazione a cui si connette il client. |
tls_sni_hostname |
Indicazione del nome del server (come definito in RFC 6066), se fornita dal client durante l'handshake TLS o QUIC. Il nome host viene convertito in lettere minuscole e viene rimosso qualsiasi punto finale. |
tls_version |
Versione TLS negoziata tra il client e il bilanciatore del carico durante l'
handshake SSL. I valori possibili includono: TLSv1,
TLSv1.1, TLSv1.2 e TLSv1.3. Se
il client si connette utilizzando QUIC anziché TLS, il valore è
QUIC.
|
tls_cipher_suite |
Suite di crittografia negoziata durante l'handshake TLS. Il valore è costituito da quattro
cifre esadecimali definite dal
registro delle suite di crittografia TLS IANA,
ad esempio 009C per TLS_RSA_WITH_AES_128_GCM_SHA256. Questo
valore è vuoto per QUIC e per le connessioni client non criptate.
|
tls_ja3_fingerprint |
Impronta JA3 TLS/SSL se il client si connette utilizzando HTTPS, HTTP/2 o HTTP/3. |
tls_ja4_fingerprint |
Impronta JA4 TLS/SSL se il client si connette utilizzando HTTPS, HTTP/2 o HTTP/3. |
Il bilanciatore del carico espande le variabili in stringhe vuote quando non riesce a determinarne i valori. Ad esempio:
- Parametri TLS quando TLS non è in uso
Il
{origin_request_header}quando la richiesta non include un'intestazioneOrigin
I valori geografici sono stime basate sull'indirizzo IP del client. Di tanto in tanto, Google aggiorna i dati che forniscono questi valori per migliorare l'accuratezza e riflettere i cambiamenti geografici e politici. Anche se l'intestazione X-Forwarded-For originale contiene informazioni sulla località valide, Google stima le località dei client utilizzando le informazioni sull'indirizzo IP di origine contenute nei pacchetti ricevuti dal bilanciatore del carico.
Intestazioni personalizzate mutual TLS
Le seguenti variabili di intestazione aggiuntive sono disponibili se il mutual TLS (mTLS) è configurato su TargetHttpsProxy del bilanciatore del carico.
| Variabile | Descrizione |
|---|---|
client_cert_present |
true se il
client ha fornito un certificato durante l'handshake TLS;
in caso contrario, false.
|
client_cert_chain_verified |
true se la catena di certificati client viene verificata rispetto a un TrustStore configurato; in caso contrario, false.
|
client_cert_error |
Stringhe predefinite che rappresentano le condizioni di errore. Per saperne di più sulle stringhe di errore, consulta Modalità di convalida del client mTLS. |
client_cert_sha256_fingerprint |
Impronta SHA-256 con codifica Base64 del certificato client. |
client_cert_serial_number |
Il numero di serie del certificato client.
Se il numero di serie supera i 50 byte, la stringa
client_cert_serial_number_exceeded_size_limit viene aggiunta a
client_cert_error e il
numero di serie viene impostato su una stringa vuota. |
client_cert_spiffe_id |
L' ID SPIFFE dal campo del nome alternativo del soggetto (SAN). Se il valore non è valido o supera i 2048 byte, l'ID SPIFFE viene impostato su una stringa vuota. Se l'ID SPIFFE supera i 2048 byte, la stringa
|
client_cert_uri_sans |
Elenco separato da virgole con codifica Base64 delle estensioni SAN di tipo URI.
Le estensioni SAN vengono estratte dal certificato client.
L'ID SPIFFE non è
incluso nel campo Se |
client_cert_dnsname_sans |
Elenco separato da virgole con codifica Base64 delle estensioni SAN di tipo DNSName. Le estensioni SAN vengono estratte dal certificato client. Se |
client_cert_valid_not_before |
Timestamp (RFC 3339
date string format) prima del quale il certificato client non è valido.
Ad esempio, 2022-07-01T18:05:09+00:00.
|
client_cert_valid_not_after |
Timestamp (RFC 3339
formato stringa di data) dopo il quale il certificato client non è valido.
Ad esempio, 2022-07-01T18:05:09+00:00.
|
client_cert_issuer_dn |
Campo Emittente completo con codifica Base64 del certificato. Se |
client_cert_subject_dn |
Campo Oggetto completo con codifica Base64 del certificato. Se il |
client_cert_leaf |
Il certificato foglia client per una connessione mTLS stabilita dove il certificato ha superato la convalida. La codifica del certificato è conforme a RFC 9440: il certificato DER binario viene codificato utilizzando Base64 (senza interruzioni di riga, spazi o altri caratteri al di fuori dell'alfabeto Base64) e delimitato da due punti su entrambi i lati. Se |
client_cert_chain |
L'elenco di certificati separato da virgole, nell'ordine TLS standard, della catena di certificati client per una connessione mTLS stabilita in cui il certificato client ha superato la convalida, senza includere il certificato foglia. La codifica del certificato è conforme a RFC 9440. Se la dimensione combinata di |
Limitazioni
Si applicano le seguenti limitazioni:
- Non puoi configurare intestazioni personalizzate sui servizi di backend utilizzati dai bilanciatori del carico delle applicazioni interni a livello di regione e dai bilanciatori del carico delle applicazioni interni tra regioni.