Risolvi 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 Virtual Private Cloud (VPC) (VPC condiviso o autonomo) o in due reti VPC connesse con 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 una singola rete VPC.
- Connessioni da VM a VM che utilizzano indirizzi IP interni all'interno di una rete VPC condiviso.
- Connessioni da VM a 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 in tutte le immagini del sistema operativo fornite da Google. Se utilizzi la tua immagine del sistema operativo, potresti dover installare gli strumenti.
Quantifica il problema
- Se ritieni di aver subito una perdita completa di pacchetti, vai a Risolvere i problemi di errore di connessione completo.
- Se riscontri latenza, perdita parziale di pacchetti o timeout che si verificano a metà connessione, vai a Risolvere i problemi di latenza o perdita di rete che causano problemi di velocità effettiva.
Risolvere il problema di connessione completa
Le seguenti sezioni forniscono i passaggi per risolvere i problemi di errore completo della connettività interna tra le VM. Se invece riscontri una latenza maggiore o timeout di connessione intermittenti, vai a Risolvere i problemi di latenza o perdita di rete che causano problemi di velocità effettiva.
Determina i valori di connessione
Innanzitutto, raccogli le seguenti informazioni:
- Nella pagina Istanze VM,
raccogli le seguenti informazioni per entrambe le VM:
- Nomi VM
- Zone VM
- Indirizzi IP interni delle vNIC che comunicano
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 tua 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 che presentano problemi e utilizza questi valori. In generale, non dovresti aver bisogno della porta di origine della connessione.
Una volta raccolte queste informazioni, vai a Investigare i problemi con la rete Google sottostante.
Esaminare i problemi relativi alla rete Google sottostante
Se la tua configurazione è esistente e non è stata modificata di recente, il problema potrebbe riguardare la rete Google sottostante. Controlla la Performance Dashboard di Network Intelligence Center per la perdita di pacchetti tra le zone VM. 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 riguardava la rete fisica sottostante la tua rete virtuale. Prima di inviare una richiesta di assistenza, controlla la dashboard dello stato di Google Cloud per verificare la presenza di problemi noti.
Se il problema non sembra riguardare la rete Google sottostante, vai a Controllare le regole firewall Google Cloud configurate in modo errato.
Controlla la presenza di regole firewall configurate in modo errato in Google Cloud
Connectivity Tests analizza la configurazione del percorso di rete VPC tra due VM e mostra se la configurazione programmata deve consentire o meno il traffico. Se il traffico non è consentito, i risultati mostrano se una regola firewall Google Cloud in uscita o in entrata blocca il traffico o se una route non è disponibile.
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 esegue il test del firewall del sistema operativo, delle route del sistema operativo o del software server sulla VM.
La seguente procedura esegue Connectivity Tests dalla consoleGoogle Cloud . Per altri modi per eseguire i test, vedi Esecuzione di Connectivity Tests.
Per creare ed eseguire un test:
Nella console Google Cloud , vai alla pagina Test di connettività.
Nel menu a discesa del progetto, verifica di trovarti nel progetto corretto o specifica quello corretto.
Fai clic su Crea test di connettività.
Assegna un nome al test.
Specifica quanto segue:
- Protocollo
- Indirizzo IP dell'endpoint di origine
- Progetto e rete VPC di origine
- Indirizzo IP endpoint di destinazione
- Progetto e rete VPC di destinazione
- Porta di destinazione
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 Google Cloud, determina se la configurazione di sicurezza prevista deve consentire la connessione. Potresti dover chiedere i dettagli al tuo amministratore di sicurezza o di rete. Se il traffico deve essere consentito, controlla
quanto segue:
- Controlla l'elenco Traffico sempre bloccato. Se il traffico è bloccato da Google Cloud come descritto nell'elenco del traffico sempre bloccato, la tua configurazione esistente non funzionerà.
- Vai alla pagina Policy del firewall e rivedi 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 firewall configurata correttamente che blocca questo traffico, contatta l'amministratore di rete o della sicurezza. 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à VPC, il problema potrebbe essere uno dei seguenti.
- Problemi con la configurazione del sistema operativo guest, ad esempio problemi con il software firewall.
- Problemi con le applicazioni client o server, ad esempio l'applicazione è bloccata o configurata per l'ascolto sulla porta errata.
I passaggi successivi ti guideranno nell'esame di ciascuna di queste possibilità. Continua con Testa la connettività TCP dall'interno della VM.
Testa la connettività TCP dall'interno della VM
Se il test di connettività VM-VM non ha rilevato un problema di configurazione VPC, inizia a testare la connettività OS-OS. I seguenti passaggi ti aiutano a determinare:
- Se un server TCP è in ascolto sulla porta indicata
- Se il software firewall lato server consente le connessioni a questa porta dalla VM client
- Se il software firewall lato client consente le connessioni a questa 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 ripristino della connessione.
- Riuscita:se l'handshake TCP viene completato correttamente, non è presente una regola firewall del sistema operativo che blocca la connessione, il sistema operativo inoltra correttamente i pacchetti e 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 la registrazione del server per informazioni sul comportamento del server.
- Timeout:se la connessione va in timeout, di solito significa una delle
seguenti cose:
- Non esiste alcuna macchina a questo indirizzo IP
- Da qualche parte c'è un firewall che scarta silenziosamente i tuoi pacchetti
- Il routing dei pacchetti del sistema operativo invia i pacchetti a una destinazione che non può elaborarli oppure il routing asimmetrico invia il pacchetto di ritorno su un percorso non valido
Ripristino:se la connessione viene ripristinata, significa che l'IP di destinazione riceve i pacchetti, ma un sistema operativo o un'applicazione li rifiuta. Ciò può significare una delle seguenti cose:
- I pacchetti arrivano sulla 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 sta reimpostando la connessione. È meno probabile che un firewall scarti silenziosamente i pacchetti, ma può succedere.
Linux
Nella console Google Cloud , vai alla pagina Policy firewall.
Assicurati che esista una regola firewall che consenta le connessioni SSH da IAP alla tua VM o creane una nuova.
Nella console Google Cloud , vai alla pagina Istanze VM.
Trova la VM di origine.
Fai clic su SSH nella colonna Connetti per quella VM.
Dalla riga di comando della macchina client, esegui questo comando. Sostituisci DEST_IP:DEST_PORT con l'indirizzo IP e la porta di destinazione.
curl -vso /dev/null --connect-timeout 5 DEST_IP:DEST_PORT
Windows
Nella console Google Cloud , vai alla pagina Istanze VM.
Trova la VM di origine.
Utilizza uno dei metodi descritti in Connessione alle VM Windows per connetterti alla VM.
Dalla riga di comando della macchina client, esegui questo comando:
- Windows 2019:
curl -vso /dev/null --connect-timeout 5 DEST_IP:DEST_PORT
- Windows 2012 o Windows 2016 Powershell:
PS C:> New-Object System.Net.Sockets.TcpClient('DEST_IP',DEST_PORT)`
- Windows 2019:
Connessione riuscita
I seguenti risultati indicano che l'handshake TCP è riuscito. Se l'handshake TCP viene completato correttamente, il problema non è correlato al timeout o al ripristino della connessione TCP. Il problema di timeout si verifica invece all'interno dei livelli dell'applicazione. Se la connessione viene stabilita, vai a Controllare la registrazione del server per informazioni sul comportamento del server.
Linux e Windows 2019
$ curl -vso /dev/null --connect-timeout 5 192.168.0.4:443
La riga "Connesso a" indica che l'handshake TCP è riuscito.
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
Windows 2012 e 2016
PS C:\> New-Object System.Net.Sockets.TcpClient('DEST_IP_ADDRESS', PORT)
Risultato della connessione riuscita. La riga "Connected: True" è pertinente.
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 è scaduta. Se la connessione scade, vai a Verificare l'indirizzo IP e la porta del server.
Linux e Windows 2019
$ curl -vso /dev/null --connect-timeout 5 DEST_IP_ADDRESS:PORT
Risultato del timeout della connessione:
Trying 192.168.0.4:443... Connection timed out after 5000 milliseconds Closing connection 0
Windows 2012 e 2016
PS C:\> New-Object System.Net.Sockets.TcpClient('DEST_IP_ADDRESS', PORT)
Risultato del timeout della connessione:
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 ripristino si verifica quando un dispositivo invia un pacchetto RST al client, informandolo che la connessione è stata terminata. La connessione potrebbe essere ripristinata per uno dei seguenti motivi:
- Il server di ricezione non è stato configurato per accettare connessioni per quel protocollo su quella porta. Ciò potrebbe essere dovuto al fatto che il pacchetto è stato inviato al server o alla porta sbagliati oppure il software del server è stato configurato in modo errato.
- Il software firewall ha rifiutato il tentativo di connessione
Se la connessione è stata reimpostata, vai a Verifica di accedere all'indirizzo IP e alla porta corretti.
Linux e Windows 2019
$ curl -vso /dev/null --connect-timeout 5 DEST_IP_ADDRESS:PORT
Risultato del ripristino della connessione:
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
Windows 2012 e 2016
PS C:\> New-Object System.Net.Sockets.TcpClientt('DEST_IP_ADDRESS', PORT)
Risultato del ripristino della connessione:
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"
Verificare 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.
Linux
$ sudo netstat -ltuvnp
L'output mostra che un server TCP è in ascolto di qualsiasi indirizzo IP di destinazione
(0.0.0.0) sulla porta 22, accettando connessioni da qualsiasi indirizzo di origine
(0.0.0.0) e qualsiasi porta di origine (*). La colonna PID/Program name specifica
l'eseguibile associato al socket.
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
Windows
PS C:\> Get-NetTcpConnection -State "LISTEN" -LocalPort DEST_PORT
L'output mostra i risultati del comando eseguito con DEST_PORT impostato su 443.
Questo output mostra che un server TCP è in ascolto di qualsiasi indirizzo (0.0.0.0) sulla porta 443, accettando connessioni da qualsiasi indirizzo di origine (0.0.0.0) e qualsiasi porta di origine (0). La colonna OwningProcess indica l'ID processo del processo in ascolto del socket.
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 o il fornitore del server per risolvere il problema. Il server deve essere associato all'indirizzo IP di un'interfaccia specifica o a 0.0.0.0 e deve accettare connessioni dal prefisso IP client corretto o da 0.0.0.0.
Se il server delle applicazioni è associato all'indirizzo IP e alla porta corretti, è possibile che il client acceda alla porta errata, che un protocollo di livello superiore (spesso TLS) rifiuti attivamente la connessione o che un firewall rifiuti la connessione.
Verifica che il client e il server utilizzino la stessa versione di 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 Controllare il firewall sul client e sul server per verificare l'eliminazione dei pacchetti.
Controlla il firewall sul client e sul server per verificare l'eliminazione dei pacchetti
Se il server non è raggiungibile dalla VM client, ma è in ascolto sulla porta corretta, una delle VM potrebbe eseguire un software firewall che scarta i pacchetti associati alla connessione. Controlla il firewall sia sulla VM client che su quella server utilizzando i seguenti comandi.
Se una regola blocca il traffico, puoi aggiornare il software firewall per consentire il traffico. 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. Prima di procedere, valuta la possibilità di configurare l'accesso alla console seriale della VM.
iptables Linux
Controlla i conteggi dei pacchetti per il numero di pacchetti elaborati per ogni catena e regola iptables installata. Determina a quali regole DROP viene applicata la corrispondenza confrontando gli indirizzi IP e le porte di origine e di destinazione con i prefissi e le porte specificati dalle regole iptables.
Se una regola corrispondente mostra un numero crescente di scarti con timeout di connessione,
consulta la documentazione di iptables per applicare la regola allow corretta alle
connessioni appropriate.
$ sudo iptables -L -n -v -x
Questa catena INPUT di esempio mostra che i pacchetti da qualsiasi indirizzo IP a qualsiasi indirizzo IP che utilizza la porta TCP di destinazione 5000 verranno eliminati dal firewall.
La colonna pkts indica che la regola ha eliminato 10342 pacchetti. Come
test, se crei connessioni scartate da questa regola, vedrai
aumentare il contatore dei pacchetti, a conferma del comportamento.
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
Puoi aggiungere una regola in entrata o in uscita a iptables con i seguenti comandi:
Regola in entrata:
$ sudo iptables -A INPUT -p tcp -s SOURCE_IP_PREFIX --dport SERVER_PORT -j ACCEPT
Regola in uscita:
$ sudo iptables -A OUTPUT -p tcp -d DEST_IP_PREFIX --dport DEST_PORT -j ACCEPT
Firewall di Windows
Verifica in Windows Firewall che la connessione sia consentita in uscita dal client e in entrata al server. Se una regola blocca il traffico, apporta le correzioni necessarie in Windows Firewall per consentire le connessioni. Puoi anche abilitare la registrazione del firewall di Windows.
Il comportamento predefinito DENY di Windows Firewall consiste nell'eliminare silenziosamente i pacchetti negati, causando timeout.
Questo comando controlla il server. Per controllare le regole in uscita sulla VM client, modifica il valore di -match in Outbound.
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
Puoi aggiungere una nuova regola firewall a Windows con i seguenti comandi.
Regola in uscita:
PS C:\> netsh advfirewall firewall add rule name="My Firewall Rule" dir=out action=allow protocol=TCP remoteport=DEST_PORT
Regola in entrata:
PS C:\> netsh advfirewall firewall add rule name="My Firewall Rule" dir=in action=allow protocol=TCP localport=PORT
Software di terze parti
Anche i firewall delle applicazioni di terze parti o i software antivirus possono interrompere o rifiutare le connessioni. Consulta la documentazione fornita dal tuo fornitore.
Se riscontri un problema con le regole firewall e lo correggi, esegui di nuovo il test della connettività. Se le regole 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 sulle VM con più interfacce di rete a causa della maggiore complessità del routing
- Su una VM creata in Google Cloud con una singola interfaccia di rete, i problemi di routing si verificano normalmente solo se qualcuno ha modificato manualmente la tabella di routing predefinita
- Su una VM di cui è stata eseguita la migrazione da on-premise, la VM potrebbe riportare 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 verso la vNIC e la subnet 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 le route controllando singolarmente ogni route o visualizzando l'intera tabella di routing della VM. Se uno dei due approcci rivela problemi con la tabella di routing, consulta i passaggi riportati in Aggiornare le tabelle di routing, se necessario per istruzioni.
Rivedere tutti gli itinerari
Elenca tutte le tue route per capire quali esistono già nella tua VM.
Linux
$ 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
Windows
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 itinerari
Se un determinato prefisso IP sembra essere il problema, verifica che esistano route appropriate per gli IP di origine e di destinazione all'interno delle VM client e server.
Linux
$ ip route get DEST_IP
Risultato positivo:
Viene mostrato un percorso valido. In questo caso, i pacchetti escono dall'interfaccia ens4.
10.3.0.34 via 10.3.0.1 dev ens4 src 10.3.0.26 uid 1000 cache
Risultato negativo:
Questo risultato conferma che i pacchetti vengono eliminati perché non esiste un percorso verso la rete di destinazione. Verifica che la tabella di routing contenga un percorso verso l'interfaccia di uscita corretta.
**RTNETLINK answers: Network is unreachable
Windows
PS C:\> Find-NetRoute -RemoteIpAddress "DEST_IP"
Risultato positivo:
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
Risultato negativo:
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
Questo comando conferma che i pacchetti vengono eliminati perché non esiste un percorso verso l'indirizzo IP di destinazione. Verifica di avere un gateway predefinito e che questo sia applicato alla vNIC e alla rete corrette.
Aggiorna tabelle di routing
Se necessario, puoi aggiungere una route alla tabella di routing 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 alla VM. Prima di procedere, valuta la possibilità di configurare l'accesso alla console seriale della VM.
Consulta la documentazione del sistema operativo per istruzioni sull'aggiornamento delle route.
Se riscontri un problema con le route e lo correggi, esegui nuovamente il test della connettività. Se le route non sembrano essere il problema, vai a Controllare l'MTU dell'interfaccia.
Controllare l'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 hanno anche MTU corrispondenti. In genere, le MTU non corrispondenti non sono un problema per TCP, ma possono esserlo per UDP.
Controlla l'MTU del VPC. Se le VM si trovano in 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.
Linux
$ netstat -i
L'interfaccia lo (loopback) ha sempre una MTU di 65536 e può essere ignorata per questo passaggio.
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
Windows
PS C:\> Get-NetIpInterface
Le pseudo-interfacce di loopback hanno sempre una MTU di 4294967295 e possono essere ignorate per questo passaggio.
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 le MTU dell'interfaccia e della rete non corrispondono, puoi riconfigurare la MTU dell'interfaccia. Per saperne di più, consulta VM e impostazioni MTU. Se corrispondono e se hai seguito finora la procedura per la risoluzione dei problemi, il problema riguarda probabilmente il server stesso. Per indicazioni sulla risoluzione dei problemi del server, vai a Controllare la registrazione del server per informazioni sul comportamento del server.
Controlla la registrazione dei log del server per informazioni sul comportamento del server
Se i passaggi precedenti non risolvono un problema, l'applicazione potrebbe causare i timeout. Controlla i log del server e dell'applicazione per individuare comportamenti che spieghino ciò che stai vedendo.
Origini log da controllare:
- Cloud Logging per la VM
- Log seriali VM
- syslog e kern.log di Linux o Visualizzatore eventi di Windows
Se continui a riscontrare problemi
Se i problemi persistono, consulta la sezione Richiedere assistenza per i passaggi successivi. È utile avere 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 velocità effettiva
I problemi di latenza o perdita di rete sono in genere causati dall'esaurimento delle risorse o dai colli di bottiglia all'interno di una VM o di un percorso di rete. A volte la perdita di rete può causare timeout di connessione intermittenti. 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 di rete.
Le seguenti istruzioni presuppongono che le connessioni non vadano costantemente in timeout e che tu stia invece riscontrando problemi di capacità o rendimento limitati. Se riscontri una perdita completa di pacchetti, vedi Risolvere i problemi relativi all'interruzione completa della connessione.
Piccole variazioni della latenza, ad esempio latenze che variano di pochi millisecondi, sono normali. Le latenze variano a causa del carico di rete o della coda all'interno della VM.
Determina i valori di connessione
Innanzitutto, raccogli le seguenti informazioni:
- Nella pagina Istanze VM,
raccogli le seguenti informazioni per entrambe le VM:
- Nomi VM
- Zone VM
- Indirizzi IP interni delle vNIC che comunicano
- 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 che presentano problemi e utilizza questi valori. In generale, non dovresti aver bisogno della porta di origine della connessione.
Una volta raccolte queste informazioni, vai a Investigare i problemi con la rete Google sottostante.
Esaminare i problemi relativi alla rete Google sottostante
Se la tua configurazione è esistente e non è stata modificata di recente, il problema potrebbe riguardare la rete Google sottostante. Controlla la Performance Dashboard di Network Intelligence Center per la perdita di pacchetti tra le zone VM. Se si verifica un aumento della perdita di pacchetti tra le zone durante il periodo di tempo in cui hai riscontrato timeout di rete, potrebbe indicare che il problema riguarda la rete fisica sottostante la tua rete virtuale. Prima di inviare una richiesta di assistenza, controlla la dashboard dello stato di Google Cloud per verificare la presenza di problemi noti.
Se il problema non sembra riguardare la rete Google sottostante, vai a Controllare la latenza dell'handshake.
Controllare la latenza dell'handshake
Tutti i protocolli basati sulla connessione comportano una certa latenza durante l'handshake di configurazione della connessione. Ogni handshake del protocollo aumenta l'overhead. 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 gli handshake con località distanti a livello globale potrebbero aggiungere ritardi maggiori all'avvio della connessione. Se hai risorse in regioni distanti, puoi verificare se la latenza che riscontri è dovuta all'handshake del protocollo.
Linux e Windows 2019
$ 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
- tcp_handshake è la durata che intercorre tra l'invio del pacchetto SYN iniziale da parte del client e l'invio dell'ACK dell'handshake TCP da parte del client.
- application_handshake è il tempo che intercorre dal primo pacchetto SYN dell'handshake TCP al completamento dell'handshake TLS (in genere).
- tempo di handshake aggiuntivo = application_handshake - tcp_handshake
Windows 2012 e 2016
Non disponibile con gli strumenti del sistema operativo predefiniti. Il tempo di round trip ICMP può essere utilizzato come riferimento se le regole firewall lo consentono.
Se la latenza è superiore a quella prevista per gli handshake, vai a Determinare il throughput massimo del tipo di VM.
Determinare il throughput massimo del tipo di VM
La velocità effettiva di uscita della rete VM è limitata dall'architettura della CPU della VM e dal numero di vCPU. Determina la potenziale larghezza di banda in uscita della tua VM consultando la pagina Larghezza di banda di rete.
Se la tua VM non è in grado di soddisfare i tuoi requisiti di traffico in uscita, valuta la possibilità di eseguire l'upgrade a una VM con maggiore capacità. Per istruzioni, vedi Modifica del tipo di macchina di un'istanza.
Se il tipo di macchina dovrebbe consentire una larghezza di banda di uscita sufficiente, verifica se l'utilizzo di Persistent Disk interferisce con l'uscita di rete. Le operazioni di Persistent Disk possono occupare fino al 60% del throughput di rete totale della VM. Per determinare se le operazioni di Persistent Disk potrebbero interferire con il throughput di rete, consulta Controllare le prestazioni di Persistent Disk.
L'ingresso di rete a una VM non è limitato dalla rete VPC o dal tipo di istanza VM. Viene invece determinata dalle prestazioni di accodamento e elaborazione dei pacchetti del sistema operativo o dell'applicazione della VM. Se la larghezza di banda in uscita è adeguata, ma riscontri 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 della VM deve corrispondere al valore MTU della rete VPC a cui è collegata. In una situazione di peering di rete VPC, le VM in reti diverse possono avere MTU diverse. Quando si verifica questo scenario, applica il valore MTU più piccolo alle interfacce associate. I mancati corrispondenti MTU in genere non sono un problema per TCP, ma possono esserlo per UDP.
Controlla l'MTU del VPC. Se le VM si trovano in 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.
Linux
L'interfaccia lo (loopback) ha sempre un MTU di 65536 e può essere ignorata per questo passaggio.
$ 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
Windows
PS C:\> Get-NetIpInterface
Le pseudo-interfacce di loopback hanno sempre una MTU di 4294967295 e possono essere ignorate per questo passaggio.
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 le MTU dell'interfaccia e della rete non corrispondono, puoi riconfigurare la MTU dell'interfaccia. Per istruzioni sull'aggiornamento dell'MTU per le VM Windows, consulta VM e impostazioni MTU. Se corrispondono, il problema potrebbe essere la disponibilità del server. Il passaggio successivo consiste nel controllare i log per verificare se una VM è stata riavviata, arrestata o sottoposta a migrazione live per vedere se è successo qualcosa alla tua VM durante il periodo di tempo pertinente.
Controlla i log per vedere se una VM è stata riavviata, arrestata o sottoposta a migrazione live
Durante il ciclo di vita di una VM, questa può essere riavviata dall'utente, sottoposta a migrazione live per la manutenzione diGoogle Cloud o, in rare circostanze, potrebbe essere persa e ricreata in caso di errore all'interno dell'host fisico che contiene la VM. Questi eventi potrebbero causare un breve aumento della latenza o timeout della connessione. Se si verifica uno di questi eventi nella VM, l'evento viene registrato.
Per visualizzare i log della tua VM:
Nella console Google Cloud , vai alla pagina Logging.
Scegli il periodo di tempo in cui si è verificata la latenza.
Utilizza la seguente query di Logging per determinare se si è verificato un evento VM in prossimità del 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 migrate durante il periodo di tempo pertinente, il problema potrebbe essere l'esaurimento delle risorse. Per controllare, vai a Controlla le statistiche di rete e del sistema operativo per gli scarti di pacchetti dovuti all'esaurimento delle risorse.
Controlla le statistiche di rete e del sistema operativo per gli scarti di pacchetti dovuti all'esaurimento delle risorse
L'esaurimento delle risorse è un termine generico che indica che a una risorsa della VM, ad esempio la larghezza di banda di uscita, viene chiesto di gestire più di quanto possa. L'esaurimento delle risorse può comportare l'eliminazione periodica dei pacchetti, causando latenza o timeout della connessione. Questi timeout potrebbero non essere visibili all'avvio del client o del server, ma potrebbero apparire nel tempo man mano che un sistema esaurisce le risorse.
Di seguito è riportato un elenco di comandi che mostrano i contatori dei pacchetti e le statistiche. Alcuni di questi comandi duplicano i risultati di altri comandi. In questi casi, puoi utilizzare il comando che preferisci. Consulta le note all'interno di ogni sezione per comprendere meglio il risultato previsto dell'esecuzione del comando. Può essere utile eseguire i comandi in momenti diversi per verificare se gli scarti o gli errori si verificano contemporaneamente al problema.
Linux
Utilizza il comando
netstatper visualizzare le statistiche di rete.$ netstat -sTcpExt: 341976 packets pruned from receive queue because of socket buffer overrun 6 ICMP packets dropped because they were out-of-window 45675 TCP sockets finished time wait in fast timer 3380 packets rejected in established connections because of timestamp 50065 delayed acks sent
Il comando netstat restituisce statistiche di rete contenenti valori per i pacchetti eliminati per protocollo. I pacchetti eliminati potrebbero essere il risultato dell'esaurimento delle risorse da parte dell'applicazione o dell'interfaccia di rete. Visualizza il motivo del contatore per indicare perché un contatore è stato incrementato.
Controlla kern.log per i log corrispondenti a
nf_conntrack: table full, dropping packet.Debian:
cat /var/log/kern.log | grep "dropping packet"CentOS:
sudo cat /var/log/dmesg | grep "dropping packet"Questo log indica che la tabella di monitoraggio delle connessioni per la VM ha raggiunto il numero massimo di connessioni che possono essere monitorate. Ulteriori connessioni da e verso questa VM potrebbero scadere. Se conntrack è stato attivato, il numero massimo di connessioni può essere trovato con:
sudo sysctl net.netfilter.nf_conntrack_maxPuoi aumentare il valore per le connessioni monitorate massime modificando sysctl
net.netfilter.nf_conntrack_maxo distribuendo il workload delle VM su più VM per ridurre il carico.
UI di Windows
Perfmon
- Utilizzando il menu di Windows, cerca "perfmon" e apri il programma.
- Nel menu a sinistra, seleziona Prestazioni > Strumenti di monitoraggio > Monitoraggio delle prestazioni.
- Nella visualizzazione principale, fai clic sul segno più verde "+" per aggiungere i contatori delle prestazioni al
grafico di monitoraggio. I seguenti contatori sono di interesse:
- Adattatore di rete
- Lunghezza coda di output
- Pacchetti in uscita eliminati
- Errori in uscita dei pacchetti
- Pacchetti ricevuti eliminati
- Errori di pacchetti ricevuti
- Pacchetti ricevuti sconosciuti
- Interfaccia di rete
- Lunghezza coda di output
- Pacchetti in uscita eliminati
- Errori in uscita dei pacchetti
- Pacchetti ricevuti eliminati
- Errori di pacchetti ricevuti
- Pacchetti ricevuti sconosciuti
- Attività della scheda di interfaccia di rete per processore
- Indicazioni di ricezione di risorse basse al secondo
- Pacchetti ricevuti al secondo con poche risorse
- Processore
- % Interrupt Time
- % tempo con privilegi
- % Processor Time
- % User Time
- Adattatore di rete
Pefmon ti consente di tracciare i contatori precedenti su un grafico delle serie temporali. Può essere utile da guardare quando si verificano test o un server è interessato. I picchi nei contatori correlati alla CPU, come Interrupt Time e Privileged Time, possono indicare problemi di saturazione man mano che la VM raggiunge i limiti di velocità effettiva della CPU. Gli errori e gli scarti di pacchetti possono verificarsi quando la CPU è satura, il che comporta la perdita dei pacchetti prima che vengano elaborati dai socket client o server. Infine, anche la lunghezza della coda di output aumenterà durante la saturazione della CPU man mano che vengono accodati più pacchetti per l'elaborazione.
Windows PowerShell
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
Il comando netstat restituisce statistiche di rete contenenti valori per i pacchetti eliminati per protocollo. I pacchetti eliminati potrebbero essere il risultato dell'esaurimento delle risorse da parte dell'applicazione o dell'interfaccia di rete.
Se noti 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 assistenza utilizzando uno dei metodi descritti in Se i problemi persistono.
Se l'esaurimento delle risorse non sembra essere il problema, la causa potrebbe essere 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 la registrazione dei 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 blocchi di elaborazione causati dall'esaurimento della vCPU. Controlla i log del server e delle applicazioni per individuare indicazioni del comportamento che stai riscontrando.
Ad esempio, un server che registra una latenza maggiore a causa di un sistema upstream, come un database sotto carico, potrebbe mettere in coda una quantità eccessiva di richieste, il che può causare una maggiore memoria utilizzata e tempi di attesa della CPU. Questi fattori potrebbero causare errori di connessione o overflow del buffer del socket.
Le connessioni TCP a volte perdono un pacchetto, ma l'acknowledgement selettivo e la ritrasmissione dei pacchetti di solito recuperano i pacchetti persi, evitando il timeout della connessione. Considera invece che i timeout potrebbero essere stati il risultato di un errore o di un nuovo deployment del server delle applicazioni, che ha causato un errore momentaneo per le connessioni.
Se l'applicazione server si basa su una connessione a un database o a un altro servizio, verifica che i servizi accoppiati non funzionino male. La tua applicazione potrebbe monitorare queste metriche.
Se continui a riscontrare problemi
Se i problemi persistono, consulta la sezione Richiedere assistenza per i passaggi successivi. È utile avere l'output dei passaggi per la risoluzione dei problemi da condividere con altri collaboratori.
Passaggi successivi
- Se i problemi persistono, consulta la pagina Risorse.