Bilanciatori del carico di rete proxy interni e reti connesse

Questa pagina descrive gli scenari per accedere a un bilanciatore del carico interno nella rete VPC (Virtual Private Cloud) da una rete connessa. Prima della revisione le informazioni in questa pagina, dovresti già conoscere i concetti nella seguente guida:

Utilizzo del peering di rete VPC

Quando utilizzi il peering di rete VPC per connettere la tua rete VPC a un'altra rete, Google Cloud condivide le route delle subnet tra le reti. Le route di subnet consentire al traffico dalla rete peer di raggiungere i bilanciatori del carico interni in della tua rete. L'accesso è consentito se è vero quanto segue:

  • Crea regole firewall in entrata per consentire il traffico dalle VM client nella rete peer. Regole firewall di Google Cloud non sono condivise tra le reti quando si utilizza il peering di rete VPC.
  • Per i bilanciatori del carico delle applicazioni interni regionali, le istanze di macchine virtuali (VM) client la rete peer deve trovarsi nella stessa regione del bilanciatore del carico interno. Questa limitazione viene rifiutata se configuri l'accesso globale.

Non puoi condividere selettivamente solo alcuni bilanciatori del carico di rete passthrough interni, bilanciatori del carico di rete proxy interni regionali o bilanciatori del carico delle applicazioni interni utilizzando il peering di rete VPC. Tutto il carico interno vengono condivisi automaticamente. Puoi limitare l'accesso ai backend del bilanciatore del carico utilizzando le regole firewall in entrata applicabili alle istanze VM di backend.

Utilizza Cloud VPN e Cloud Interconnect

Puoi accedere a un bilanciatore del carico interno da una rete peer collegata tramite un tunnel VPN Cloud o un collegamento VLAN per una connessione Dedicated Interconnect o Partner Interconnect. La rete peer può essere una rete on-premise, un'altra rete Google Cloud rete VPC o una rete virtuale ospitata da un cloud diverso o il provider di servizi di terze parti.

Accesso tramite tunnel Cloud VPN

Puoi accedere a un bilanciatore del carico interno tramite un tunnel VPN Cloud quando sono soddisfatte tutte le seguenti condizioni.

Nella rete del bilanciatore del carico interno

  • Sia il gateway Cloud VPN sia i tunnel devono trovarsi nella stessa regione del bilanciatore del carico quando l'accesso globale è disattivato. Se l'accesso globale è abilitato nell'inoltro del bilanciatore del carico regola, questa limitazione viene rinunciata.
  • Le route devono fornire percorsi di risposta dai sistemi proxy alla rete on-premise o peer in cui si trova il client. Se utilizzi I tunnel Cloud VPN con funzionalità dinamiche di routing, considera il routing dinamico del bilanciatore del carico rete Cloud VPN. La modalità di routing dinamico determina quale le route dinamiche sono disponibili per i proxy nel server subnet.

Nella rete peer

La rete peer deve avere almeno un tunnel Cloud VPN con route per la subnet in cui è definito il bilanciatore del carico interno.

Se la rete peer è un'altra rete VPC di Google Cloud:

  • Il gateway e i tunnel Cloud VPN della rete peer possono trovarsi in in qualsiasi regione.

  • Per i tunnel Cloud VPN che utilizzano il routing dinamico, la modalità di routing dinamico della rete VPC determina disponibili per i client in ogni regione. Per fornire un insieme coerente di route dinamiche personalizzate ai client in tutte le regioni, utilizza la modalità di routing dinamico globale.

  • Assicurati che i firewall di rete on-premise o peer consentano i pacchetti inviati all'indirizzo IP della regola di inoltro del bilanciatore del carico. Assicurati che i firewall di rete on-premise o peer consentano i pacchetti di risposta ricevuti dall'indirizzo IP della regola di inoltro del bilanciatore del carico.

Il seguente diagramma evidenzia i concetti chiave per accedere a un bilanciatore del carico interno tramite un gateway Cloud VPN e il relativo tunnel associato. Cloud VPN connette in sicurezza la rete on-premise Rete VPC Google Cloud con tunnel Cloud VPN.

Bilanciamento del carico interno e Cloud VPN.
Bilanciamento del carico interno e Cloud VPN (fai clic per ingrandire).

Tieni presente i seguenti elementi di configurazione associati a questo esempio:

  • Nel lb-network, un tunnel Cloud VPN che utilizza il routing dinamico è stata configurata. Il tunnel VPN, il gateway e il router Cloud si trovano tutti in REGION_A, la stessa regione in cui si trovano i componenti del bilanciatore del carico interno.
  • Sono state configurate regole firewall di autorizzazione in entrata da applicare al backend VM nei gruppi di istanze A e B in modo che possano ricevono traffico dagli indirizzi IP nella rete VPC e sulla rete on-premise, 10.1.2.0/24 e 192.168.1.0/24. No sono state create regole firewall di negazione in uscita, regola di traffico in uscita implicita .
  • I pacchetti inviati dai client nelle reti on-premise, tra cui da 192.168.1.0/24, all'indirizzo IP del bilanciatore del carico interno, 10.1.2.99, vengono inviati direttamente a una VM di backend integra, come vm-a2, in base all'affinità di sessione configurata.
  • Le risposte inviate dalle VM di backend (ad esempio vm-a2) vengono inviate tramite il tunnel VPN ai client on-premise.

Per risolvere i problemi relativi a Cloud VPN, consulta la sezione Risoluzione dei problemi di Cloud VPN.

Accesso tramite Cloud Interconnect

Puoi accedere a un bilanciatore del carico interno da un peer on-premise connessa alla rete VPC del bilanciatore del carico nella rete del bilanciatore del carico interno sono soddisfatte tutte le condizioni seguenti:

  • Sia il collegamento VLAN sia il router Cloud devono trovarsi nella stessa regione del bilanciatore del carico quando l'accesso globale è disattivato. Se l'accesso globale è abilitato nella regola di inoltro del bilanciatore del carico, questa limitazione viene ignorata.

  • I router on-premise devono fornire percorsi di risposta dai backend del bilanciatore del carico alla rete on-premise. I collegamenti VLAN per entrambi i tipi di interconnessione, Dedicated Interconnect e Partner Interconnect, devono utilizzare router Cloud. Pertanto, le route dinamiche personalizzate forniscono percorsi di risposta. L'insieme di route dinamiche personalizzate che apprendono dipende dalla modalità di routing dinamico della rete del bilanciatore del carico.

  • Assicurati che i firewall on-premise consentano l'invio di pacchetti all'indirizzo IP del la regola di forwarding del bilanciatore del carico. Assicurati che i firewall on-premise consentano i pacchetti di risposta ricevuti dall'indirizzo IP della regola di inoltro del bilanciatore del carico.

Utilizza l'accesso globale con Cloud VPN e Cloud Interconnect

Per impostazione predefinita, i client devono trovarsi nella stessa rete o in una rete VPC connessa tramite peering di rete VPC. Puoi attivare l'accesso globale per consentire ai client di qualsiasi regione di accedere al bilanciatore del carico.

Per i bilanciatori del carico di rete proxy interno tra regioni, l'accesso globale è attivo per impostazione predefinita. I client di qualsiasi regione possono accedere al tuo bilanciatore del carico. Per i bilanciatori del carico di rete proxy interno regionali, quando abiliti l'accesso globale, le seguenti risorse possono trovarsi in qualsiasi regione:
  • Router Cloud
  • Gateway e tunnel Cloud VPN
  • Collegamenti VLAN

Nel diagramma:

  • Il frontend e i backend del bilanciatore del carico si trovano nella regione REGION_A.
  • Il router Cloud si trova nella regione REGION_B.
  • Il router Cloud esegue il peering con il router VPN on-premise.
  • La sessione di peering BGP (Border Gateway Protocol) può avvenire tramite Cloud VPN o Cloud Interconnect con peering diretto Partner Interconnect.
Bilanciamento del carico interno con accesso globale.
Bilanciamento del carico interno con accesso globale (fai clic per ingrandire).

La modalità di routing dinamico della rete VPC è impostata su global per consentire a Cloud Router in REGION_B di pubblicizzare le route delle sottoreti per le sottoreti in qualsiasi regione della rete VPC del bilanciatore del carico.

Più percorsi in uscita

Negli ambienti di produzione, dovresti utilizzare più Cloud VPN tunnel o collegamenti VLAN per la ridondanza. Questo illustra i requisiti per l'utilizzo di più tunnel o collegamenti VLAN.

Nel diagramma seguente, due tunnel Cloud VPN connettono lb-network a una rete on-premise. Sebbene qui vengano utilizzati i tunnel Cloud VPN, gli stessi principi si applicano a Cloud Interconnect.

Bilanciamento del carico interno e più tunnel Cloud VPN.
Bilanciamento del carico interno e più tunnel Cloud VPN (fai clic per ingrandire).

Devi configurare ogni tunnel o ogni collegamento VLAN nella stessa regione del bilanciatore del carico interno. Questo requisito non viene applicato se hai attivato l'accesso globale.

Più tunnel o collegamenti VLAN possono fornire larghezza di banda aggiuntiva o percorsi di standby per la ridondanza.

Tieni presente quanto segue:

  • Se la rete on-premise ha due route con le stesse priorità, ciascuna con destinazione 10.1.2.0/24 e un hop successivo corrispondente a un tunnel VPN diverso nella stessa regione del bilanciatore del carico interno, il traffico può essere inviato dalla rete on-premise (192.168.1.0/24) al bilanciatore del carico utilizzando il protocollo multipath con costo uguale (ECMP).
  • Dopo che i pacchetti sono stati inviati alla rete VPC, il bilanciatore del carico interno li distribuisce alle VM di backend in base all'affinità di sessione configurata.
  • Se lb-network ha due route, ciascuna con la destinazione192.168.1.0/24 e un hop successivo corrispondente a diversi tunnel VPN, le risposte delle VM di backend possono essere inviate su ogni tunnel in base alla priorità delle route nella rete. Se priorità del percorso diverse uno dei due tunnel può fungere da backup per l'altro. Se vengono utilizzate le stesse priorità, le risposte vengono inviate utilizzando ECMP.
  • Le risposte inviate dalle VM di backend (ad esempio vm-a2) vengono inviate direttamente ai client on-premise tramite il tunnel appropriato. Dal punto di vista di lb-network, se le route o i tunnel VPN cambiano, il traffico potrebbe uscire utilizzando un tunnel diverso. Ciò potrebbe comportare il ripristino della sessione TCP se una connessione in corso viene interrotta.

Passaggi successivi