Risolvere i problemi di connettività interna tra le VM

Questo documento fornisce i passaggi per la risoluzione dei problemi di connettività tra le VM di Compute Engine che si trovano nella stessa rete VPC (Virtual Private Cloud) (VPC condiviso o autonomo) o in due reti VPC connesse con il peering di rete VPC. Si presume che le VM comunichino utilizzando gli indirizzi IP interni dei rispettivi controller di interfaccia di rete virtuale (vNIC).

I passaggi di questa guida si applicano sia alle VM di Compute Engine sia ai nodi di Google Kubernetes Engine.

Se vuoi visualizzare scenari di risoluzione dei problemi aggiuntivi specifici, fai clic sul link Invia feedback in fondo alla pagina e comunicacelo.

Le seguenti configurazioni di VM e VPC sono applicabili a questa guida:

• Connessioni da VM a VM che utilizzano indirizzi IP interni in un'unica rete VPC.
• Connessioni da VM a VM che utilizzano indirizzi IP interni all'interno di una rete VPC condiviso.
• Connessioni VM-to-VM che utilizzano indirizzi IP interni in reti VPC diverse con peering tramite il peering di rete VPC.

I comandi utilizzati in questa guida sono disponibili su tutte le immagini del sistema operativo fornite da Google. Se utilizzi la tua immagine del sistema operativo, potresti dover installare gli strumenti.

Quantificare il problema

• Se ritieni di avere una perdita completa dei pacchetti, vai a Risolvere i problemi di interruzione completa della connessione.
• Se riscontri latenza, perdita di pacchetti solo parziale o timeout in corso di connessione, vai a Risolvere i problemi di latenza o perdita di rete che causano problemi di throughput.

Risolvere i problemi relativi a una connessione completa non riuscita

Le sezioni seguenti descrivono la procedura per la risoluzione dei problemi di connettività interna completa tra le VM. Se invece riscontri un aumento della latenza o timeout di connessione intermittenti, vai a Risolvere i problemi di latenza o perdita di rete che causano problemi di throughput.

Determina i valori di connessione

Innanzitutto, raccogli le seguenti informazioni:

• Nella pagina Istanze VM, raccoglie quanto segue per entrambe le VM:
  • Nomi VM
  • Zone VM
  • Indirizzi IP interni per le vNIC in comunicazione

• Dalla configurazione del software del server di destinazione, raccogli le seguenti informazioni:

  • Protocollo di livello 4
  • Porta di destinazione

  Ad esempio, se la destinazione è un server HTTPS, il protocollo è TCP e la porta è in genere 443, ma la configurazione specifica potrebbe utilizzare una porta diversa.

Se riscontri problemi con più VM, scegli una singola VM di origine e una singola VM di destinazione con problemi e utilizza questi valori. In genere, non è necessaria la porta di origine della connessione.

Una volta ottenute queste informazioni, vai a Esaminare i problemi della rete di Google sottostante.

Esaminare i problemi relativi alla rete di Google sottostante

Se la tua configurazione è esistente e non è cambiata di recente, il problema potrebbe riguardare la rete di Google sottostante. Controlla la perdita di pacchetti tra le zone VM nella dashboard sul rendimento del Network Intelligence Center. Se si verifica un aumento della perdita di pacchetti tra le zone durante il periodo di tempo in cui si sono verificati i timeout di rete, potrebbe indicare che il problema riguarda la rete fisica sottostante alla rete virtuale. Controlla la dashboard dello stato di Google Cloud per verificare la presenza di problemi noti prima di inviare una richiesta di assistenza.

Se il problema non sembra riguardare la rete Google sottostante, vai a Verificare la presenza di regole firewall di Google Cloud configurate in modo errato.

Verificare la presenza di regole firewall configurate in modo errato in Google Cloud

Connectivity Tests analizzano la configurazione del percorso di rete VPC tra due VM e mostrano se la configurazione programmata deve consentire o meno il traffico. Se il traffico non è consentito, i risultati indicano se una regola del firewall in entrata o in uscita di Google Cloud blocca il traffico o se non è disponibile una route.

Connectivity Tests potrebbero anche testare dinamicamente il percorso inviando pacchetti tra gli hypervisor delle VM. Se vengono eseguiti questi test, vengono visualizzati i risultati.

Connectivity Tests esamina solo la configurazione della rete VPC. Non testa il firewall del sistema operativo, i percorsi del sistema operativo o il software del server sulla VM.

La procedura seguente esegue Connectivity Tests dalla console Google Cloud. Per altri modi per eseguire i test, consulta Eseguire test di connettività.

Per creare ed eseguire un test, segui la procedura riportata di seguito:

1. Nella console Google Cloud, vai alla pagina Test di connettività.

   Vai a Connectivity Tests

2. Nel menu a discesa del progetto, verifica di trovarti nel progetto corretto o specifica quello corretto.

3. Fai clic su Crea test di connettività.

4. Assegna un nome al test.

5. Specifica quanto segue:

   1. Protocollo
   2. Indirizzo IP dell'endpoint di origine
   3. Progetto di origine e rete VPC
   4. Indirizzo IP dell'endpoint di destinazione
   5. Progetto di destinazione e rete VPC
   6. Porta di destinazione

6. Fai clic su Crea.

Il test viene eseguito immediatamente. Per visualizzare il diagramma dei risultati, fai clic su Visualizza nella colonna Dettagli risultato.

• Se i risultati indicano che la connessione viene interrotta da una regola firewall di Google Cloud, determina se la configurazione di sicurezza prevista deve consentire la connessione. Potresti dover chiedere all'amministratore della sicurezza o della rete di fornirti i dettagli. Se il traffico deve essere consentito, controlla quanto segue:
  • Controlla l'elenco Traffico sempre bloccato. Se il traffico viene bloccato da Google Cloud come descritto nell'elenco del traffico bloccato sempre, la configurazione esistente non funzionerà.
  • Vai alla pagina Criteri firewall e controlla le regole firewall. Se il firewall è configurato in modo errato, crea o modifica una regola firewall per consentire la connessione. Questa regola può essere una regola firewall VPC o una regola della policy firewall gerarchica.
• Se esiste una regola del firewall configurata correttamente che blocca questo traffico, consulta l'amministratore della sicurezza o della rete. Se i requisiti di sicurezza della tua organizzazione prevedono che le VM non debbano comunicare tra loro, potresti dover riprogettare la configurazione.
• Se i risultati indicano che non ci sono problemi con il percorso di connettività della VPC, il problema potrebbe essere uno dei seguenti.
  • Problemi con la configurazione del sistema operativo guest, ad esempio con il software del firewall.
  • Problemi con le applicazioni client o server, ad esempio se l'applicazione è bloccata o configurata per ascoltare sulla porta sbagliata.

I passaggi successivi illustrano come esaminare ciascuna di queste possibilità. Continua con Testa la connettività TCP dall'interno della VM.

Verifica la connettività TCP dall'interno della VM

Se il test di connettività VM-VM non ha rilevato un problema di configurazione della VPC, inizia a testare la connettività OS-OS. I seguenti passaggi ti aiutano a determinare quanto segue:

• Se un server TCP è in ascolto sulla porta indicata
• Se il software del firewall lato server consente le connessioni a quella porta dalla VM client
• Se il software del firewall lato client consente le connessioni a quella porta sul server
• Se la tabella di routing lato server è configurata correttamente per inoltrare i pacchetti
• Se la tabella di routing lato client è configurata correttamente per inoltrare i pacchetti

Puoi testare l'handshake TCP utilizzando curl con Linux o Windows 2019 oppure utilizzando il comando New-Object System.Net.Sockets.TcpClient con Windows Powershell. Il flusso di lavoro in questa sezione dovrebbe produrre uno dei seguenti risultati: connessione riuscita, timeout della connessione o reimpostazione della connessione.

• Risultato positivo: se la stretta di mano TCP viene completata correttamente, significa che una regola del firewall del sistema operativo non blocca la connessione, che il sistema operativo inoltra correttamente i pacchetti e che un server di qualche tipo è in ascolto sulla porta di destinazione. In questo caso, il problema potrebbe riguardare l'applicazione stessa. Per verificare, consulta Controllare i log del server per informazioni sul comportamento del server.
• Timeout: se la connessione scade, in genere significa una delle seguenti condizioni:
  • Non è presente alcuna macchina all'indirizzo IP specificato
  • Da qualche parte c'è un firewall che ignora silenziosamente i pacchetti
  • Il routing dei pacchetti del sistema operativo invia i pacchetti a una destinazione che non può elaborarli o il routing asimmetrico invia il pacchetto di ritorno su un percorso non valido

• Reimpostazione: se la connessione viene reimpostata, significa che l'IP di destinazione riceve i pacchetti, ma un sistema operativo o un'applicazione li rifiuta. Ciò può significare uno dei seguenti casi:

  • I pacchetti arrivano alla macchina sbagliata e non è configurata per rispondere a quel protocollo su quella porta
  • I pacchetti arrivano alla macchina corretta, ma nessun server è in ascolto su quella porta
  • I pacchetti arrivano alla macchina e alla porta corrette, ma i protocolli di livello superiore (come SSL) non completano l'handshake.
  • Un firewall reimposta la connessione. È meno probabile che un firewall scarichi silenziosamente i pacchetti, ma può succedere.

Connessione riuscita

I seguenti risultati indicano un handshake TCP riuscito. Se l'handshake TCP viene completato correttamente, il problema non riguarda il timeout o il ripristino della connessione TCP. Il problema di timeout si verifica invece all'interno degli strati dell'applicazione. Se la connessione viene stabilita, procedi con la verifica dei log del server per informazioni sul comportamento del server.

$ curl -vso /dev/null --connect-timeout 5 192.168.0.4:443

Expire in 0 ms for 6 (transfer 0x558b3289ffb0)
Expire in 5000 ms for 2 (transfer 0x558b3289ffb0)
  Trying 192.168.0.4...
TCP_NODELAY set
Expire in 200 ms for 4 (transfer 0x558b3289ffb0)
Connected to 192.168.0.4 (192.168.0.4) port 443 (#0)
> GET / HTTP/1.1
> Host: 192.168.0.4:443
> User-Agent: curl/7.64.0
> Accept: */*
>
Empty reply from server
Connection #0 to host 192.168.0.4 left intact

PS C:\> New-Object System.Net.Sockets.TcpClient('DEST_IP_ADDRESS', PORT)

Available           : 0
Client              : System.Net.Sockets.Socket
Connected           : True
ExclusiveAddressUse : False
ReceiveBufferSize   : 131072
SendBufferSize      : 131072
ReceiveTimeout      : 0
SendTimeout         : 0
LingerState         : System.Net.Sockets.LingerOption
NoDelay             : False

Timeout connessione

I seguenti risultati indicano che la connessione ha superato il tempo di attesa. Se la connessione scade, vai a Verificare l'indirizzo IP e la porta del server.

$ curl -vso /dev/null --connect-timeout 5 DEST_IP_ADDRESS:PORT

Trying 192.168.0.4:443...
Connection timed out after 5000 milliseconds
Closing connection 0

PS C:\> New-Object System.Net.Sockets.TcpClient('DEST_IP_ADDRESS', PORT)

New-Object: Exception calling ".ctor" with "2" argument(s): "A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. 192.168.0.4:443"

Reimposta connessione

Un reset si verifica quando un dispositivo invia un pacchetto RST al client per informarlo che la connessione è stata interrotta. La connessione potrebbe essere reimpostata per uno dei seguenti motivi:

• Il server di ricezione non è stato configurato per accettare collegamenti per quel protocollo su quella porta. Ciò potrebbe essere dovuto al fatto che il pacchetto è stato inviato al server o alla porta sbagliati oppure al fatto che il software del server è stato configurato in modo errato.
• Il software del firewall ha rifiutato il tentativo di connessione

Se la connessione è stata reimpostata, vai a Verificare di accedere all'indirizzo IP e alla porta corretti.

$ curl -vso /dev/null --connect-timeout 5 DEST_IP_ADDRESS:PORT

Trying 192.168.0.4:443...
connect to 192.168.0.4 port 443 failed: Connection refused
Failed to connect to 192.168.0.4 port 443: Connection refused
Closing connection 0

PS C:\> New-Object System.Net.Sockets.TcpClientt('DEST_IP_ADDRESS', PORT)

New-Object: Exception calling ".ctor" with "2" argument(s): "No connection could be made because the target machine actively refused it. 192.168.0.4:443"

Verifica l'indirizzo IP e la porta del server

Esegui uno dei seguenti comandi sul server. Indicano se è presente un server in ascolto sulla porta necessaria.

$ sudo netstat -ltuvnp

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      588/sshd
tcp6       0      0 :::22                   :::*                    LISTEN      588/sshd
udp        0      0 0.0.0.0:68              0.0.0.0:*                           334/dhclient
udp        0      0 127.0.0.1:323           0.0.0.0:*                           429/chronyd
udp6       0      0 ::1:323                 :::*                                429/chronyd

PS C:\> Get-NetTcpConnection -State "LISTEN" -LocalPort DEST_PORT

LocalAddress LocalPort RemoteAddress RemotePort State  AppliedSetting OwningProcess
------------ --------- ------------- ---------- -----  -------------- -------------
::           443       ::            0          Listen                928
0.0.0.0      443       0.0.0.0       0          Listen                928

Se noti che il server non è associato alla porta o all'IP corretti o che il prefisso remoto non corrisponde al tuo client, consulta la documentazione del server o il fornitore per risolvere il problema. Il server deve essere associato all'indirizzo IP di una determinata interfaccia o a 0.0.0.0 e deve accettare le connessioni dal prefisso IP del client corretto o da 0.0.0.0.

Se il server dell'applicazione è associato all'indirizzo IP e alla porta corretti, potrebbe essere che il client stia accedendo alla porta sbagliata, che un protocollo di livello superiore (spesso TLS) stia rifiutando attivamente la connessione o che un firewall stia rifiutando la connessione.

Verifica che il client e il server utilizzino la stessa versione TLS e la stessa formazione di crittografia.

Verifica che il client acceda alla porta corretta.

Se i passaggi precedenti non risolvono il problema, vai a Verificare se il firewall su client e server elimina i pacchetti.

Controlla se il firewall su client e server elimina i pacchetti

Se il server non è raggiungibile dalla VM client, ma è in ascolto sulla porta corretta, è possibile che in una delle VM sia in esecuzione un software firewall che scarti i pacchetti associati alla connessione. Controlla il firewall sia sulle VM client sia su quelle server utilizzando i seguenti comandi.

Se una regola blocca il traffico, puoi aggiornare il software del firewall per consentirlo. Se aggiorni il firewall, procedi con cautela durante la preparazione e l'esecuzione dei comandi, perché un firewall configurato in modo errato può bloccare il traffico imprevisto. Valuta la possibilità di configurare l'accesso alla console seriale della VM prima di procedere.

$ sudo iptables -L -n -v -x

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts   bytes  target prot opt in  out  source      destination
10342 2078513    DROP  tcp  --  *  *    0.0.0.0/0   0.0.0.0/0 tcp dpt:5000

$ sudo iptables -A INPUT -p tcp -s SOURCE_IP_PREFIX --dport SERVER_PORT -j ACCEPT

$ sudo iptables -A OUTPUT -p tcp -d DEST_IP_PREFIX --dport DEST_PORT -j ACCEPT

PS C:\> Get-NetFirewallPortFilter | `
>>   Where-Object LocalPort -match  "PORT" | `
>>   Get-NetFirewallRule | `
>>   Where-Object {$_.Direction -match "Inbound" -and $_.Profile -match "Any"}

Name                  : {80D79988-C7A5-4391-902D-382369B4E4A3}
DisplayName           : iperf3 udp
Description           :
DisplayGroup          :
Group                 :
Enabled               : True
Profile               : Any
Platform              : {}
Direction             : Inbound
Action                : Allow
EdgeTraversalPolicy   : Block
LooseSourceMapping    : False
LocalOnlyMapping      : False
Owner                 :
PrimaryStatus         : OK
Status                : The rule was parsed successfully from the store. (65536)
EnforcementStatus     : NotApplicable
PolicyStoreSource     : PersistentStore
PolicyStoreSourceType : Local

PS C:\> netsh advfirewall firewall add rule name="My Firewall Rule" dir=out action=allow protocol=TCP remoteport=DEST_PORT

PS C:\> netsh advfirewall firewall add rule name="My Firewall Rule" dir=in action=allow protocol=TCP localport=PORT

Se rilevi un problema con le regole del firewall e lo correggi, verifica di nuovo la connettività. Se le regole del firewall non sembrano essere il problema, vai a Controllare la configurazione del routing del sistema operativo.

Controlla la configurazione del routing del sistema operativo

I problemi di routing del sistema operativo possono derivare da una delle seguenti situazioni:

• I problemi di routing sono più comuni nelle VM con più interfacce di rete a causa della complessità aggiuntiva del routing
• In una VM creata in Google Cloud con una singola interfaccia di rete, solitamente i problemi di routing si verificano solo se qualcuno ha modificato manualmente la tabella di routing predefinita
• In una VM di cui è stata eseguita la migrazione da un ambiente on-premise, potrebbero essere trasferite le impostazioni di routing o MTU necessarie on-premise, ma che causano problemi nella rete VPC

Se utilizzi una VM con più interfacce di rete, le route devono essere configurate per l'uscita alla vNIC e alla sottorete corrette. Ad esempio, una VM potrebbe avere route configurate in modo che il traffico destinato alle subnet interne venga inviato a una vNIC, ma il gateway predefinito (destinazione 0.0.0.0/0) sia configurato su un'altra vNIC con un indirizzo IP esterno o accesso a Cloud NAT.

Puoi esaminare i percorsi controllandoli singolarmente o esaminando l'intera tabella di routing della VM. Se uno dei due approcci rivela problemi con la tabella di routing, consulta la procedura descritta in Aggiornare le tabelle di routing, se necessario per istruzioni.

Rivedi tutti i percorsi

Elenca tutti i route per capire quali sono già presenti sulla tua VM.

$ ip route show table all

default via 10.3.0.1 dev ens4
10.3.0.1 dev ens4 scope link
local 10.3.0.19 dev ens4 table local proto kernel scope host src 10.3.0.19
broadcast 10.3.0.19 dev ens4 table local proto kernel scope link src 10.3.0.19
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
::1 dev lo proto kernel metric 256 pref medium
fe80::/64 dev ens4 proto kernel metric 256 pref medium
local ::1 dev lo table local proto kernel metric 0 pref medium
local fe80::4001:aff:fe03:13 dev ens4 table local proto kernel metric 0 pref medium
multicast ff00::/8 dev ens4 table local proto kernel metric 256 pref medium

PS C:\> Get-NetRoute

ifIndex DestinationPrefix             NextHop  RouteMetric ifMetric PolicyStore
------- -----------------             -------  ----------- -------- -----------
4       255.255.255.255/32            0.0.0.0          256 5        ActiveStore
1       255.255.255.255/32            0.0.0.0          256 75       ActiveStore
4       224.0.0.0/4                   0.0.0.0          256 5        ActiveStore
1       224.0.0.0/4                   0.0.0.0          256 75       ActiveStore
4       169.254.169.254/32            0.0.0.0            1 5        ActiveStore
1       127.255.255.255/32            0.0.0.0          256 75       ActiveStore
1       127.0.0.1/32                  0.0.0.0          256 75       ActiveStore
1       127.0.0.0/8                   0.0.0.0          256 75       ActiveStore
4       10.3.0.255/32                 0.0.0.0          256 5        ActiveStore
4       10.3.0.31/32                  0.0.0.0          256 5        ActiveStore
4       10.3.0.1/32                   0.0.0.0            1 5        ActiveStore
4       10.3.0.0/24                   0.0.0.0          256 5        ActiveStore
4       0.0.0.0/0                     10.3.0.1           0 5        ActiveStore
4       ff00::/8                      ::               256 5        ActiveStore
1       ff00::/8                      ::               256 75       ActiveStore
4       fe80::b991:6a71:ca62:f23f/128 ::               256 5        ActiveStore
4       fe80::/64                     ::               256 5        ActiveStore
1       ::1/128                       ::               256 75       ActiveStore

Controllare i singoli percorsi

Se il problema sembra riguardare un determinato prefisso IP, verifica che esistano route appropriati per gli IP di origine e di destinazione all'interno delle VM client e server.

$ ip route get DEST_IP

10.3.0.34 via 10.3.0.1 dev ens4 src 10.3.0.26 uid 1000
   cache

**RTNETLINK answers: Network is unreachable

PS C:\> Find-NetRoute -RemoteIpAddress "DEST_IP"

IPAddress         : 192.168.0.2
InterfaceIndex    : 4
InterfaceAlias    : Ethernet
AddressFamily     : IPv4
Type              : Unicast
PrefixLength      : 24
PrefixOrigin      : Dhcp
SuffixOrigin      : Dhcp
AddressState      : Preferred
ValidLifetime     : 12:53:13
PreferredLifetime : 12:53:13
SkipAsSource      : False
PolicyStore       : ActiveStore

Caption            :
Description        :
ElementName        :
InstanceID         : ;:8=8:8:9<>55>55:8:8:8:55;
AdminDistance      :
DestinationAddress :
IsStatic           :
RouteMetric        : 256
TypeOfRoute        : 3
AddressFamily      : IPv4
CompartmentId      : 1
DestinationPrefix  : 192.168.0.0/24
InterfaceAlias     : Ethernet
InterfaceIndex     : 4
InterfaceMetric    : 5
NextHop            : 0.0.0.0
PreferredLifetime  : 10675199.02:48:05.4775807
Protocol           : Local
Publish            : No
State              : Alive
Store              : ActiveStore
ValidLifetime      : 10675199.02:48:05.4775807
PSComputerName     :
ifIndex            : 4

Find-NetRoute : The network location cannot be reached. For information about network troubleshooting, see Windows Help.
At line:1 char:1
+ Find-NetRoute -RemoteIpAddress "192.168.0.4"
+ ----------------------------------------
    + CategoryInfo          : NotSpecified: (MSFT_NetRoute:ROOT/StandardCimv2/MSFT_NetRoute) [Find-NetRoute], CimException
    + FullyQualifiedErrorId : Windows System Error 1231,Find-NetRoute

Aggiorna le tabelle di routing

Se necessario, puoi aggiungere una route alla tabella dei percorsi del sistema operativo. Prima di eseguire un comando per aggiornare la tabella di routing della VM di routing, ti consigliamo di familiarizzare con i comandi e di comprendere le possibili implicazioni. L'uso improprio dei comandi di aggiornamento delle route potrebbe causare problemi imprevisti o disconnessione dalla VM. Valuta la possibilità di configurare l'accesso alla console seriale della VM prima di procedere.

Consulta la documentazione del sistema operativo per istruzioni su come aggiornare le route.

Se riscontri un problema con i percorsi e lo correggi, verifica di nuovo la connettività. Se i percorsi non sembrano essere il problema, vai a Controllare l'MTU dell'interfaccia.

Controlla MTU

L'MTU dell'interfaccia di una VM deve corrispondere all'MTU della rete VPC a cui è collegata. Idealmente, le VM che comunicano tra loro devono avere anche MTU corrispondenti. In genere, gli MTU non corrispondenti non sono un problema per TCP, ma possono esserlo per UDP.

Controlla l'MTU della VPC. Se le VM si trovano su due reti diverse, controlla entrambe le reti.

gcloud compute networks describe NET_NAME --format="table(name,mtu)"

Controlla la configurazione MTU per le interfacce di rete del client e del server.

$ netstat -i

Kernel Interface table
Iface      MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
ens4      1460  8720854      0      0 0      18270406      0      0      0 BMRU
lo       65536       53      0      0 0            53      0      0      0 LRU

PS C:\> Get-NetIpInterface

ifIndex InterfaceAlias              Address NlMtu(Bytes) Interface Dhcp     Connection PolicyStore
                                    Family               Metric             State
------- --------------              ------- ------------ --------- ----     ---------- -----------
4       Ethernet                    IPv6            1500         5 Enabled  Connected  ActiveStore
1       Loopback Pseudo-Interface 1 IPv6      4294967295        75 Disabled Connected  ActiveStore
4       Ethernet                    IPv4            1460         5 Enabled  Connected  ActiveStore
1       Loopback Pseudo-Interface 1 IPv4      4294967295        75 Disabled Connected  Active

Se gli MTU di interfaccia e rete non corrispondono, puoi riconfigurare l'MTU di interfaccia. Per ulteriori informazioni, consulta VM e impostazioni MTU. Se corrispondono e se hai seguito la procedura di risoluzione dei problemi fino a questo punto, è probabile che il problema sia con il server stesso. Per indicazioni sulla risoluzione dei problemi del server, consulta Controllare i log del server per informazioni sul comportamento del server.

Controlla i log del server per informazioni sul comportamento del server

Se i passaggi precedenti non risolvono il problema, è possibile che sia l'applicazione a causare i timeout. Controlla i log del server e dell'applicazione per verificare se sono presenti comportamenti che potrebbero spiegare il problema.

Origini log da controllare:

• Cloud Logging per la VM
• Log della porta seriale della VM
• Syslog e kern.log di Linux o Visualizzatore eventi di Windows

Se continui a riscontrare problemi

Se i problemi persistono, consulta la sezione Ricevere assistenza per conoscere i passaggi successivi. È utile avere a disposizione l'output dei passaggi per la risoluzione dei problemi precedenti da condividere con altri collaboratori.

Risolvere i problemi di latenza o perdita di rete che causano problemi di throughput

I problemi di latenza o perdita di rete sono in genere causati dall'esaurimento delle risorse o da colli di bottiglia all'interno di una VM o di un percorso di rete. A volte, la perdita di rete può causare timeout intermittenti della connessione. Cause come l'esaurimento delle vCPU o la saturazione delle vNIC comportano un aumento della latenza e della perdita di pacchetti, con conseguente riduzione delle prestazioni della rete.

Le istruzioni riportate di seguito presuppongono che le connessioni non si interrompano in modo coerente e che tu stia riscontrando problemi di capacità o prestazioni limitate. Se si verifica una perdita completa dei pacchetti, consulta Risolvere i problemi di interruzione completa della connessione.

Piccole variazioni di latenza, ad esempio la latenza che varia di alcuni millisecondi, sono normali. Le latenze variano a causa del carico della rete o delle code all'interno della VM.

Determina i valori di connessione

Innanzitutto, raccogli le seguenti informazioni:

• Nella pagina Istanze VM, raccoglie quanto segue per entrambe le VM:
  • Nomi VM
  • Zone VM
  • Indirizzi IP interni per le vNIC in comunicazione
• Dalla configurazione del software del server di destinazione, raccogli le seguenti informazioni:
  • Protocollo di livello 4
  • Porta di destinazione

Se riscontri problemi con più VM, scegli una singola VM di origine e una singola VM di destinazione con problemi e utilizza questi valori. In genere, non è necessaria la porta di origine della connessione.

Una volta ottenute queste informazioni, vai a Esaminare i problemi della rete di Google sottostante.

Esaminare i problemi relativi alla rete di Google sottostante

Se la tua configurazione è esistente e non è cambiata di recente, il problema potrebbe riguardare la rete di Google sottostante. Controlla la perdita di pacchetti tra le zone VM nella dashboard sul rendimento del Network Intelligence Center. Se si verifica un aumento della perdita di pacchetti tra le zone durante il periodo di tempo in cui si sono verificati timeout di rete, potrebbe indicare che il problema riguarda la rete fisica sottostante alla rete virtuale. Controlla la dashboard dello stato di Google Cloud per verificare la presenza di problemi noti prima di inviare una richiesta di assistenza.

Se il problema non sembra riguardare la rete Google sottostante, vai a Verificare la latenza dell'handshake.

Controlla la latenza dell'handshake

Tutti i protocolli basati su connessione presentano una certa latenza durante l'handshake di configurazione della connessione. Ogni handshake del protocollo aumenta il sovraccarico. Per le connessioni SSL/TLS, ad esempio, l'handshake TCP deve essere completato prima che possa iniziare l'handshake SSL/TLS, quindi l'handshake TLS deve essere completato prima che i dati possano essere trasmessi.

La latenza di handshake nella stessa zona Google Cloud è in genere trascurabile, ma i handshake con località distanti a livello globale potrebbero aggiungere ritardi maggiori all'inizio della connessione. Se hai risorse in regioni distanti, puoi controllare se la latenza che stai riscontrando è dovuta all'handshake del protocollo.

$ curl -o /dev/null -Lvs -w 'tcp_handshake: %{time_connect}s, application_handshake: %{time_appconnect}s' DEST_IP:PORT

tcp_handshake: 0.035489s, application_handshake: 0.051321s

Se la latenza è superiore a quella prevista dai handshake, vai a Determinare la velocità effettiva massima del tipo di VM.

Determina la velocità effettiva massima del tipo di VM

La velocità effettiva di uscita della rete della VM è limitata dall'architettura della CPU e dal numero di vCPU della VM. Per determinare la potenziale larghezza di banda in uscita della tua VM, consulta la pagina Larghezza di banda della rete.

Se la tua VM non è in grado di soddisfare i requisiti di uscita, valuta la possibilità di eseguire l'upgrade a una VM con una maggiore capacità. Per istruzioni, consulta Modificare il tipo di macchina di un'istanza.

Se il tipo di macchina dovrebbe consentire una larghezza di banda in uscita sufficiente, controlla se l'utilizzo Persistent Disk interferisce con l'uscita della rete. Le operazioni dei Persistent Disk possono occupare fino al 60% del throughput di rete totale della VM. Per determinare se le operazioni dei Persistent Disk potrebbero interferire con il throughput della rete, consulta Verificare il rendimento dei dischi permanenti.

L'ingresso di rete in una VM non è limitato dalla rete VPC o dal tipo di istanza VM. ma dal rendimento di elaborazione e messa in coda dei pacchetti del sistema operativo o dell'applicazione della VM. Se la larghezza di banda in uscita è adeguata, ma si verificano problemi in entrata, consulta Controllare i log del server per informazioni sul comportamento del server.

Controlla l'MTU dell'interfaccia

L'MTU di una rete VPC è configurabile. L'MTU dell'interfaccia sulla VM deve corrispondere al valore MTU della rete VPC a cui è collegata. In un caso di peering di rete VPC, le VM in reti diverse possono avere MTU diversi. Quando si verifica questo scenario, applica il valore MTU più piccolo alle interfacce associate. In genere, le mancata corrispondenza dell'MTU non sono un problema per TCP, ma possono esserlo per UDP.

Controlla l'MTU della VPC. Se le VM si trovano su due reti diverse, controlla entrambe le reti.

gcloud compute networks describe NET_NAME --format="table(name,mtu)"

Controlla la configurazione MTU per l'interfaccia di rete.

$ netstat -i

Kernel Interface table
Iface      MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
ens4      1460  8720854      0      0 0      18270406      0      0      0 BMRU
lo       65536       53      0      0 0            53      0      0      0 LRU

PS C:\> Get-NetIpInterface

ifIndex InterfaceAlias              Address NlMtu(Bytes) Interface Dhcp     Connection PolicyStore
                                    Family               Metric             State
------- --------------              ------- ------------ --------- ----     ---------- -----------
4       Ethernet                    IPv6            1500         5 Enabled  Connected  ActiveStore
1       Loopback Pseudo-Interface 1 IPv6      4294967295        75 Disabled Connected  ActiveStore
4       Ethernet                    IPv4            1460         5 Enabled  Connected  ActiveStore
1       Loopback Pseudo-Interface 1 IPv4      4294967295        75 Disabled Connected  Active

Se gli MTU di interfaccia e rete non corrispondono, puoi riconfigurare l'MTU di interfaccia. Per istruzioni su come aggiornare il valore MTU per le VM Windows, consulta VM e impostazioni MTU. Se corrispondono, è probabile che il problema sia la disponibilità del server. Il passaggio successivo consiste nel controllare i log per verificare se una VM è stata riavviata, interrotta o sottoposta a migrazione live per vedere se è successo qualcosa alla VM durante il periodo di tempo pertinente.

Controlla i log per verificare se una VM è stata riavviata, interrotta o sottoposta a migrazione in tempo reale

Durante il ciclo di vita di una VM, questa può essere riavviata dall'utente, sottoposta a migrazione live per la manutenzione di Google Cloud o, in rare circostanze, potrebbe essere persa e ricreata se si verifica un errore nell'host fisico contenente la VM. Questi eventi potrebbero causare un breve aumento della latenza o timeout di connessione. Se accade uno di questi eventi alla VM, l'evento viene registrato.

Per visualizzare i log della VM:

1. Nella console Google Cloud, vai alla pagina Logging.

   Vai a Logging

2. Scegli il periodo di tempo in cui si è verificata la latenza.

3. Utilizza la seguente query di logging per determinare se si è verificato un evento VM nel periodo di tempo in cui si è verificata la latenza:

   resource.labels.instance_id:"INSTANCE_NAME"
   resource.type="gce_instance"
   (
     protoPayload.methodName:"compute.instances.hostError" OR
     protoPayload.methodName:"compute.instances.OnHostMaintenance" OR
     protoPayload.methodName:"compute.instances.migrateOnHostMaintenance" OR
     protoPayload.methodName:"compute.instances.terminateOnHostMaintenance" OR
     protoPayload.methodName:"compute.instances.stop" OR
     protoPayload.methodName:"compute.instances.reset" OR
     protoPayload.methodName:"compute.instances.automaticRestart" OR
     protoPayload.methodName:"compute.instances.guestTerminate" OR
     protoPayload.methodName:"compute.instances.instanceManagerHaltForRestart" OR
     protoPayload.methodName:"compute.instances.preempted"
   )
   

Se le VM non sono state riavviate o non è stata eseguita la migrazione durante il periodo di tempo pertinente, il problema potrebbe riguardare l'esaurimento delle risorse. Per verificare, vai a Controllare le statistiche di rete e del sistema operativo per verificare l'eliminazione dei pacchetti a causa dell'esaurimento delle risorse.

Controlla le statistiche di rete e del sistema operativo per verificare se i pacchetti vengono eliminati a causa dell'esaurimento delle risorse

Esaurimento delle risorse è un termine generale che indica che a una risorsa della VM, ad esempio la larghezza di banda in uscita, viene chiesto di gestire più di quanto possa. L'esaurimento delle risorse può comportare l'eliminazione periodica dei pacchetti, che causa la latenza o i timeout della connessione. Questi timeout potrebbero non essere visibili all'avvio del client o del server, ma potrebbero comparire nel tempo man mano che il sistema esaurisce le risorse.

Di seguito è riportato un elenco di comandi che mostrano contatori e statistiche dei pacchetti. Alcuni di questi comandi duplicano i risultati di altri comandi. In questi casi, puoi utilizzare il comando più adatto alle tue esigenze. Consulta le note in ogni sezione per comprendere meglio il risultato previsto dell'esecuzione del comando. Può essere utile eseguire i comandi in momenti diversi per verificare se si verificano scarti o errori contemporaneamente al problema.

PS C:\> netstat -s

IPv4 Statistics

  Packets Received                   = 56183
  Received Header Errors             = 0
  Received Address Errors            = 0
  Datagrams Forwarded                = 0
  Unknown Protocols Received         = 0
  Received Packets Discarded         = 25
  Received Packets Delivered         = 56297
  Output Requests                    = 47994
  Routing Discards                   = 0
  Discarded Output Packets           = 0
  Output Packet No Route             = 0
  Reassembly Required                = 0
  Reassembly Successful              = 0
  Reassembly Failures                = 0
  Datagrams Successfully Fragmented  = 0
  Datagrams Failing Fragmentation    = 0
  Fragments Created                  = 0

Se riscontri un esaurimento delle risorse, puoi provare a distribuire il carico di lavoro su più istanze, eseguire l'upgrade della VM a una con più risorse, ottimizzare il sistema operativo o l'applicazione per esigenze di prestazioni specifiche, inserire il messaggio di errore in un motore di ricerca per cercare possibili soluzioni o chiedere aiuto utilizzando uno dei metodi descritti in Se continui a riscontrare problemi.

Se il problema non sembra essere l'esaurimento delle risorse, il problema potrebbe riguardare il software del server stesso. Per indicazioni sulla risoluzione dei problemi relativi al software del server, vai a Controllare i log del server per informazioni sul comportamento del server.

Controlla i log del server per informazioni sul comportamento del server

Se i passaggi precedenti non rivelano un problema, i timeout potrebbero essere causati dal comportamento dell'applicazione, ad esempio da interruzioni dell'elaborazione causate dall'esaurimento delle vCPU. Controlla i log del server e delle applicazioni per verificare se sono presenti indicazioni sul comportamento riscontrato.

Ad esempio, un server con una latenza aumentata a causa di un sistema a monte, ad esempio un database sotto carico, potrebbe mettere in coda una quantità eccessiva di richieste, il che può causare un aumento dell'utilizzo della memoria e dei tempi di attesa della CPU. Questi fattori potrebbero causare connessioni non riuscite o un sovraccarico del buffer del socket.

A volte le connessioni TCP perdono un pacchetto, ma il riconoscimento selettivo e la ritrasmissione dei pacchetti di solito recuperano i pacchetti persi, evitando il timeout della connessione. Tieni invece presente che i timeout potrebbero essere stati causati dal fallimento o dal nuovo dispiegamento del server delle applicazioni, causando un errore momentaneo per le connessioni.

Se l'applicazione del server si basa su una connessione a un database o a un altro servizio, verifica che il rendimento dei servizi accoppiati non sia scadente. La tua applicazione potrebbe monitorare queste metriche.

Se continui a riscontrare problemi

Se i problemi persistono, consulta la sezione Ricevere assistenza per conoscere i passaggi successivi. È utile avere a disposizione l'output dei passaggi per la risoluzione dei problemi da condividere con altri collaboratori.

Passaggi successivi

• Se i problemi persistono, consulta la pagina Risorse.