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 tra due reti VPC connesse con peering di rete VPC. Presuppone 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 che ai nodi di Google Kubernetes Engine.
Se vuoi vedere altri scenari specifici di risoluzione dei problemi, fai clic sul link Invia feedback nella parte inferiore della 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 in una rete VPC condiviso.
- Connessioni da VM a VM che utilizzano indirizzi IP interni in reti VPC diverse con 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 che si sia verificata una perdita di pacchetti completa, vai a Risolvere l'errore di connessione completo.
- Se riscontri latenza, solo una perdita di pacchetti parziale o timeout che si verificano durante la connessione, vai a Risolvere i problemi di latenza o perdita di rete che causano problemi di velocità effettiva.
Risolvere un errore di connessione completo
Le sezioni seguenti forniscono i passaggi per risolvere i problemi di errore di connettività interna completa tra le VM. Se riscontri invece un aumento della latenza o dei timeout delle connessioni intermittenti, vai alla sezione Risolvere i problemi di latenza o perdita di rete che causano problemi di velocità effettiva.
Determinare i valori di connessione
Innanzitutto raccogli le seguenti informazioni:
- Dalla pagina Istanze VM, raccogli quanto segue per entrambe le VM:
- Nomi VM
- Zone VM
- Indirizzi IP interni per le 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 quei valori. In generale, la porta di origine della connessione non è necessaria.
Una volta raccolte queste informazioni, vai alla pagina Esaminare i problemi relativi alla rete Google sottostante.
Esamina i problemi relativi alla rete Google di base
Se la tua configurazione è esistente e non è cambiata di recente, il problema potrebbe riguardare la rete Google sottostante. Controlla la Dashboard delle prestazioni di Network Intelligence Center per verificare la perdita di pacchetti tra le zone VM. 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 alla rete virtuale. Controlla la Dashboard dello stato di Google Cloud per conoscere i problemi noti prima di inviare una richiesta di assistenza.
Se il problema non sembra riguardare la rete Google sottostante, consulta la pagina Controllare 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 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 in uscita o in entrata di Google Cloud blocca il traffico o se una route non è disponibile.
Connectivity Tests può anche testare il percorso in modo dinamico inviando pacchetti tra gli hypervisor delle VM. Se vengono eseguiti questi test, vengono visualizzati i relativi risultati.
Connectivity Tests esamina solo la configurazione della rete VPC. Non verifica il firewall o le route del sistema operativo né il software del server sulla VM.
La seguente procedura esegue Connectivity Tests dalla console Google Cloud. Per informazioni su altri modi di eseguire i test, consulta Esecuzione di test di connettività.
Per creare ed eseguire un test, usa la procedura seguente:
Nella console Google Cloud, vai alla pagina Test di connettività.
Nel menu a discesa del progetto, conferma di essere 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 endpoint di origine
- Progetto di origine e rete VPC
- Indirizzo IP dell'endpoint di destinazione
- Progetto di destinazione e rete VPC
- 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 di Google Cloud, determina se la configurazione di sicurezza prevista deve consentire la connessione. Potresti dover chiedere dettagli all'amministratore
della sicurezza o della rete. Se il traffico deve essere consentito, verifica quanto segue:
- Seleziona l'elenco Traffico sempre bloccato. Se il traffico è bloccato da Google Cloud come descritto nell'elenco del traffico sempre bloccato, la configurazione esistente non funzionerà.
- Vai alla pagina Criteri firewall e rivedi le regole firewall. Se il firewall non è configurato correttamente, crea o modifica una regola firewall per consentire la connessione. Questa regola può essere una regola firewall VPC o una regola dei criteri firewall gerarchici.
- Se esiste una regola firewall configurata correttamente che blocca questo traffico, contatta l'amministratore della sicurezza o di rete. Se i requisiti di sicurezza della tua organizzazione impediscono di connettersi tra le VM, potrebbe essere necessario 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 viene bloccata o configurata per l'ascolto sulla porta sbagliata.
I passaggi successivi illustrano ciascuna di queste possibilità. Continua con Verificare 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 passaggi seguenti ti aiutano a determinare quanto segue:
- Se un server TCP è in ascolto alla porta indicata
- Se il software firewall lato server consente le connessioni a quella porta dalla VM client
- Se il software firewall lato client consente le connessioni a quella porta sul server
- Se la tabella delle route lato server è configurata correttamente per l'inoltro dei pacchetti
- Se la tabella delle route lato client è configurata correttamente per l'inoltro dei 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 comportare uno dei seguenti risultati: connessione riuscita, timeout della connessione o reimpostazione della connessione.
- Operazione riuscita: se l'handshake TCP viene completato correttamente, una regola firewall del sistema operativo non 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 il logging del server per informazioni sul comportamento del server.
- Timeout: in caso di timeout della connessione, in genere si verifica una delle seguenti condizioni:
- Non esistono macchine a quell'indirizzo IP
- Da qualche parte c'è un firewall in cui i pacchetti vengono scartati silenziosamente
- 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 reimpostata, significa che l'IP di destinazione riceve i pacchetti, ma un sistema operativo o un'applicazione li rifiuta. Ciò può indicare una delle seguenti condizioni:
- I pacchetti arrivano sulla macchina sbagliata e non è configurato per rispondere a quel protocollo su quella porta
- I pacchetti arrivano al computer corretto, ma nessun server sta ascoltando su quella porta
- I pacchetti arrivano alla porta e alla macchina corrette, ma i protocolli di livello superiore (come SSL) non completano l'handshake
- Un firewall sta reimpostando la connessione. È meno probabile che un firewall elimini automaticamente i pacchetti, ma può succedere.
Linux
Nella console Google Cloud, vai alla pagina Criteri firewall.
Assicurati che esista una regola firewall che consente le connessioni SSH da IAP alla tua VM oppure 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 del computer 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 tua VM.
Dalla riga di comando del computer 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 risultati seguenti indicano un handshake TCP riuscito. Se l'handshake TCP viene completato correttamente, il problema non è correlato al timeout o alla reimpostazione della connessione TCP. ma il problema di timeout si verifica all'interno dei livelli dell'applicazione. Se la connessione viene stabilita, consulta l'articolo Controllare il logging 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 un 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 riuscito. La riga "Collegato: 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 della connessione
I seguenti risultati indicano che la connessione è scaduta. Se la connessione si verifica in timeout, vai alla sezione 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 avviene quando un dispositivo invia un pacchetto RST al client, per informare il client che la connessione è stata terminata. La connessione potrebbe essere reimpostata per uno dei seguenti motivi:
- Il server ricevente non è stato configurato per accettare connessioni per quel protocollo su quella porta. Il motivo potrebbe essere che il pacchetto è stato inviato al server sbagliato, alla porta errata o che il software del server non è stato configurato correttamente.
- Il software firewall ha rifiutato il tentativo di connessione
Se la connessione è stata reimpostata, vai alla sezione 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 della reimpostazione 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 della reimpostazione 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"
Verifica porta e indirizzo IP del server
Esegui uno dei seguenti comandi sul tuo server. Indicano se c'è 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 da qualsiasi porta di origine (*). La colonna PID/Nome programma 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 dell'esecuzione del comando 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 e accetta connessioni da qualsiasi indirizzo di origine (0.0.0.0) e porta di origine (0). La colonna OwningProcess indica l'ID di processo del processo di 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 corretto oppure 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 una determinata interfaccia 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 alla porta e all'indirizzo IP corretti, è possibile che il client acceda alla porta errata, che un protocollo di livello superiore (spesso TLS) stia rifiutando attivamente la connessione o che esista un firewall che rifiuta la connessione.
Verifica che il client e il server utilizzino la stessa versione TLS e la stessa struttura di crittografia.
Verifica che il client stia accedendo alla porta corretta.
Se i passaggi precedenti non risolvono il problema, consulta la sezione Verificare l'eventuale presenza di rifiuti di pacchetti nel firewall sul client e sul server.
Verifica la presenza di rifiuti di pacchetti nel firewall sul client e sul server
Se il server non è raggiungibile dalla VM client, ma è in ascolto sulla porta corretta, una delle VM potrebbe eseguire un software firewall che ignora i pacchetti associati alla connessione. Controlla il firewall sulle VM client e 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 mentre prepari ed esegui i comandi, poiché un firewall configurato in modo errato può bloccare il traffico imprevisto. Valuta la possibilità di configurare l'accesso alla console seriale VM prima di procedere.
IPtable Linux
Controlla nel conteggio dei pacchetti il numero di pacchetti elaborati per ogni regola e catena di IPtable installati. Determina a quali regole DROP viene abbinata la corrispondenza confrontando gli indirizzi IP di origine e di destinazione e le porte con i prefissi e le porte specificati dalle regole iptables.
Se per una regola con corrispondenza viene mostrato un aumento degli abbandoni con timeout della connessione, consulta la documentazione di iptables per applicare la regola allow corretta alle connessioni appropriate.
$ sudo iptables -L -n -v -x
Questa catena di 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 10.342 pacchetti. Come
test, se crei connessioni che vengono eliminate da questa regola, vedrai l'aumento del contatore pkts, confermando il 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 Windows
Verifica in Windows Firewall che la connessione in uscita sia autorizzata 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 il logging di Windows Firewall.
Il comportamento predefinito di DENY di Windows Firewall prevede l'eliminazione automatica dei pacchetti negati, causando timeout.
Questo comando verifica il server. Per controllare le regole in uscita sulla VM client, modifica il valore -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 nuove regole 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 firewall applicazioni o software antivirus di terze parti possono interrompere o rifiutare le connessioni. Consulta la documentazione fornita dal fornitore.
Se riscontri un problema con le regole firewall e lo correggi, ripeti il test della connettività. Se le regole firewall non sembrano essere il problema, vai a Controlla la configurazione del routing del sistema operativo.
Controlla la configurazione del routing del sistema operativo
I problemi di routing del sistema operativo possono verificarsi in una delle seguenti situazioni:
- I problemi di routing sono più comuni sulle VM con più interfacce di rete, per via dell'ulteriore complessità
- Su una VM creata in Google Cloud con una singola interfaccia di rete, in genere i problemi di routing si verificano solo se qualcuno ha modificato manualmente la tabella di routing predefinita
- Su una VM di cui è stata eseguita la migrazione da on-premise, potrebbe trasferire 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 il traffico in uscita verso la subnet 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 un vNIC, mentre il gateway predefinito (destinazione 0.0.0.0/0) è configurato su un altro vNIC che ha un indirizzo IP esterno o accesso a Cloud NAT.
Puoi rivedere le route controllando le singole route una alla volta o l'intera tabella di routing delle VM. Se uno dei due approcci rileva problemi con la tabella di routing, consulta i passaggi descritti in Aggiornare le tabelle di routing, se necessario, per ricevere istruzioni.
Rivedi tutti i percorsi
Elenca tutte le route per capire quali sono già presenti sulla 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 percorsi
Se il problema sembra essere un determinato prefisso IP, verifica che esistano route corrette per gli IP di origine e di destinazione all'interno delle VM client e server.
Linux
$ ip route get DEST_IP
Risultato positivo:
Viene visualizzata una route valida. In questo caso, i pacchetti in uscita 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 ignorati perché non esiste un percorso per la rete di destinazione. Verifica che la tabella di route contenga un percorso per l'interfaccia in 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 per l'indirizzo IP di destinazione. Verifica di disporre di un gateway predefinito e che quest'ultimo sia applicato alla rete e alla vNIC corrette.
Aggiorna tabelle di routing
Se necessario, puoi aggiungere una route alla tabella delle route del tuo sistema operativo. Prima di eseguire un comando per aggiornare la tabella di routing della VM di routing, ti consigliamo di acquisire familiarità con i comandi e comprendere le possibili implicazioni. L'uso improprio dei comandi di aggiornamento delle route potrebbe causare problemi imprevisti o disconnessioni dalla VM. Valuta la possibilità di configurare l'accesso alla console seriale VM prima di procedere.
Consulta la documentazione del sistema operativo per istruzioni sull'aggiornamento dei percorsi.
Se rilevi un problema con i percorsi e lo correggi, ripeti il test della connettività. Se le route non sembrano essere il problema, vai alla sezione Controllare la MTU dell'interfaccia.
Controlla MTU
La MTU dell'interfaccia di una VM deve corrispondere alla MTU della rete VPC a cui è collegata. Idealmente, anche le VM che comunicano tra loro hanno MTU corrispondenti. La mancata corrispondenza di MTU non rappresenta un problema per TCP, ma può esserlo per UDP.
Controlla la MTU del VPC. Se le VM si trovano in due reti diverse, controlla entrambe.
gcloud compute networks describe NET_NAME --format="table(name,mtu)"
Verifica la configurazione della MTU per le interfacce di rete client e 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 un 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 gli MTU dell'interfaccia e della rete non corrispondono, puoi riconfigurare la MTU dell'interfaccia. Per maggiori informazioni, consulta Impostazioni di VM e MTU. Se corrispondono e se hai seguito i passaggi per la risoluzione dei problemi, è probabile che il problema riguardi il server stesso. Per indicazioni sulla risoluzione dei problemi del server, consulta Controllare il logging del server per informazioni sul comportamento del server.
Controlla il logging del server per informazioni sul comportamento del server
Se i passaggi precedenti non risolvono il problema, i timeout potrebbero essere causati dall'applicazione. Controlla i log del server e delle applicazioni per verificare che non ci siano comportamenti che possano spiegare ciò che stai visualizzando.
Sorgenti log da verificare:
- Cloud Logging per la VM
- Log seriali delle VM
- syslog e kern.log Linux o Visualizzatore eventi di Windows
Se i problemi persistono
Se i problemi persistono, vedi Ricevere assistenza per i passaggi successivi. È utile rendere disponibile 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 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 vNIC comportano un aumento della latenza e una perdita di pacchetti, con una conseguente riduzione delle prestazioni di rete.
Le istruzioni seguenti presuppongono che il timeout delle connessioni non sia costante e che tu stia invece riscontrando problemi di capacità o prestazioni limitate. Se viene visualizzata la perdita di pacchetti completa, consulta Risolvere i problemi di connessione completa.
Sono normali le piccole variazioni di latenza, come le latenze di alcuni millisecondi. Le latenze variano a causa del carico di rete o delle code all'interno della VM.
Determinare i valori di connessione
Innanzitutto raccogli le seguenti informazioni:
- Dalla pagina Istanze VM, raccogli quanto segue per entrambe le VM:
- Nomi VM
- Zone VM
- Indirizzi IP interni per le 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 quei valori. In generale, la porta di origine della connessione non è necessaria.
Una volta raccolte queste informazioni, vai alla pagina Esaminare i problemi relativi alla rete Google sottostante.
Esamina i problemi relativi alla rete Google di base
Se la tua configurazione è esistente e non è cambiata di recente, il problema potrebbe riguardare la rete Google sottostante. Controlla la Dashboard delle prestazioni di Network Intelligence Center per verificare la perdita di pacchetti tra le zone VM. 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 la rete virtuale. Controlla la Dashboard dello stato di Google Cloud per conoscere i problemi noti prima di inviare una richiesta di assistenza.
Se il problema non sembra riguardare la rete Google sottostante, vai alla sezione Controllare la latenza di handshake.
Controlla la latenza di handshake
Tutti i protocolli basati sulla connessione presentano una certa latenza mentre eseguono l'handshake di configurazione della connessione. Ogni handshake di protocollo si aggiunge all'overhead. Per le connessioni SSL/TLS, ad esempio, l'handshake TCP deve essere completato prima che possa iniziare l'handshake SSL/TLS, poi l'handshake TLS deve essere completato prima che i dati possano essere trasmessi.
La latenza di handshake nella stessa zona Google Cloud è generalmente trascurabile, ma gli handshake a località distanti globale potrebbero aggiungere ritardi maggiori all'avvio della connessione. Se disponi di risorse in regioni lontane, puoi verificare se la latenza visualizzata è 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 indica la durata tra l'invio del pacchetto SYN iniziale e l'invio dell'ACK dell'handshake TCP.
- application_handshake è il tempo che intercorre tra il primo pacchetto SYN dell'handshake TCP e il completamento dell'handshake TLS (in genere).
- tempo di handshake aggiuntivo = application_handshake - tcp_handshake
Windows 2012 e 2016
Non disponibile con gli strumenti predefiniti del sistema operativo. Il tempo di round trip ICMP può essere usato come riferimento, se le regole firewall lo consentono.
Se la latenza è superiore a quella che potrebbe essere presa dagli handshake, vai a Determinare la velocità effettiva massima del tuo tipo di VM.
Determina la velocità effettiva massima del tuo tipo di VM.
La velocità effettiva della rete in uscita delle VM è limitata dall'architettura della CPU delle VM e dal conteggio delle vCPU. Per determinare la potenziale larghezza di banda in uscita della VM, consulta la pagina Larghezza di banda di rete.
Se la tua VM non è in grado di soddisfare i requisiti di traffico in uscita, valuta la possibilità di eseguire l'upgrade a una VM con maggiore capacità. Per le istruzioni, consulta Modifica del tipo di macchina di un'istanza.
Se il tipo di macchina deve consentire una larghezza di banda in uscita sufficiente, verifica se l'utilizzo Persistent Disk interferisce con il traffico in uscita dalla rete. Le operazioni del Persistent Disk possono occupare fino al 60% della velocità effettiva di rete totale della tua VM. Per determinare se le operazioni Persistent Disk potrebbero interferire con la velocità effettiva di rete, consulta Verificare le prestazioni del disco permanente.
Il ingresso di rete in una VM non è limitato dalla rete VPC o dal tipo di istanza VM. Viene invece determinato dalle prestazioni di coda dei pacchetti e elaborazione del sistema operativo VM o dell'applicazione. Se la larghezza di banda in uscita è adeguata, ma riscontri problemi di traffico, consulta Controllare il logging del server per informazioni sul comportamento del server.
Controlla MTU dell'interfaccia
La MTU di una rete VPC è configurabile. La MTU dell'interfaccia sulla 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 inferiore alle interfacce associate. Le mancate corrispondenze di MTU di solito non sono un problema per TCP, ma possono esserlo per UDP.
Controlla la MTU del VPC. Se le VM si trovano in due reti diverse, controlla entrambe.
gcloud compute networks describe NET_NAME --format="table(name,mtu)"
Controlla la configurazione MTU della tua interfaccia di rete.
Linux
L'interfaccia lo (loopback) ha sempre una 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 un 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 gli MTU dell'interfaccia e della rete non corrispondono, puoi riconfigurare la MTU dell'interfaccia. Per istruzioni sull'aggiornamento della MTU per le VM Windows, consulta Impostazioni per VM e MTU. Se corrispondono, il problema probabilmente potrebbe essere la disponibilità del server. Il passaggio successivo consiste nel controllare i log per verificare se una VM è stata riavviata, arrestata o migrata in tempo reale per verificare se è successo qualcosa alla VM nell'orario pertinente.
Controlla i log per verificare se una VM è stata riavviata, arrestata o migrata in tempo reale
Durante il ciclo di vita di una VM, una VM può essere riavviata dall'utente, sottoposta a migrazione live per la manutenzione di Google Cloud o, in rare circostanze, una VM potrebbe andare persa e ricreata in caso di errore all'interno dell'host fisico contenente la tua VM. Questi eventi potrebbero causare un breve aumento della latenza o dei timeout della connessione. Se accade una di queste cose alla VM, l'evento viene registrato.
Per visualizzare i log della 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 un evento VM si è verificato vicino al 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 l'orario pertinente, il problema potrebbe essere dovuto all'esaurimento delle risorse. Per verificare, consulta l'articolo Controllare le statistiche di rete e del sistema operativo per l'eliminazione di pacchetti a causa dell'esaurimento di risorse.
Controlla le statistiche di rete e del sistema operativo per verificare la presenza di rifiuti di pacchetti dovuti a esaurimento di risorse
Esaurimento di risorse è un termine generale che indica che ad alcune risorse sulla VM, come la larghezza di banda in uscita, viene richiesto di gestirne più di quanto può essere in grado di gestire. L'esaurimento delle risorse può comportare l'eliminazione periodica di pacchetti, causando una latenza o un timeout della connessione. Questi timeout potrebbero non essere visibili all'avvio del client o del server, ma nel tempo potrebbero apparire quando il sistema esaurisce le risorse.
Di seguito è riportato un elenco di comandi che visualizzano le statistiche e i contatori 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 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 vedere se eliminazioni o 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 scartati in base al protocollo. I pacchetti eliminati potrebbero essere il risultato dell'esaurimento di risorse da parte dell'applicazione o dell'interfaccia di rete. Visualizza il motivo del contatore per indicare il motivo per cui un contatore è stato incrementato.
Cerca su kern.log 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 tracciabili. Ulteriori connessioni da e verso questa VM potrebbero scadere. Se conntrack è stato abilitato, il numero massimo di connessioni è disponibile con:
sudo sysctl net.netfilter.nf_conntrack_maxPuoi aumentare il valore del numero massimo di connessioni monitorate modificando il comando sysctl
net.netfilter.nf_conntrack_maxo distribuendo un carico di lavoro VM su più VM per ridurre il carico.
UI Windows
Perfmon
- Nel menu Windows, cerca "perfmon" e apri il programma.
- Nel menu a sinistra, seleziona Performance > Monitoring Tools > Performance Monitor.
- Nella visualizzazione principale, fai clic sul segno "+" verde per aggiungere contatori delle prestazioni al grafico di monitoraggio. I seguenti contatori sono interessanti:
- Adattatore di rete
- Lunghezza coda di output
- Pacchetti in uscita eliminati
- Errori in uscita dei pacchetti
- Pacchetti ricevuti eliminati
- Errori relativi ai 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 relativi ai pacchetti ricevuti
- Pacchetti ricevuti sconosciuti
- Attività della scheda di interfaccia di rete per processore
- Indicazioni di ricezione risorse basse/sec
- Pacchetti ricevuti/sec in esaurimento risorse
- Processore
- % tempo di interruzione
- % tempo privilegiato
- % tempo di elaborazione
- % tempo utente
- Adattatore di rete
Pefmon ti consente di tracciare i contatori sopra in un grafico delle serie temporali. Questo può essere utile da guardare quando i test sono in corso o quando un server è attualmente interessato. I picchi nei contatori relativi alla CPU, come il tempo di interruzione e il tempo con privilegi, possono indicare problemi di saturazione quando la VM raggiunge i limiti di velocità effettiva della CPU. Quando la CPU è satura, gli errori e gli scarti di pacchetti possono verificarsi quando la CPU è satura, forzando la perdita dei pacchetti prima di essere elaborati dai socket client o server. Infine, anche la lunghezza della coda di output aumenterà durante la saturazione della CPU man mano che più pacchetti vengono messi in coda 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 scartati in base al protocollo. I pacchetti eliminati potrebbero essere il risultato dell'esaurimento di risorse da parte dell'applicazione o dell'interfaccia di rete.
Se riscontri un esaurimento di risorse, puoi provare a distribuire il tuo carico di lavoro tra 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 oppure chiedere aiuto utilizzando uno dei metodi descritti nella sezione Se i problemi persistono.
Se il problema non sembra essere l'esaurimento delle risorse, questo potrebbe riguardare il software del server. Per indicazioni sulla risoluzione dei problemi del software server, consulta Controllare il logging del server per informazioni sul comportamento del server.
Controlla il logging del server per informazioni sul comportamento del server
Se i passaggi precedenti non rivelano alcun problema, i timeout potrebbero essere causati dal comportamento dell'applicazione, ad esempio dal blocco dell'elaborazione dovuto all'esaurimento di vCPU. Controllare i log del server e delle applicazioni per indicazioni sul comportamento che stai riscontrando.
Ad esempio, un server che subisce un aumento della latenza a causa di un sistema upstream, come un database sotto carico, potrebbe mettere in coda una quantità eccessiva di richieste, con un conseguente aumento dell'utilizzo della memoria e dei tempi di attesa della CPU. Questi fattori potrebbero causare connessioni non riuscite o superamento del buffer del socket.
A volte le connessioni TCP perdono un pacchetto, ma il riconoscimento selettivo e la ritrasmissione dei pacchetti solitamente recuperano quelli persi, evitando il timeout della connessione. Considera invece che i timeout potrebbero essere il risultato di un errore del server delle applicazioni o del nuovo deployment, causando un errore temporaneo delle connessioni.
Se la tua applicazione server si basa su una connessione a un database o a un altro servizio, verifica che i servizi accoppiati non abbiano prestazioni scadenti. La tua applicazione potrebbe monitorare queste metriche.
Se i problemi persistono
Se i problemi persistono, vedi Ricevere assistenza per i passaggi successivi. È utile rendere disponibile l'output dei passaggi per la risoluzione dei problemi da condividere con altri collaboratori.
Passaggi successivi
- Se i problemi persistono, consulta la pagina Risorse.