Questo esempio mostra come tutte le richieste alla porta 80 vengono reindirizzate ai rispettivi servizi HTTPS.
Per informazioni su come configurare il reindirizzamento da HTTP a HTTPS per il bilanciamento del carico esterno, consulta Configurazione del reindirizzamento da HTTP a HTTPS per i bilanciatori del carico HTTP(S) esterni.
Per utilizzare i reindirizzamenti da HTTP a HTTPS con un indirizzo IP condiviso, devi creare due bilanciatori del carico, uno per il traffico HTTPS e un altro per il traffico HTTP. Ogni bilanciatore del carico ha regole di forwarding e mappa URL proprie, ma condivide lo stesso indirizzo IP. Per il bilanciatore del carico HTTP, non è necessario configurare un backend perché il frontend reindirizza il traffico al backend del bilanciatore del carico HTTPS.
Questo esempio mostra come reindirizzare tutte le richieste dalla porta 80 alla porta 443.
A livello generale, per reindirizzare il traffico HTTP su HTTPS, è necessario:
- Crea un normale bilanciatore del carico HTTPS interno con un indirizzo IP interno condiviso e riservato.
- Testa il bilanciatore del carico HTTPS interno per assicurarti che funzioni.
- Reindirizza il traffico al bilanciatore del carico HTTPS interno.
A tale scopo, devi aggiungere un bilanciatore del carico HTTP interno parziale con frontend. Il frontend riceve le richieste e le reindirizza al bilanciatore del carico HTTPS interno. Per farlo, utilizza quanto segue:- Una regola di forwarding con lo stesso indirizzo IP interno riservato utilizzato dal bilanciatore del carico HTTPS (vedi nel passaggio 1)
- Un proxy HTTP di destinazione
- Una mappa degli URL che reindirizza il traffico al bilanciatore del carico HTTPS
Come mostrato nel diagramma seguente, il bilanciatore del carico HTTPS interno è un normale bilanciatore del carico con i componenti del bilanciatore del carico previsti.
Il bilanciatore del carico HTTP ha lo stesso indirizzo IP del bilanciatore del carico HTTPS e un'istruzione di reindirizzamento nella mappa URL.
Creazione del bilanciatore del carico HTTPS interno
La procedura è simile a quella per configurare un bilanciatore del carico HTTP(S) interno.
La configurazione del bilanciamento del carico HTTP(S) interno si compone di due parti:
- Eseguire attività preliminari, ad esempio garantire che gli account richiesti dispongano delle autorizzazioni corrette e preparare la rete Virtual Private Cloud (VPC).
- Configurazione delle risorse del bilanciatore del carico.
Prima di seguire questa guida, acquisisci familiarità con quanto segue:
- Panoramica del bilanciamento del carico HTTP(S) interno, inclusa la sezione Limitazioni
- Panoramica delle regole firewall VPC
Autorizzazioni
Per seguire questa guida, devi essere in grado di creare istanze e modificare una rete in un progetto. Devi essere un proprietario o un editor del progetto oppure devi disporre di tutti i seguenti ruoli IAM di Compute Engine.
Attività | Ruolo richiesto |
---|---|
Crea reti, subnet e componenti del bilanciatore del carico | Amministratore di rete |
Aggiungi e rimuovi regole firewall | Amministratore sicurezza |
Creare istanze | Amministratore istanza |
Per ulteriori informazioni, consulta le seguenti guide:
Configurazione della rete e delle subnet
È necessaria una rete VPC con due subnet: una per i backend del bilanciatore del carico e l'altra per i proxy del bilanciatore del carico. Un bilanciatore del carico HTTP(S) interno è a livello di area geografica. Il traffico nella rete VPC è instradato al bilanciatore del carico, se l'origine del traffico si trova in una subnet nella stessa area geografica del bilanciatore del carico.
Questo esempio utilizza le seguenti reti, aree geografiche e subnet VPC:
Rete. La rete è una rete VPC in modalità personalizzata denominata
lb-network
.Subnet per i backend. Una subnet denominata
backend-subnet
nell'area geograficaus-west1
utilizza10.1.2.0/24
come intervallo IP principale.Subnet per i proxy. Una subnet denominata
proxy-only-subnet
nell'area geograficaus-west1
utilizza10.129.0.0/23
come intervallo IP principale.
Configurazione della rete e della subnet per i backend
console
- Vai alla pagina di rete VPC in Google Cloud Console.
Vai alla pagina Reti VPC - Fai clic su Crea rete VPC.
- In Nome, inserisci
lb-network
. - Nella sezione Subnet:
- Imposta la modalità di creazione subnet su Personalizzata.
- Nella sezione Nuova subnet, inserisci le seguenti informazioni:
- Nome:
backend-subnet
- Area geografica:
us-west1
- Intervallo di indirizzi IP:
10.1.2.0/24
- Nome:
- Fai clic su Fine.
- Fai clic su Crea.
gcloud
Crea la rete VPC personalizzata con il comando
gcloud compute networks create
:gcloud compute networks create lb-network --subnet-mode=custom
Crea una subnet nella rete
lb-network
nell'area geograficaus-west1
con il comandogcloud compute networks subnets create
:gcloud compute networks subnets create backend-subnet \ --network=lb-network \ --range=10.1.2.0/24 \ --region=us-west1
API
Fai una richiesta POST
al metodo
networks.insert
,
sostituendo PROJECT_ID
con l'ID progetto.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks { "routingConfig": { "routingMode": "REGIONAL" }, "name": "lb-network", "autoCreateSubnetworks": false }
Fai una richiesta POST
al metodo
subnetworks.insert
,
sostituendo PROJECT_ID
con l'ID progetto.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks { "name": "backend-subnet", "network": "projects/PROJECT_ID/global/networks/lb-network", "ipCidrRange": "10.1.2.0/24", "region": "projects/PROJECT_ID/regions/us-west1", }
Configurazione della subnet solo proxy
Questa subnet solo proxy è destinata a tutti i bilanciatori del carico HTTP(S) interni nell'area geografica us-west1
.
console
Se utilizzi Google Cloud Console, puoi attendere e creare la subnet solo proxy in un secondo momento nella pagina Bilanciamento del carico.
Se vuoi creare subito una subnet solo proxy, segui questi passaggi:
- In Google Cloud Console, vai alla pagina Reti VPC.
Vai alla pagina Reti VPC - Fai clic sul nome della rete VPC condivisa:
lb-network
. - Fai clic su Aggiungi subnet.
- In Nome, inserisci
proxy-only-subnet
. - Come Area geografica, seleziona
us-west1
. - Imposta Finalità su Proxy gestito a livello di area geografica.
- Per Intervallo di indirizzi IP, inserisci
10.129.0.0/23
. - Fai clic su Aggiungi.
gcloud
Crea la subnet solo proxy con il comando gcloud compute networks subnets
create
.
gcloud compute networks subnets create proxy-only-subnet \ --purpose=REGIONAL_MANAGED_PROXY \ --role=ACTIVE \ --region=us-west1 \ --network=lb-network \ --range=10.129.0.0/23
API
Crea la subnet solo proxy con il metodo
subnetworks.insert
, sostituendo PROJECT_ID
con l'ID progetto.
POST https://compute.googleapis.com/compute/projects/PROJECT_ID/regions/us-west1/subnetworks { "name": "proxy-only-subnet", "ipCidrRange": "10.129.0.0/23", "network": "projects/PROJECT_ID/global/networks/lb-network", "region": "projects/PROJECT_ID/regions/us-west1", "purpose": "REGIONAL_MANAGED_PROXY", "role": "ACTIVE" }
Configurazione delle regole del firewall
In questo esempio vengono utilizzate le seguenti regole firewall:
fw-allow-ssh
. Una regola in entrata, applicabile alle istanze in bilanciamento del carico, che consente la connettività SSH in entrata sulla porta TCP22
da qualsiasi indirizzo. Puoi scegliere un intervallo IP di origine più restrittivo per questa regola; ad esempio, puoi specificare solo gli intervalli IP del sistema da cui avvii le sessioni SSH. In questo esempio viene utilizzato il tag di destinazioneallow-ssh
.fw-allow-health-check
. Una regola in entrata, applicabile alle istanze in bilanciamento del carico, che consente tutto il traffico TCP dai sistemi di controllo di integrità di Google Cloud (in130.211.0.0/22
e35.191.0.0/16
). In questo esempio viene utilizzato il tag di destinazioneload-balanced-backend
.fw-allow-proxies
. Una regola in entrata, applicabile alle istanze in fase di bilanciamento del carico, che consente il traffico TCP sulle porte80
,443
e8080
dal proxy del carico HTTP(S) interno. In questo esempio viene utilizzato il tag di destinazioneload-balanced-backend
.
Senza queste regole firewall, la regola predefinita per il traffico in entrata blocca il traffico in entrata verso le istanze di backend.
I tag di destinazione definiscono le istanze di backend. Senza i tag di destinazione, le regole firewall si applicano a tutte le tue istanze di backend nella rete VPC. Quando crei le VM di backend, assicurati di includere i tag di destinazione specificati, come mostrato nella sezione Creazione di un gruppo di istanze gestite.
console
- Vai alla pagina Regole firewall in Google Cloud Console.
Vai alla pagina Regole firewall - Fai clic su Crea regola firewall per creare la regola per consentire le connessioni SSH in entrata:
- Nome:
fw-allow-ssh
- Rete:
lb-network
- Direzione del traffico: in entrata
- Azione in caso di corrispondenza: Consenti
- Target: tag di destinazione specificati
- Tag di destinazione:
allow-ssh
- Filtro di origine: intervalli IPv4
- Intervalli IPv4 di origine:
0.0.0.0/0
- Protocolli e porte:
- Scegli Protocolli e porte specificati.
- Seleziona la casella di controllo tcp, quindi inserisci
22
per il numero di porta.
- Nome:
- Fai clic su Crea.
- Fai clic su Crea regola firewall una seconda volta per creare la regola per consentire i
controlli di integrità di Google Cloud:
- Nome:
fw-allow-health-check
- Rete:
lb-network
- Direzione del traffico: in entrata
- Azione in caso di corrispondenza: Consenti
- Target: tag di destinazione specificati
- Tag di destinazione:
load-balanced-backend
- Filtro di origine: intervalli IPv4
- Intervalli IPv4 di origine:
130.211.0.0/22
e35.191.0.0/16
- Protocolli e porte:
- Scegli Protocolli e porte specificati.
- Seleziona la casella di controllo tcp, quindi inserisci
80
per il numero di porta.
Come best practice, limita questa regola solo ai protocolli e alle porte corrispondenti a quelli utilizzati dal controllo di integrità. Se utilizzitcp:80
per il protocollo e la porta, Google Cloud può utilizzare HTTP sulla porta80
per contattare le tue VM, ma non può utilizzare HTTPS sulla porta443
per contattarli.
- Nome:
- Fai clic su Crea.
- Fai clic su Crea regola firewall una terza volta per creare la regola e consentire ai server proxy del bilanciatore del carico di connettere i backend:
- Nome:
fw-allow-proxies
- Rete:
lb-network
- Direzione del traffico: in entrata
- Azione in caso di corrispondenza: Consenti
- Target: tag di destinazione specificati
- Tag di destinazione:
load-balanced-backend
- Filtro di origine: intervalli IPv4
- Intervalli IPv4 di origine:
10.129.0.0/23
- Protocolli e porte:
- Scegli Protocolli e porte specificati.
- Seleziona la casella di controllo tcp, quindi inserisci
80, 443, 8080
per i numeri di porta.
- Nome:
- Fai clic su Crea.
gcloud
Crea la regola firewall
fw-allow-ssh
per consentire la connettività SSH alle VM con il tag di reteallow-ssh
. Se omettisource-ranges
, Google Cloud interpreta la regola per indicare qualsiasi origine.gcloud compute firewall-rules create fw-allow-ssh \ --network=lb-network \ --action=allow \ --direction=ingress \ --target-tags=allow-ssh \ --rules=tcp:22
Crea la regola
fw-allow-health-check
per consentire i controlli di integrità di Google Cloud. Questo esempio consente a tutto il traffico TCP da probe di controllo di integrità; tuttavia, puoi configurare un insieme di porte più ristretto in base alle tue esigenze.gcloud compute firewall-rules create fw-allow-health-check \ --network=lb-network \ --action=allow \ --direction=ingress \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --target-tags=load-balanced-backend \ --rules=tcp
Crea la regola
fw-allow-proxies
per consentire ai proxy del bilanciatore del carico HTTP(S) interno di connettersi ai backend. Impostasource-ranges
sugli intervalli allocati della subnet solo proxy, ad esempio10.129.0.0/23
.gcloud compute firewall-rules create fw-allow-proxies \ --network=lb-network \ --action=allow \ --direction=ingress \ --source-ranges=source-range \ --target-tags=load-balanced-backend \ --rules=tcp:80,tcp:443,tcp:8080
API
Crea la regola firewall fw-allow-ssh
inviando una richiesta POST
al
metodo firewalls.insert
, sostituendo PROJECT_ID
con l'ID progetto.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls { "name": "fw-allow-ssh", "network": "projects/PROJECT_ID/global/networks/lb-network", "sourceRanges": [ "0.0.0.0/0" ], "targetTags": [ "allow-ssh" ], "allowed": [ { "IPProtocol": "tcp", "ports": [ "22" ] } ], "direction": "INGRESS" }
Crea la regola firewall fw-allow-health-check
inviando una richiesta POST
al
metodo firewalls.insert
, sostituendo PROJECT_ID
con l'ID progetto.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls { "name": "fw-allow-health-check", "network": "projects/PROJECT_ID/global/networks/lb-network", "sourceRanges": [ "130.211.0.0/22", "35.191.0.0/16" ], "targetTags": [ "load-balanced-backend" ], "allowed": [ { "IPProtocol": "tcp" } ], "direction": "INGRESS" }
Crea la regola firewall fw-allow-proxies
per consentire il traffico TCP all'interno della subnet proxy per il metodo firewalls.insert
, sostituendo PROJECT_ID
con l'ID progetto.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls { "name": "fw-allow-proxies", "network": "projects/PROJECT_ID/global/networks/lb-network", "sourceRanges": [ "10.129.0.0/23" ], "targetTags": [ "load-balanced-backend" ], "allowed": [ { "IPProtocol": "tcp", "ports": [ "80" ] }, { "IPProtocol": "tcp", "ports": [ "443" ] }, { "IPProtocol": "tcp", "ports": [ "8080" ] } ], "direction": "INGRESS" }
Creazione delle risorse interne per il bilanciatore del carico HTTPS
Questo esempio utilizza un backend di macchina virtuale su Compute Engine in un gruppo di istanze gestite. Puoi invece utilizzare altri tipi di backend supportati.
Creazione di un modello di istanza con un server HTTP
gcloud
gcloud compute instance-templates create l7-ilb-backend-template \ --region=us-west1 \ --network=lb-network \ --subnet=backend-subnet \ --tags=allow-ssh,load-balanced-backend \ --image-family=debian-9 \ --image-project=debian-cloud \ --metadata=startup-script='#! /bin/bash apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://169.254.169.254/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html systemctl restart apache2'
Creazione di un gruppo di istanze gestite nella zona
gcloud
gcloud compute instance-groups managed create l7-ilb-backend \ --zone=us-west1-a \ --size=2 \ --template=l7-ilb-backend-template
Creazione di un controllo di integrità HTTP
gcloud
gcloud compute health-checks create http l7-ilb-basic-check \ --region=us-west1 \ --use-serving-port
Creazione di un servizio di backend
gcloud
gcloud compute backend-services create l7-ilb-backend-service \ --load-balancing-scheme=INTERNAL_MANAGED \ --protocol=HTTP \ --health-checks=l7-ilb-basic-check \ --health-checks-region=us-west1 \ --region=us-west1
Aggiunta di backend al servizio di backend
gcloud
gcloud compute backend-services add-backend l7-ilb-backend-service \ --balancing-mode=UTILIZATION \ --instance-group=l7-ilb-backend \ --instance-group-zone=us-west1-a \ --region=us-west1
Creazione di una mappa URL
gcloud
gcloud compute url-maps create l7-ilb-service-url-map \ --default-service=l7-ilb-backend-service \ --region=us-west1
Creazione di un certificato SSL a livello di area geografica
L'esempio seguente mostra come utilizzare gcloud
per creare un certificato SSL autogestito. Per ulteriori informazioni, consulta Utilizzo dei certificati SSL autogestiti e
Utilizzo dei certificati SSL gestiti da Google.
gcloud
gcloud compute ssl-certificates create CERTIFICATE_NAME \ --certificate=CERTIFICATE_FILE \ --private-key=PRIVATE_KEY_FILE \ --region=us-west1
Usare il certificato SSL a livello di area geografica per creare un proxy di destinazione
gcloud
gcloud compute target-https-proxies create l7-ilb-https-proxy \ --url-map=l7-ilb-service-url-map \ --region=us-west1 \ --ssl-certificates=l7-ilb-cert
Prenotazione di un indirizzo IP condiviso per le regole di forwarding
gcloud
gcloud compute addresses create NAME \ --addresses=10.1.2.99 \ --region=us-west1 \ --subnet=backend-subnet \ --purpose=SHARED_LOADBALANCER_VIP
Creazione di una regola di forwarding HTTPS
gcloud
gcloud compute forwarding-rules create l7-ilb-https-forwarding-rule \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=lb-network \ --subnet=backend-subnet \ --address=10.1.2.99 \ --ports=443 \ --region=us-west1 \ --target-https-proxy=l7-ilb-https-proxy \ --target-https-proxy-region=us-west1
Test del bilanciatore del carico HTTPS
A questo punto, il bilanciatore del carico (inclusi il servizio di backend, la mappa URL e la regola di forwarding) è pronto. Testa questo bilanciatore del carico per verificare che funzioni come previsto.
Crea un'istanza VM del client per testare la connettività.
gcloud
gcloud compute instances create l7-ilb-client-us-west1-a \ --image-family=debian-9 \ --image-project=debian-cloud \ --network=lb-network \ --subnet=backend-subnet \ --zone=us-west1-a \ --tags=allow-ssh
Connettiti alla VM del client tramite SSH.
gcloud
gcloud compute ssh l7-ilb-client-us-west1-a \ --zone=us-west1-a
Usa Curl per connetterti al bilanciatore del carico HTTPS.
curl -k -s 'https://10.1.2.99:443' --connect-to 10.1.2.99:443
Esempio di output:
Page served from: l7-ilb-backend-850t
Invia 100 richieste e verifica che siano tutte bilanciate.
{
RESULTS=
for i in {1..100}
do
RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.99:443)"
done
echo "***"
echo "*** Results of load-balancing to 10.1.2.99: "
echo "***"
echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
echo
}
Esempio di output:
***
*** Results of load-balancing to 10.1.2.99:
***
51 l7-ilb-backend-https-850t
49 l7-ilb-backend-https-w11t
100 Page served from
Reindirizzamento del traffico al bilanciatore del carico HTTPS
Il bilanciatore del carico HTTP ha un indirizzo IP condiviso che reindirizza il traffico dalla porta 80 alla 443.
Creazione di una nuova mappa URL per il reindirizzamento del traffico
Crea un file YAML con la configurazione del reindirizzamento del traffico.
defaultService: regions/us-west1/backendServices/l7-ilb-backend-service
kind: compute#urlMap
name: l7-ilb-redirect-url-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- name: matcher1
defaultUrlRedirect:
hostRedirect: 10.1.2.99:443
pathRedirect: /
redirectResponseCode: PERMANENT_REDIRECT
httpsRedirect: True
Importa il file YAML in una nuova mappa URL.
gcloud
gcloud compute url-maps import l7-ilb-redirect-url-map \ --source=/tmp/url_map.yaml \ --region=us-west1
Creazione del proxy di destinazione del bilanciatore del carico HTTP
gcloud
gcloud compute target-http-proxies create l7-ilb-http-proxy \ --url-map=l7-ilb-redirect-url-map \ --region=us-west1
Creazione di una nuova regola di forwarding e dell'indirizzo IP condiviso
gcloud
gcloud compute forwarding-rules create l7-ilb-forwarding-rule \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=lb-network \ --subnet=backend-subnet \ --address=10.1.2.99 \ --ports=80 \ --region=us-west1 \ --target-http-proxy=l7-ilb-http-proxy \ --target-http-proxy-region=us-west1
Test del reindirizzamento del traffico
Connettiti alla VM del tuo client.
gcloud
gcloud compute ssh l7-ilb-client-us-west1-a \ --zone=us-west1-a
Invia una richiesta http alla 10.1.2.99 sulla porta 80, aspettati un reindirizzamento del traffico.
curl -L -k 10.1.2.99
Un output di esempio.
Page served from: l7-ilb-backend-w11t
Puoi aggiungere -vvv per visualizzare ulteriori dettagli.
curl -L -k 10.1.2.99 -vvv
* Rebuilt URL to: 10.1.2.99/
* Trying 10.1.2.99...
* TCP_NODELAY set
* Connected to 10.1.2.99 (10.1.2.99) port 80 (#0)
> GET / HTTP/1.1
> Host: 10.1.2.99
> User-Agent: curl/7.52.1
> Accept: */*
>
< HTTP/1.1 308 Permanent Redirect
< location: https://10.1.2.99:443/
< date: Fri, 07 Aug 2020 05:07:18 GMT
< via: 1.1 google
< content-length: 0
<
* Curl_http_done: called premature == 0
* Connection #0 to host 10.1.2.99 left intact
* Issue another request to this URL: 'https://10.1.2.99:443/'
* Trying 10.1.2.99...
* TCP_NODELAY set
* Connected to 10.1.2.99 (10.1.2.99) port 443 (#1)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
...
...
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: O=Google TESTING; CN=test_cert_1
* start date: Jan 1 00:00:00 2015 GMT
* expire date: Jan 1 00:00:00 2025 GMT
* issuer: O=Google TESTING; CN=Intermediate CA
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x561a6b0e3ea0)
> GET / HTTP/1.1
> Host: 10.1.2.99
> User-Agent: curl/7.52.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
< date: Fri, 07 Aug 2020 05:07:18 GMT
< server: Apache/2.4.25 (Debian)
< last-modified: Thu, 06 Aug 2020 13:30:21 GMT
< etag: "2c-5ac357d7a47ec"
< accept-ranges: bytes
< content-length: 44
< content-type: text/html
< via: 1.1 google
<
Page served from: l7-ilb-backend-https-w11t
* Curl_http_done: called premature == 0
* Connection #1 to host 10.1.2.99 left intact
Passaggi successivi
Per informazioni sul funzionamento del bilanciamento del carico HTTP(S) interno, consulta Panoramica del bilanciamento del carico HTTP(S) interno.
Per gestire la risorsa di subnet solo proxy richiesta dal bilanciamento del carico HTTP(S) interno, consulta la sezione Subnet solo proxy per i bilanciatori del carico HTTP(S) interni.