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 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:
- le connessioni da VM a VM che utilizzano indirizzi IP interni in un rete VPC.
- Connessioni da VM a VM che utilizzano indirizzi IP interni all'interno di una rete VPC condivisa.
- Connessioni da VM a VM che utilizzano indirizzi IP interni in diversi Reti VPC in peering tramite 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 il problema di connessione completa
Le sezioni seguenti forniscono i passaggi per la risoluzione dei problemi interni e un errore di connettività tra le VM. Se invece riscontri aumento della latenza o timeout della connessione intermittente, passa a Risolvi 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, 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 di solito è
443, ma la tua configurazione specifica potrebbe utilizzare un 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.
Esamina i problemi relativi alla rete Google sottostante
Se la configurazione è un uno esistente che non è cambiato di recente, il problema potrebbe riguardare rete Google sottostante. Visita il Network Intelligence Center Dashboard del rendimento della perdita pacchetti tra le zone VM. In caso di 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. in una 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, procedi alla pagina Verifica la presenza di regole firewall di Google Cloud configurate in modo errato.
Verifica la presenza di regole firewall configurate in modo errato in Google Cloud
I test di connettività 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 può anche testare in modo dinamico il percorso inviando e 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 verifica il firewall del sistema operativo o le route del sistema operativo o il software server sulla VM.
La procedura seguente esegue i test di connettività dalla console Google Cloud. Per altri modi di eseguire i test, consulta la sezione Esecuzione di test. Connectivity Tests.
Per creare ed eseguire un test, segui la procedura riportata di seguito:
Nella console Google Cloud, vai alla pagina Connectivity Tests.
Nel menu a discesa del progetto, verifica di essere nel progetto corretto oppure specificare 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 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 è stata interrotta da un Google Cloud
firewall, determina se la configurazione di sicurezza prevista deve consentire
connessione. Potresti dover chiedere al tuo sistema di sicurezza o alla tua rete
amministratore per maggiori dettagli. Se il traffico deve essere consentito, controlla
le seguenti:
- Controlla l'elenco Traffico sempre bloccato. Se il traffico è bloccato da Google Cloud come descritto in l'elenco del traffico sempre bloccato, la configurazione esistente non al lavoro.
- Vai alla pagina Criteri 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 di tipo VPC regola firewall o un criterio firewall gerarchico .
- Se esiste una regola firewall configurata correttamente che blocca questo traffico, rivolgiti all'amministratore di rete o della sicurezza. Se il livello di dei requisiti della tua organizzazione per cui le VM non devono raggiungere potrebbe essere necessario 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: il blocco o la configurazione dell'applicazione per l'ascolto sulla porta errata.
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 VPC, inizia a testare la connettività OS-OS. La i seguenti passaggi consentono di determinare quanto segue:
- Se un server TCP è in ascolto sulla 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 il server
- Se la tabella di route 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
in 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 essere dovuto e l'applicazione stessa. Per verificare, consulta Controllare i log del server per informazioni sul comportamento del server.
- Timeout: se la connessione si interrompe, in genere si verifica uno dei seguenti problemi:
seguenti:
- Non esistono computer a quell'indirizzo IP
- Esiste un firewall da qualche parte in cui i pacchetti vengono scartati automaticamente
- 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 è configurato per rispondere al 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 protocolli di livello superiore (come SSL) non stanno completando l'handshake
- Un firewall sta reimpostando la connessione. È meno probabile che un firewall scarichi silenziosamente i pacchetti, ma può succedere.
Linux
Nella console Google Cloud, vai alla pagina Criteri firewall.
Assicurati che esista una regola firewall che consenta le connessioni SSH da IAP alla VM per crearne uno nuovo.
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 la tua destinazione l'indirizzo IP e la porta.
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 quanto segue:
- Windows 2019:
curl -vso /dev/null --connect-timeout 5 DEST_IP:DEST_PORT
- PowerShell di Windows 2012 o Windows 2016:
PS C:> New-Object System.Net.Sockets.TcpClient('DEST_IP',DEST_PORT)`
- Windows 2019:
Connessione riuscita
I seguenti risultati indicano un handshake TCP riuscito. Se l'handshake TCP viene completato correttamente, il problema non è correlato Timeout o reset della connessione TCP. Il problema di timeout si verifica invece all'interno degli strati dell'applicazione. Se la connessione viene stabilita, vai a Controlla 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 che l'handshake TCP è andato a buon fine.
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 "Connesso: 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 ha superato il tempo di attesa. 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
La reimpostazione si verifica quando un dispositivo invia un pacchetto RST per informare il client 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 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 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 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, accetta connessioni da qualsiasi indirizzo di origine
(0.0.0.0) e 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.
Questa uscita mostra che un server TCP è in ascolto su qualsiasi indirizzo (0.0.0.0) sulla porta 443, accettando connessioni da qualsiasi indirizzo di origine (0.0.0.0) e da qualsiasi porta di origine (0). La colonna OwningProcess indica l'ID processo del processo in ascolto sulla 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
documentazione o del fornitore
per risolvere il problema. Il server deve essere associato all'IP
indirizzo di una particolare interfaccia o a 0.0.0.0 e deve accettare connessioni
dal prefisso IP client corretto o 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 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 sta ascoltando sulla macchina corretta una delle VM potrebbe eseguire un software firewall che sta ignorando i pacchetti associati alla connessione. Controlla il firewall sia sul client usando i comandi seguenti.
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 Console seriale VM l'accesso prima di procedere.
Iptables di Linux
Controlla i conteggi dei pacchetti per il numero di pacchetti elaborati per ogni catena e regola iptables installata. Determina quali regole DROP vengono confrontate con Confrontando indirizzi IP e porte di origine e di destinazione con i prefissi e le porte specificate dalle regole iptables.
Se una regola con corrispondenza mostra un aumento degli scarti con i 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
che utilizza la porta TCP di destinazione 5000 verrà scartato a livello di firewall.
La colonna pkts indica che la regola ha perso 10342 pacchetti. Come
Se crei connessioni ignorate da questa regola, dovrai
l'aumento del contatore pkts, confermando il relativo 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 di ingresso o di 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
In Windows Firewall, verifica che la connessione sia consentita in uscita dal client e in entrata sul server. Se una regola blocca il traffico, apporta le correzioni necessarie nel firewall di Windows per consentire le connessioni. Tu puoi anche abilitare il logging di Windows Firewall.
Il comportamento predefinito di Windows Firewall per i pacchetti con azione DENY è ignorarli silenziosamente, causando timeout.
Questo comando controlla il server. Per controllare le regole in uscita
VM client, cambia 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 o il 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 e la connettività privata. Se non sembrano essere le regole firewall che il problema, procedi con Verifica 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
- Su una VM creata in Google Cloud con una singola interfaccia di rete, i problemi di calcolo itinerario di solito si verificano solo se qualcuno ha modificato manualmente tabella di routing predefinita
- Su una VM di cui è stata eseguita la migrazione da on-premise, la VM potrebbe essere trasferita di routing o di 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
configurato in modo che il traffico destinato alle subnet interne venga inviato a una vNIC
ma 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 i percorsi selezionando i singoli percorsi uno alla volta oppure cercando per l'intera tabella di routing delle VM. Se entrambi gli approcci rivelano problemi con il tabella di routing, consulta i passaggi Aggiornare le tabelle di routing, se necessario per 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 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.
Linux
$ ip route get DEST_IP
Risultato positivo:
Viene mostrato un percorso valido. 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. Conferma che il tuo percorso contiene un percorso all'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 ignorati perché non esiste un percorso per l'indirizzo IP di destinazione. Verifica che disponi di un gateway predefinito e il gateway viene applicato il vNIC e la rete corretti.
Aggiorna tabelle di routing
Se necessario, puoi aggiungere un percorso 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 di comprendere le possibili implicazioni. Uso improprio dei comandi di aggiornamento del percorso potrebbe causare problemi imprevisti o la disconnessione dalla VM. Valuta la possibilità di configurare Console seriale VM l'accesso 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 non sembrano essere il problema, procedi con Controlla la 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 anche MTU corrispondenti. MTU non corrispondenti in genere non sono un problema per TCP, ma possono essere per UDP.
Controlla la MTU del 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.
Linux
$ netstat -i
L'interfaccia lo (loopback) ha sempre un 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 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 le MTU dell'interfaccia e della rete non corrispondono, puoi riconfigurare MTU dell'interfaccia utente. 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 riguardi il server stesso. Per indicazioni sulla risoluzione dei problemi del server, vai a Verifica se nel logging del server sono presenti informazioni sul server comportamento degli utenti.
Controlla il logging del server per informazioni sul comportamento del server
Se i passaggi precedenti non risolvono il problema, è possibile che l'applicazione stia causando i timeout. Controlla nei log del server e delle applicazioni il comportamento che potrebbe spiegare ciò che vedi.
Sorgenti di log da controllare:
- Cloud Logging per la VM
- Log della porta seriale della VM
- syslog e kern.log di Linux o il visualizzatore eventi di Windows
Se i problemi persistono
Se i problemi persistono, consulta la sezione Come ricevere assistenza per i passaggi successivi. È utile avere l'output dei passaggi di risoluzione dei problemi precedenti disponibile per la condivisione 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 generalmente causati dall'esaurimento delle risorse o colli di bottiglia all'interno di un percorso VM o 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 seguenti istruzioni presuppongono che le connessioni non avvengano in modo coerente e si verificano invece 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 latenze che variano 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 che comunicano
- Dalla configurazione del software del server di destinazione, raccogli le informazioni
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.
Esamina i problemi relativi alla rete Google sottostante
Se la tua configurazione è esistente e non è cambiata di recente, il problema potrebbe riguardare la rete di Google sottostante. Visita il Network Intelligence Center Dashboard del rendimento della perdita pacchetti tra le zone VM. In caso di 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 in una rete virtuale. Controlla il 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 a Verificare la latenza dell'handshake.
Controlla la latenza dell'handshake
Tutti i protocolli basati sulla connessione subiscono una certa latenza mentre svolgono handshake per la configurazione della connessione. Ogni handshake del protocollo aumenta il sovraccarico. Ad esempio, per le connessioni SSL/TLS, 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 è solitamente trascurabile, ma gli handshake a località lontane in tutto il mondo potrebbero causare ritardi maggiori avvio della connessione. Se hai risorse in regioni distanti, puoi controllare se la latenza che stai riscontrando è 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 dal momento in cui il client invia il pacchetto SYN iniziale a quando invia l'ACK dell'handshake TCP.
- application_handshake è il tempo che intercorre tra il primo pacchetto SYN del 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 un riferimento, se consentito le regole firewall.
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 in uscita, valuta 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 in uscita sufficiente, esamina se l'utilizzo del disco permanente interferisce con l'uscita della rete. Le operazioni dei dischi permanenti possono occupare fino al 60% del throughput di rete totale della VM. Per determinare se le operazioni dei dischi permanenti potrebbero interferire con il throughput della rete, consulta Verificare il rendimento dei dischi permanenti.
Il traffico in entrata di rete verso una VM non è limitato dalla rete VPC o il 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
La MTU di una rete VPC è configurabile. La MTU dell'interfaccia sulla VM deve corrispondere al valore della MTU sulla rete VPC alla quale è collegato. In un caso di peering di rete VPC, le VM in reti diverse possono avere MTU diversi. Quando questo scenario applica il valore MTU più basso alle interfacce associate. In genere, le mancata corrispondenza dell'MTU non sono un problema per TCP, ma possono esserlo per UDP.
Controlla la MTU del 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.
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 gli MTU di interfaccia e rete non corrispondono, puoi riconfigurare l'MTU di interfaccia. Per istruzioni sull'aggiornamento della MTU per le VM Windows, consulta VM e MTU impostazioni. Se corrispondono, il problema è probabilmente la disponibilità del server. Il passaggio successivo consiste nel controllare i log per verificare se una VM è stata riavviata, interrotta o se è stata eseguita una 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, arrestata o eseguita la migrazione live
Durante il ciclo di vita di una VM, è possibile riavviarla dall'utente, eseguirne la migrazione live manutenzione di Google Cloud o, in rari casi, potrebbe andare persa una VM viene ricreato se si verifica un errore all'interno dell'host fisico contenente la VM. Questi eventi potrebbero causare un breve aumento della latenza o dei timeout di connessione. Se accade uno di questi eventi alla VM, l'evento viene registrato.
Per visualizzare i log per la tua VM, segui questi passaggi:
Nella console Google Cloud, vai alla pagina Logging.
Scegli il periodo di tempo in cui si è verificata la latenza.
Usa la seguente query di Logging per determinare se si è verificato un evento VM nelle vicinanze l'intervallo 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 vengono riavviate o non migrate nel periodo pertinente, il problema potrebbe essere con l'esaurimento delle risorse. Per verificare, vai a Controlla le statistiche di rete e del sistema operativo per gli scarti 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 generico che indica che alcune risorse Alla VM, come la larghezza di banda in uscita, viene chiesto di gestire più di quanto possa. L'esaurimento delle risorse può causare lo scarto periodico dei pacchetti, causando latenza o timeout della connessione. Questi timeout potrebbero non essere visibili ma potrebbe apparire nel tempo quando un sistema esaurisce le risorse.
Di seguito è riportato un elenco di comandi che visualizzano i contatori dei pacchetti e statistiche. 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.
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 genera 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 motivo del contatore per l'indicazione del motivo per cui un contatore è stato incrementato.
Controlla il file kern.log per verificare la presenza di 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 del monitoraggio delle connessioni La VM ha raggiunto il numero massimo di connessioni tracciabili. Ulteriore le connessioni da e verso questa VM potrebbero scadere. Se la connessione è stata attiva, il numero massimo di connessioni è indicato con:
sudo sysctl net.netfilter.nf_conntrack_maxPuoi aumentare il valore del numero massimo di connessioni monitorate di modificando sysctl
net.netfilter.nf_conntrack_maxo diffondendo un carico di lavoro delle VM su più VM per ridurre il carico.
Interfaccia utente di Windows
Perfmon
- Utilizzando il menu di Windows, cerca "perfmon" e apri il programma.
- Nel menu a sinistra, seleziona Prestazioni > Strumenti di monitoraggio > Monitoraggio prestazioni.
- Nella visualizzazione principale, fai clic sul segno Più 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 ignorati
- Errori relativi ai pacchetti in uscita
- Pacchetti ricevuti ignorati
- Errori relativi ai pacchetti ricevuti
- Pacchetti ricevuti sconosciuti
- Interfaccia di rete
- Lunghezza coda di output
- Pacchetti in uscita ignorati
- Errori relativi ai pacchetti in uscita
- Pacchetti ricevuti ignorati
- Errori relativi ai pacchetti ricevuti
- Pacchetti ricevuti sconosciuti
- Attività della scheda di interfaccia di rete per processore
- Indicazioni di ricezione di risorse ridotte al secondo
- Pacchetti ricevuti al secondo con risorse ridotte
- Processore
- % Tempo di interruzione
- % di ora con privilegi
- % tempo di utilizzo della CPU
- % tempo utente
- Adattatore di rete
Pefmon consente di tracciare i contatori precedenti su un grafico delle serie temporali. Può essere utile guardarlo quando vengono eseguiti i test o quando un server è interessato. Picchi nei contatori relativi alla CPU, come il tempo di interruzione e Tempo con privilegi possono indicare problemi di saturazione quando la VM raggiunge la CPU e la velocità effettiva massima. Gli errori e gli annullamenti dei pacchetti possono verificarsi quando la CPU saturare, il che forza la perdita dei pacchetti prima di essere elaborati o socket server. Infine, aumenteranno anche la lunghezza della coda di output durante la saturazione della CPU, perché più pacchetti sono 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 le statistiche di rete contenenti valori per e ignorarli per protocollo. I pacchetti eliminati potrebbero essere il risultato di dell'esaurimento delle risorse da parte dell'applicazione o dell'interfaccia di rete.
Se si verifica l'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 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 il logging 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.
Le connessioni TCP a volte perdono un pacchetto, ma quando la conferma e la ritrasmissione di solito consentono di recuperare i pacchetti persi, evitando il timeout della connessione. Considera invece che i timeout potrebbero essere stati causa di un errore o di un nuovo deployment del server delle applicazioni, causando un errore temporaneo delle connessioni.
Se la tua applicazione server si basa su una connessione a un database o a un altro servizio, conferma che i servizi accoppiati non abbiano prestazioni scadenti. La tua applicazione potrebbe monitorare queste metriche.
Se i problemi persistono
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 il problema persiste, consulta la Risorse.