Memecahkan masalah konektivitas internal antar VM
Dokumen ini menyediakan langkah pemecahan masalah untuk masalah konektivitas antara VM Compute Engine pada jaringan Virtual Private Cloud (VPC) yang sama (baik VPC Bersama maupun mandiri) atau dua jaringan VPC yang terhubung dengan Peering Jaringan VPC. Hal ini mengasumsikan bahwa VM berkomunikasi menggunakan alamat IP internal dari pengontrol antarmuka jaringan virtual (vNIC) masing-masing.
Langkah-langkah dalam panduan ini berlaku untuk VM Compute Engine dan node Google Kubernetes Engine.
Jika Anda ingin melihat skenario pemecahan masalah tambahan tertentu, klik link Kirim masukan di bagian bawah halaman ini dan beri tahu kami.
Konfigurasi VPC dan VM berikut dapat diterapkan pada panduan ini:
- Koneksi VM-ke-VM menggunakan alamat IP internal dalam satu jaringan VPC.
- Koneksi VM-ke-VM menggunakan alamat IP internal dalam jaringan VPC Bersama.
- Koneksi VM-ke-VM menggunakan alamat IP internal pada jaringan VPC berbeda yang di-peer dengan Peering Jaringan VPC.
Perintah yang digunakan pada panduan ini tersedia di semua OS image yang disediakan Google. Apabila menggunakan OS image sendiri, Anda mungkin harus meng-install alat tersebut.
Mengukur masalah
- Apabila Anda merasa kehilangan paket lengkap, buka Memecahkan masalah kegagalan koneksi lengkap.
- Apabila mengalami latensi, kehilangan paket sebagian, atau kejadian timeout habis di tengah koneksi, buka Memecahkan masalah latensi jaringan atau kehilangan karena masalah throughput.
Memecahkan masalah koneksi lengkap
Bagian berikut menyediakan langkah untuk memecahkan masalah kegagalan konektivitas internal lengkap antar VM. Apabila mengalami peningkatan latensi atau timeout koneksi terputus-putus, lewati ke Memecahkan masalah kehilangan atau latensi jaringan karena masalah throughput.
Menentukan nilai koneksi
Langkah pertama, kumpulkan informasi berikut:
- Dari halaman instance VM,
kumpulkan beberapa hal berikut untuk kedua VM:
- Nama VM
- Zona VM
- Alamat IP internal untuk vNIC yang sedang berkomunikasi
Dari konfigurasi software server tujuan, kumpulkan informasi berikut:
- Protokol lapisan 4
- Destination port
Sebagai contoh, apabila tujuan Anda adalah server HTTPS, protokol yang dimaksud adalah TCP dan port yang biasa digunakan adalah
443, tetapi konfigurasi tertentu mungkin menggunakan port yang berbeda.
Apabila mengalami masalah dengan berbagai VM, pilih satu sumber dan satu tujuan VM yang bermasalah, kemudian gunakan nilai tersebut. Umumnya, port sumber koneksi tidak diperlukan.
Setelah mendapatkan informasi, lanjutkan ke Menyelidiki masalah pada jaringan Google yang mendasarinya.
Menyelidiki masalah pada jaringan Google yang mendasarinya
Apabila penyiapan tersebut sudah ada dan tidak berubah baru-baru ini, maka masalah tersebut mungkin saja berada di jaringan Google yang mendasarinya. Periksa Dasbor Performa Network Intelligence Center untuk mengetahui kehilangan paket di antara zona VM. Apabila jumlah paket yang hilang meningkat di antara zona selama jangka waktu ketika mengalami timeout jaringan, hal ini mungkin menunjukkan bahwa masalah tersebut berada di jaringan fisik yang mendasari jaringan virtual. Periksa Dasbor Status Google Cloud untuk mengetahui masalah umum sebelum mengajukan kasus dukungan.
Apabila masalah tersebut terlihat tidak terjadi pada jaringan Google yang mendasarinya, lanjutkan ke Memeriksa aturan firewall Google Cloud yang salah dikonfigurasi.
Memeriksa aturan firewall yang salah dikonfigurasi pada Google Cloud
Uji Konektivitas menganalisis konfigurasi jalur jaringan VPC antara dua VM dan menunjukkan apakah konfigurasi yang telah diprogram tersebut harus mengizinkan traffic tersebut atau tidak. Apabila traffic tidak diizinkan, hasil tersebut menunjukkan apakah aturan firewall traffic masuk atau keluar Google Cloud diblokir traffic tersebut atau bisa jadi rute tidak tersedia.
Uji Konektivitas mungkin juga menguji jalur tersebut secara dinamis dengan mengirimkan paket di antara hypervisor. Apabila pengujian tersebut sudah dilakukan, maka hasil pengujian akan ditampilkan.
Uji Konektivitas hanya memeriksa konfigurasi jaringan VPC. Pengujian ini tidak menguji firewall sistem operasi, rute sistem operasi, atau software server pada VM.
Prosedur berikut menjalankan Uji Konektivitas dari konsol Google Cloud. Untuk informasi lebih lanjut terkait cara lain dalam menjalankan pengujian, lihat Menjalankan Uji Konektivitas.
Gunakan prosedur berikut untuk membuat dan menjalankan pengujian:
Pada konsol Google Cloud, buka halaman Uji Konektivitas.
Pada menu pull-down project, pastikan Anda berada di project yang tepat atau tentukan project yang benar.
Klik Buat uji konektivitas.
Beri nama untuk pengujian tersebut.
Tentukan nilai berikut:
- Protocol
- Alamat IP endpoint sumber
- Jaringan VPC dan project sumber
- Alamat IP endpoint tujuan
- Jaringan VPC dan project tujuan
- Destination port
Klik Create.
Pengujian akan segera berjalan. Untuk melihat diagram hasil, klik Lihat pada kolom Hasil detail.
- Apabila hasil tersebut menyatakan bahwa koneksi terputus oleh aturan firewall
Google Cloud, tentukan apakah penyiapan keamanan yang diinginkan harus mengizinkan
koneksi. Anda mungkin harus meminta administrator jaringan atau
keamanan untuk informasi lebih lanjut. Apabila traffic harus diizinkan, periksa
hal berikut:
- Periksa daftar Traffic yang selalu diblokir. Jika traffic diblokir oleh Google Cloud seperti yang sudah dijelaskan dalam daftar traffic yang selalu diblokir, maka konfigurasi yang ada tidak akan bekerja.
- Buka halaman Kebijakan firewall dan tinjau aturan firewall Anda. Apabila firewall salah dikonfigurasi, buat atau ubah aturan firewall untuk mengizinkan koneksi. Aturan ini dapat berupa aturan firewall VPC atau aturan kebijakan firewall hierarki.
- Jika ada aturan firewall yang dikonfigurasi dengan benar yang memblokir traffic ini, periksa dengan administrator jaringan atau keamanan. Jika persyaratan keamanan organisasi berarti VM tidak dapat saling menjangkau satu sama lain, Anda mungkin perlu mendesain ulang penyiapan tersebut.
- Apabila hasil tersebut menunjukkan bahwa tidak ada masalah dengan
jalur konektivitas VPC, mungkin masalahnya adalah salah satu hal
berikut.
- Masalah dengan konfigurasi OS tamu seperti masalah dengan software firewall.
- Masalah dengan aplikasi klien atau server, seperti aplikasi yang dibekukan atau terkonfigurasi untuk memproses port yang salah.
Langkah berikutnya akan memandu untuk memeriksa setiap kemungkinan. Lanjutkan dengan Menguji konektivitas TCP dari dalam VM.
Menguji konektivitas TCP dari dalam VM
Apabila Uji Konektivitas VM-VM tidak mendeteksi masalah konfigurasi VPC, mulailah menguji konektivitas OS-OS. Langkah berikut ini membantu Anda menentukan hal berikut:
- Apabila server TCP memproses port yang ditunjuk
- Apabila software firewall sisi server mengizinkan koneksi ke port tersebut dari VM klien
- Apabila software sisi klien mengizinkan koneksi ke port tersebut di server
- Apabila tabel rute sisi server dikonfigurasi dengan benar untuk meneruskan paket
- Apabila tabel rute sisi klien dikonfigurasi dengan benar untuk meneruskan paket
Anda dapat menguji handshake TCP menggunakancurl dengan Linux atau Windows 2019, atau
menggunakan perintah New-Object System.Net.Sockets.TcpClient dengan Windows
Powershell. Alur kerja di bagian ini akan menghasilkan sasah satu hasil berikut:
koneksi berhasil, timeout koneksi, atau reset koneksi.
- Berhasil: Apabila handshake TCP berhasil diselesaikan, maka aturan firewall OS tidak memblokir koneksi, OS meneruskan paket dengan benar, dan beberapa jenis server melakukan proses pada port tujuan. Jika begitu, masalah tersebut mungkin berasal dari aplikasi itu sendiri. Lihat Memeriksa logging server untuk mengetahui informasi tentang perilaku server untuk memeriksa masalah.
- Timeout: Apabila timeout koneksi habis, seringkali hal ini disebabkan oleh salah satu
hal berikut:
- Tidak ada mesin dengan alamat IP tersebut
- Terdapat firewall di suatu tempat yang diam-diam membuang paket
- Perutean paket OS mengirim paket tersebut ke tujuan yang tidak dapat memprosesnya, atau perutean asimetris mengirim kembali paket tersebut di jalur yang tidak valid
Reset: Apabila koneksi sedang direset, itu berarti IP tujuan sedang menerima paket, tetapi OS atau aplikasi menolaknya. Hal ini dapat berarti salah satu dari kemungkinan berikut:
- Paket tiba pada mesin yang salah dan tidak dikonfigurasi untuk merespon protocol pada port tersebut.
- Paket tersebut tiba pada komputer yang benar, tetapi tidak ada server yang memproses pada port tersebut.
- Paket tersebut tidak pada mesin dan port yang benar, tetapi protokol dengan tingkat lebih tinggi (seperti SSL) tidak menyelesaikan handskake-nya
- Firewall sedang mereset koneksi. Hal ini berisiko lebih kecil dibandingkan firewall yang diam-diam membuang paket, tetapi hal tersebut bisa terjadi.
Linux
Pada konsol Google Cloud, buka halaman Kebijakan Firewall.
Pastikan terdapat aturan firewall yang mengizinkan koneksi SSH dari IAP ke VM atau buat yang baru.
Di Konsol Google Cloud, buka halaman Instance VM.
Temukan VM sumber.
Klik SSH di kolom Hubungkan untuk VM tersebut.
Dari command line mesin klien, jalankan perintah berikut: Ganti DEST_IP:DEST_PORT dengan tujuan port dan alamat IP.
curl -vso /dev/null --connect-timeout 5 DEST_IP:DEST_PORT
Windows
Di Konsol Google Cloud, buka halaman Instance VM.
Temukan VM sumber.
Gunakan salah satu metode yang dijelaskan pada Menghubungkan ke VM Windows untuk terhubung ke VM.
Dari command line mesin klien, jalankan perintah berikut:
- Windows 2019:
curl -vso /dev/null --connect-timeout 5 DEST_IP:DEST_PORT
- Powershell Windows 2012 atau Windows 2016:
PS C:> New-Object System.Net.Sockets.TcpClient('DEST_IP',DEST_PORT)`
- Windows 2019:
Sambungan berhasil
Hasil berikut ini menunjukkan handshake TCP yang berhasil. Apabila handshake berhasil diselesaikan, maka masalah tersebut tidak terkait dengan reset atau timeout koneksi TCP. Sebaliknya masalah timeout terjadi di dalam lapisan aplikasi. Apabila mendapat koneksi yang berhasil, lanjutkan ke Memeriksa logging server untuk mendapat informasi terkait perilaku server.
Linux dan Windows 2019
$ curl -vso /dev/null --connect-timeout 5 192.168.0.4:443
Baris "Terhubung ke" menunjukkan bahwa handshake TCP berhasil.
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 dan 2016
PS C:\> New-Object System.Net.Sockets.TcpClient('DEST_IP_ADDRESS', PORT)
Hasil koneksi berhasil. Baris terhubung: "Terhubung: Benar" relevan.
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
Waktu tunggu koneksi habis
Hasil berikut menunjukkan bahwa waktu sambungan habis. Apabila waktu koneksi habis, lanjutkan ke Memverifikasi server port dan alamat IP.
Linux dan Windows 2019
$ curl -vso /dev/null --connect-timeout 5 DEST_IP_ADDRESS:PORT
Hasil waktu tunggu sambungan:
Trying 192.168.0.4:443... Connection timed out after 5000 milliseconds Closing connection 0
Windows 2012 dan 2016
PS C:\> New-Object System.Net.Sockets.TcpClient('DEST_IP_ADDRESS', PORT)
Hasil waktu tunggu sambungan:
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"
Mereset koneksi
Reset adalah ketika device memerlukan paket RST kembali ke klien, yang memberi tahu klien bahwa koneksi telah dihentikan. Koneksi dapat direset karena salah satu alasan berikut:
- Server penerima tidak dikonfigurasi untuk menerima koneksi untuk protokol tersebut pada port tersebut. Hal ini dapat terjadi karena paket tersebut dikirim ke server atau port yang salah, atau software server yang salah dikonfigurasi.
- Perangkat lunak firewall menolak upaya koneksi
Apabila koneksi direset, lanjutkan ke Memverifikasi bahwa Anda mengakses alamat IP dan port yang benar
Linux dan Windows 2019
$ curl -vso /dev/null --connect-timeout 5 DEST_IP_ADDRESS:PORT
Hasil penyetelan ulang sambungan:
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 dan 2016
PS C:\> New-Object System.Net.Sockets.TcpClientt('DEST_IP_ADDRESS', PORT)
Hasil penyetelan ulang sambungan:
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"
Memverifikasi port dan alamat IP server
Jalankan salah satu perintah berikut di server Anda. Tindakan ini menunjukkan apakah ada server yang memproses port yang diperlukan.
Linux
$ sudo netstat -ltuvnp
Output menunjukkan bahwa server TCP memproses setiap tujuan alamat IP
(0.0.0.0) pada port 22, menerima koneksi dari alamat sumber mana pun
(0.0.0.0) dan setiap port sumber (*). Kolom PID/Nama program
menentukan file yang dapat dieksekusi agar terikat ke soket ke soket.
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
Output menunjukkan hasil perintah yang dijalankan dengan DEST_PORT ditetapkan ke 443.
Output ini menunjukkan bahwa server TCP memproses alamat apa saja (0.0.0.0) pada
port 443, menerima koneksi dari tiap alamat sumber (0.0.0.0) dan port sumber
apa pun (0). Kolom OwningProcess menunjukkan bahwa ID proses dari operasi
yang memproses soket.
LocalAddress LocalPort RemoteAddress RemotePort State AppliedSetting OwningProcess ------------ --------- ------------- ---------- ----- -------------- ------------- :: 443 :: 0 Listen 928 0.0.0.0 443 0.0.0.0 0 Listen 928
Apabila menemukan salah satu server tidak terikat ke port atau IP yang benar, atau
awalan jarak jauh tidak cocok dengan klien, lihat vendor
atau dokumentasi server untuk menyelesaikan masalah. Server harus terikat ke alamat
IP antarmuka tertentu atau ke 0.0.0.0, dan harus menerima koneksi
dari awalan IP klien yang benar atau 0.0.0.0.
Apabila server aplikasi terikat ke port dan alamat IP yang benar, klien mungkin saja mengakses port yang salah, protokol dengan tingkat lebih tinggi (sering kali TLS) menolak koneksi secara aktif, atau terdapat firewall yang membatalkan koneksi.
Periksa apakah klien dan server menggunakan versi TLS dan formasi enkripsi yang sama.
Periksa apakah klien mengakses port yang benar.
Jika langkah-langkah sebelumnya tidak menyelesaikan masalah, lanjutkan ke Memeriksa firewall pada klien dan server untuk penghapusan paket.
Memeriksa firewall di klien dan server untuk pembuangan paket
Apabila server tidak dapat dijangkau dari VM klien, tetapi sedang memproses port yang tepat, salah satu VM mungkin menjalankan software firewall yang menghapus paket yang terkait dengan koneksi. Periksa firewall pada VM klien dan server menggunakan perintah berikut.
Apabila ada aturan yang memblokir traffic, Anda dapat memperbarui software firewall untuk mengizinkan traffic. Apabila Anda memperbarui firewall, lanjutkan dengan hati-hati saat menyiapkan dan menjalankan perintah karena firewall yang salah dikonfigurasi dapat memblokir traffic yang tidak terduga. Pertimbangkan untuk menyiapkan akses Konsol Serial VM sebelum melanjutkan.
IPTable Linux
Periksa jumlah paket untuk mengetahui jumlah paket yang diproses untuk setiap aturan dan chain iptable yang telah diinstal. Tentukan aturan DROP yang dicocokkan dengan membandingkan sumber dan tujuan port dan alamat IP dengan awalan dan port yang ditentukan oleh aturan iptable.
Apabila aturan yang cocok menunjukkan peningkatan penghapusan dengan timeout koneksi
lihat dokumentasi iptable untuk menerapkan aturan allow yang benar ke
koneksi yang sesuai.
$ sudo iptables -L -n -v -x
Contoh rantai INPUT ini menunjukkan bahwa paket dari satu alamat IP ke alamat IP lainnya
menggunakan port TCP 5000 yang akan dihapus di firewall.
Kolom pkts menunjukkan bahwa aturan telah menghapus 10342 paket. Apabila
membuat koneksi yang dihapus oleh aturan ini sebagai pengujian, Anda akan
melihat peningkatan penghitung pkts yang mengonfirmasi perilaku tersebut.
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
Anda dapat menambahkan aturan masuk atau keluar untuk iptable dengan perintah berikut:
Aturan masuk:
$ sudo iptables -A INPUT -p tcp -s SOURCE_IP_PREFIX --dport SERVER_PORT -j ACCEPT
Aturan keluar:
$ sudo iptables -A OUTPUT -p tcp -d DEST_IP_PREFIX --dport DEST_PORT -j ACCEPT
Windows Firewall
Periksa di Windows Firewall apakah koneksi diizinkan untuk keluar dari klien dan masuk ke server. Apabila aturan tersebut memblokir traffic, lakukan perbaikan yang diperlukan pada Windows Firewall untuk mengizinkan koneksi. Anda juga dapat mengaktifkan Windows Firewall Logging.
Perilaku default TOLAK dari Windows Firewall menghapus paket yang ditolak diam-diam sehingga terjadi timeout.
Perintah ini akan memeriksa server. Untuk memeriksa aturan keluar pada
VM klien, ubah nilai -match ke 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
Anda dapat menambahkan aturan firewall baru untuk Windows dengan perintah berikut.
Aturan Keluar:
PS C:\> netsh advfirewall firewall add rule name="My Firewall Rule" dir=out action=allow protocol=TCP remoteport=DEST_PORT
Aturan Masuk:
PS C:\> netsh advfirewall firewall add rule name="My Firewall Rule" dir=in action=allow protocol=TCP localport=PORT
Software pihak ketiga
Aplikasi firewall atau software antivirus pihak ketiga juga dapat memutus atau menolak koneksi. Lihat dokumentasi yang disediakan oleh vendor.
Apabila Anda menemukan masalah pada aturan firewall dan memperbaikinya, tes ulang konektivitas tersebut. Jika aturan firewall tidak terlihat seperti masalah yang dimaksud, lanjutkan ke Memeriksa konfigurasi pemilihan rute OS.
Memeriksa konfigurasi perutean OS
Masalah perutean sistem operasi dapat disebabkan oleh salah satu situasi berikut:
- Masalah perutean paling sering terjadi pada VM dengan beberapa antarmuka jaringan karena kompleksitas perutean tambahan.
- Pada VM yang dibuat di Google Cloud dengan satu antarmuka jaringan, masalah perutean biasanya hanya terjadi apabila seseorang telah mengubah tabel perutean default secara manual.
- Pada VM yang telah bermigrasi dari jaringan lokal, VM mungkin diteruskan perutean atau setelan MTU yang diperlukan jaringan lokal tetapi menyebabkan masalah dalam jaringan VPC
Apabila menggunakan VM dengan beberapa antarmuka jaringan, rute harus dikonfigurasi
untuk keluar ke subnet dan vNIC yang benar. Sebagai contoh, VM mungkin memiliki rute
yang dikonfigurasi sehingga traffic yang dimaksudkan agar subnet internal dikirim ke satu vNIC,
tetapi gateway default (0.0.0.0/0 tujuan) dikonfigurasi pada vNIC
lain yang memiliki alamat IP eksternal atau akses Cloud NAT.
Anda dapat meninjau rute dengan memeriksa setiap rute satu per satu atau dengan mencari di semua tabel perutean VM. Jika salah satu pendekatan tersebut mengungkap masalah pada tabel perutean, lihat langkah-langkah pada Memperbarui tabel perutean jika diperlukan untuk menemukan petunjuk.
Meninjau semua rute
Catat semua rute untuk memahami rute apa saja yang sudah ada pada 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
Memeriksa rute masing-masing
Apabila awalan IP tertentu terlihat menunjukkan adanya masalah, periksa apakah ada rute yang tepat untuk sumber dan tujuan IP dalam VM klien dan server.
Linux
$ ip route get DEST_IP
Hasil baik:
Rute yang valid akan ditampilkan. Dalam hal ini, paket keluar dari antarmuka ens4.
10.3.0.34 via 10.3.0.1 dev ens4 src 10.3.0.26 uid 1000 cache
Hasil buruk:
Hasil ini mengonfirmasi bahwa paket dibuang karena tidak ada jalur ke jaringan tujuan. Pastikan tabel rute berisi jalur ke antarmuka keluar yang benar.
**RTNETLINK answers: Network is unreachable
Windows
PS C:\> Find-NetRoute -RemoteIpAddress "DEST_IP"
Hasil baik:
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
Hasil buruk:
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
Perintah ini mengonfirmasi bahwa paket dihapus karena tidak ada jalur ke alamat IP tujuan. Periksa apakah Anda memiliki gateway default yang diterapkan ke jaringan dan vNIC yang benar.
Memperbarui tabel
Anda dapat menambahkan rute ke tabel rute sistem operasi apabila diperlukan. Sebelum menjalankan perintah untuk memperbarui tabel perutean VM, sebaiknya pelajari perintah tersebut dan kembangkan pemahaman terkait implikasi yang mungkin terjadi. Penggunaan perintah pembaruan rute yang tidak tepat mungkin dapat menyebabkan masalah tidak terduga atau terputusnya koneksi ke VM. Pertimbangkan untuk menyiapkan akses Konsol Serial VM sebelum melanjutkan.
Lihat dokumentasi sistem operasi agar menemukan petunjuk untuk memperbarui rute.
Apabila menemukan masalah pada rute dan memperbaikinya, tes ulang konektivitas tersebut. Jika rute tidak terlihat menunjukkan masalah, lanjutkan ke Memeriksa antarmuka MTU.
Memeriksa MTU
Antarmuka MTU VM harus cocok dengan MTU jaringan VPC yang telah terpasang. VM yang berkomunikasi satu sama lain seharusnya juga memiliki MTU yang cocok. MTU yang tidak cocok biasanya bukan masalah untuk TCP, tetapi bisa juga untuk UDP.
Periksa MTU VPC. Apabila VM berada di dua jaringan yang berbeda, periksa kedua jaringan tersebut.
gcloud compute networks describe NET_NAME --format="table(name,mtu)"
Periksa konfigurasi MTU untuk antarmuka jaringan klien dan server.
Linux
$ netstat -i
Antarmuka Io (loopback) selalu memiliki MTU 65536 dan dapat diabaikan untuk langkah ini.
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
Antarmuka Semu untuk Loopback selalu memiliki MTU 4294967295 dan dapat diabaikan untuk langkah ini.
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
Jika MTU antarmuka dan jaringan tidak cocok, Anda dapat mengonfigurasi ulang MTU antarmuka tersebut. Untuk informasi lebih lanjut, lihat Setelan VM dan MTU. Apabila cocok dan Anda telah mengikuti langkah pemecahan masalah sejauh ini, maka masalah tersebut berada di server itu sendiri. Untuk menemukan panduan terkait pemecahan masalah server, lanjutkan ke Memeriksa logging server untuk mendapat informasi terkait perilaku server.
Memeriksa logging server untuk mendapat informasi terkait perilaku server
Jika langkah-langkah sebelumnya tidak menyelesaikan masalah, aplikasi mungkin menyebabkan timeout. Periksa log server dan aplikasi untuk mengetahui perilaku yang dapat menjelaskan apa yang terlihat.
Catat sumber yang digunakan untuk memeriksa:
- Cloud Logging untuk VM
- Log Serial VM
- syslog dan kern.log Linux atau Windows Event Viewer
Apabila Anda masih memiliki masalah
Apabila Anda masih memiliki masalah, lihat Mendapatkan dukungan untuk langkah berikutnya. Sebaiknya Anda memiliki output dari langkah pemecahan masalah sebelumnya yang tersedia untuk dibagikan ke kolaborator lain.
Memecahkan masalah latensi atau kehilangan karena throughput
Masalah latensi atau kehilangan biasanya disebabkan oleh kehabisan resource atau bottlenecks dalam VM atau jalur jaringan. Kehilangan jaringan terkadang dapat menyebabkan timeout koneksi terputus-putus. Penyebab seperti penghabisan vCPU atau satuasi vNIC menghasilkan peningkatan latensi dan kehilangan paket yang mengarah pada penurunan performa jaringan.
Petunjuk berikut mengasumsikan bahwa koneksi tidak secara konsisten mengalami timeout dan justru mengalami masalah kapasitas atau performa yang terbatas. Apabila menemukan paket lengkap yang hilang, lihat Memecahkan masalah kegagalan koneksi lengkap.
Sedikit variasi pada latensi, seperti latensi yang bervariasi dalam beberapa milidetik, adalah hal normal. Latensi bervariasi karena beban jaringan atau antrean di dalam VM.
Menentukan nilai koneksi
Langkah pertama, kumpulkan informasi berikut:
- Dari halaman instance VM,
kumpulkan beberapa hal berikut untuk kedua VM:
- Nama VM
- Zona VM
- Alamat IP internal untuk vNIC yang sedang berkomunikasi
- Dari konfigurasi software server tujuan, kumpulkan
informasi berikut:following information:
- Protokol lapisan 4
- Destination port
Apabila mengalami masalah dengan berbagai VM, pilih satu sumber dan satu tujuan VM yang bermasalah, kemudian gunakan nilai tersebut. Umumnya, port sumber koneksi tidak diperlukan.
Setelah mendapatkan informasi, lanjutkan ke Menyelidiki masalah pada jaringan Google yang mendasarinya.
Menyelidiki masalah pada jaringan Google yang mendasarinya
Apabila penyiapan tersebut sudah ada dan tidak berubah baru-baru ini, maka masalah tersebut mungkin saja berada di jaringan Google yang mendasarinya. Periksa Dasbor Performa Network Intelligence Center untuk mengetahui kehilangan paket di antara zona VM. Apabila terdapat peningkatan kehilangan paket di antara zona selama jangka waktu di mana Anda mengalami timeout jaringan, hal ini mungkin menunjukkan bahwa masalah tersebut berada di jaringan fisik yang mendasari jaringan virtual. Periksa Dasbor Status Google Cloud untuk mengetahui masalah umum sebelum mengajukan kasus dukungan.
Apabila masalah tersebut tidak terlihat di jaringan Google yang mendasarinya, lanjutkan ke Memeriksa latensi handshake.
Memeriksa latensi handshake
Semua protokol berbasis koneksi menimbulkan beberapa latensi ketika melakukan penyiapan koneksi. Setiap handshake protokol akan menambah overhead. Untuk, koneksi SSL/TLS, sebagai contoh, handshake TCP harus selesai sebelum SSL/TLS handshake dapat dimulai, kemudian TLS handshake harus selesai sebelum data dapat dikirim.
Latensi handshake di zona Google Cloud yang sama biasanya dapat diabaikan, tetapi handshake ke lokasi yang jauh secara global mungkin menambah penundaan yang lebih besar pada inisiasi koneksi. Apabila memiliki resource pada region yang jauh, Anda dapat memeriksa apakah latensi yang terlihat disebabkan oleh handshake protokol.
Linux dan 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 adalah durasi dari sejak klien mengirim paket SYN awal hingga ketika klien mengirim ACK handshake TCP.
- application_handshake adalah waktu dari paket SYN pertama handshake TCP hingga penyelesaian handshake TCP (biasanya).
- waktu handshake tambahan = application_handshake - tcp_handshake
Windows 2012 dan 2016
Tidak tersedia dengan fitur OS default Waktu round-trip ICMP dapat digunakan sebagai referensi apabila aturan firewall mengizinkan.
Apabila latensi lebih besar daripada yang bisa dihitung oleh handshake, lanjutkan ke Menentukan throughput maksimum jenis VM.
Menentukan throughput maksimum jenis VM
Throughput keluar jaringan VM dibatasi oleh arsitektur CPU VM dan jumlah vCPU. Tentukan bandwidth keluar potensial dari VM dengan melihat halaman Bandwidth jaringan.
Apabila VM tidak mampu memenuhi persyaratan traffic keluar, pertimbangkan untuk mengupgrade ke VM dengan kapasitas yang lebih besar. Untuk menemukan petunjuk, lihat Mengubah jenis mesin instance.
Apabila jenis mesin harus mengizinkan bandwidth keluar yang memadai, maka selidiki apakah penggunaan Persistent Disk menimbulkan interferensi pada traffic keluar jaringan. Operasi Persistent Disk diizinkan untuk mengisi hingga 60% dari total throughput jaringan VM. Untuk menentukan apabila operasi Persistent Disk mungkin menimbulkan interferensi pada throughput jaringan, lihat Memeriksa performa Persistent Disk.
Jaringan masuk ke VM tidak dibatasi oleh jaringan VPC atau jenis instance VM. Sebaliknya, hal ini ditentukan oleh performa pemrosesan dan antrean paket dari sistem operasi atau aplikasi VM. Apabila bandwidth keluar yang memadai tetapi mengalami masalah traffic masuk, lihat Memeriksa logging server untuk mendapat informasi terkait perilaku server.
Memeriksa antarmuka MTU
MTU jaringan VPC dapat dikonfigurasi MTU antarmuka pada VM harus cocok dengan nilai MTU untuk jaringan VPC yang telah terpasang. Dalam situasi Peering Jaringan VPC VM pada jaringan yang berbeda dapat memiliki MTU yang berbeda juga Ketika skenario ini terjadi, terapkan nilai MTU yang lebih kecil ke antarmuka terkait. Ketidakcocokan MTC biasanya bukan merupakan masalah untuk TCP, tetapi dapat terjadi pada UDP.
Periksa MTU VPC. Apabila VM berada di dua jaringan yang berbeda, periksa kedua jaringan tersebut.
gcloud compute networks describe NET_NAME --format="table(name,mtu)"
Periksa konfigurasi MTU untuk antarmuka jaringan
Linux
Antarmuka Io (loopback) selalu memiliki MTU 65536 dan dapat diabaikan untuk langkah ini.
$ 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
Antarmuka Semu untuk Loopback selalu memiliki MTU 4294967295 dan dapat diabaikan untuk langkah ini.
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
Jika MTU antarmuka dan jaringan tidak cocok, Anda dapat mengonfigurasi ulang MTU antarmuka tersebut. untuk menemukan petunjuk terkait cara memperbarui MTU untuk VM Windows, lihat Setelan VM dan MTU. Apabila cocok, maka masalah tersebut kemungkinan besar karena ketersediaan server. Langkah selanjutnya adalah Memeriksa log untuk melihat apakah VM telah di-reboot, dihentikan, atau dimigrasikan langsung untuk mengetahui apakah ada sesuatu yang terjadi pada VM selama waktu yang relevan.
Memeriksa log untuk melihat apakah VM telah di-reboot, dihentikan, atau dimigrasikan langsung
VM dapat di-reboot oleh pengguna, dimigrasikan langsung untuk pemeliharaan Google Cloud, atau dalam keadaan langka mungkin hilang dan dibuat ulang apabila terjadi kegagalan dalam host yang berisi VM selama siklus proses VM itu sendiri. Hal ini mungkin menyebabkan peningkatan latensi atau timeout koneksi secara singkat. Hal tersebut akan dicatat dalam log apabila salah satu di antaranya terjadi pada VM.
Lakukan hal berikut untuk melihat log VM:
Pada konsol Google Cloud, buka halaman Logging.
Pilih jangka waktu ketika terjadi latensi.
Gunakan kueri Logging berikut untuk menentukan apakah peristiwa VM terjadi ketika mendekati waktu latensi:
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" )
Apabila VM tidak dimulai atau dimigrasi selama waktu yang relevan, masalah tersebut mungkin karena kehabisan resource. Lanjutkan ke Memeriksa statistik jaringan dan OS untuk penghapusan paket karena kehabisan resource untuk memeriksa hal tersebut.
Memeriksa statistik jaringan dan OS untuk penghapusan paket karena kehabisan resource
Kehabisan resource adalah istilah umum yang berarti beberapa resource di VM, seperti bandwidth keluar, diminta untuk menangani lebih banyak daripada kapasitasnya. Kehabisan resource dapat menyebabkan paket dihapus secara berkala, sehingga akan terjadi latensi atau timeout koneksi. Timeout mungkin tidak terlihat ketika memulai sistem server atau klien, tetapi mungkin muncul seiring berjalannya waktu ketika sistem menghabiskan resource.
Berikut daftar perintah yang menampilkan statistik dan penghitung paket. Beberapa perintah ini adalah duplikasi dari hasil perintah lainnya. Anda dapat menggunakan perintah mana pun yang paling cocok untuk Anda dalam hal ini. Lihat catatan dalam setiap bagian untuk lebih memahami hasil yang diinginkan ketika menjalankan perintah tersebut. Sebaiknya jalankan perintah pada waktu yang berbeda untuk melihat apakah penghapusan atau error terjadi pada waktu yang sama dengan masalah ini.
Linux
Gunakan perintah
netstatuntuk melihat statistik jaringan.$ 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
Perintah netstat menghasilkan statistik jaringan berisi nilai untuk paket yang dibuang oleh protokol. Paket yang dihapus mungkin akibat kehabisan resource oleh antarmuka jaringan atau aplikasi. Lihat alasan penghitung untuk indikasi mengapa penghitung terus bertambah.
Periksa kern.log untuk menemukan log yang cocok
nf_conntrack: table full, dropping packet.Debian:
cat /var/log/kern.log | grep "dropping packet"CentOS:
sudo cat /var/log/dmesg | grep "dropping packet"Log ini menunjukkan bahwa tabel pelacakan koneksi untuk VM telah mencapai koneksi maksimum yang dapat dilacak. Koneksi lebih lanjut ke dan dari VM mungkin mengalami timeout. Apabila conntrack telah diaktifkan, jumlah koneksi maksimum dapat ditemukan dengan:
sudo sysctl net.netfilter.nf_conntrack_maxAnda dapat meningkatkan nilai untuk koneksi maksimum yang dilacak dengan mengubah sysctl
net.netfilter.nf_conntrack_maxatau dengan menyebarkan workload VM di beberapa VM untuk mengurangi beban.
UI Windows
Perfmon
- Menggunakan menu Windows, telusuri "perfmon" dan buka program tersebut.
- Pada menu sebelah kiri, pilih Performa > Alat Monitoring > Pemantau Performa.
- Pada tampilan utama, klik tanda plus "+" berwarna hijau untuk menambahkan penghitung performa ke
grafik pemantauan. Penghitung tersebut akan menarik:
- Adaptor Jaringan
- Panjang Antrean Output
- Paket Keluar yang Dihapus
- Error pada Paket Keluar
- Paket Diterima yang Dihapus
- Error pada Paket yang Diterima
- Paket Diterima yang Tidak Dikenal
- Antarmuka Jaringan
- Panjang Antrean Output
- Paket Keluar yang Dihapus
- Error pada Paket Keluar
- Paket Diterima yang Dihapus
- Error pada Paket yang Diterima
- Paket Diterima yang Tidak Dikenal
- Aktivitas Kartu Antarmuka Jaringan Per Pemroses
- Indikasi Penerimaan Resource Rendah per detik
- Paket yang Diterima Resource Rendah per detik
- Pemroses
- % Waktu Interupsi
- % Waktu Hak Istimewa
- % Waktu Pemroses
- % Waktu Pengguna
- Adaptor Jaringan
Pefmon memungkinkan Anda memetakan penghitung sebelumnya pada grafik deret waktu. Akan sangat bermanfaat untuk memperhatikan ketika pengujian sedang berlangsung atau server sedang terkena dampak. Lonjakan dalam penghitung terkait CPU seperti Waktu Interupsi dan Waktu Hak Istimewa dapat menunjukkan masalah saturasi ketika VM mencapai batas throughput CPU. Error dan penghapusan paket dapat terjadi ketika CPU disaturisasi sehingga menghilangkan paket sebelum diproses oleh soket klien atau server. Panjang Antrean Output juga akan bertambah selama saturisasi CPU karena lebih banyak paket yang menunggu untuk diproses.
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
Perintah netstat menghasilkan statistik jaringan berisi nilai untuk paket yang dibuang oleh protokol. Paket yang dihapus mungkin akibat kehabisan resource oleh antarmuka jaringan atau aplikasi.
Apabila resource habis, Anda dapat mencoba menyebarkan workload ke lebih banyak instance, memperbarui VM ke instance yang memiliki resource lebih banyak, menyesuaikan OS atau aplikasi untuk kebutuhan performa tertentu, memasukkan pesan error ke dalam mesin penelusuran untuk mencari solusi yang masuk akal, atau meminta bantuan menggunakan salah satu metode yang dijelaskan dalam Apabila masih memiliki masalah.
Apabila masalah tersebut bukan karena kehabisan resource, mungkin saja yang bermasalah adalah software server itu sendiri. Untuk menemukan panduan terkait pemecahan masalah software server, lanjutkan ke Memeriksa logging server untuk mendapat informasi terkait perilaku server.
Memeriksa logging server untuk mendapat informasi terkait perilaku server
Jika langkah-langkah sebelumnya tidak mengungkap masalah, waktu tunggu mungkin disebabkan oleh perilaku aplikasi seperti pemrosesan terhenti karena kehabisan vCPU. Periksa log server dan aplikasi untuk indikasi perilaku yang Anda alami.
Contohnya, server mengalami peningkatan latensi karena sistem upstream, seperti database yang sedang dimuat, karena mungkin mengalami antrean permintaan berlebih yang menyebabkan peningkatan penggunaan memori dan waktu tunggu CPU. Faktor ini mungkin menghasilkan koneksi yang gagal atau kelebihan buffer soket.
Koneksi TCP terkadang menghilangkan paket, tetapi konfirmasi selektif dan transmisi ulang paket biasanya memulihkan paket yang hilang untuk menghindari timeout koneksi. Sebagai gantinya, pertimbangkan bahwa timeout mungkin terjadi karena kegagalan server aplikasi atau sedang di-deploy kembali sehingga menyebabkan kegagalan koneksi sementara.
Apabila aplikasi server mengandalkan koneksi ke database atau layanan lain, pastikan bahwa layanan yang digabung tidak memiliki performa buruk. Aplikasi mungkin melacak metrik ini.
Apabila Anda masih memiliki masalah
Apabila Anda masih memiliki masalah, lihat Mendapatkan dukungan untuk langkah berikutnya. Sebaiknya Anda memiliki output dari langkah pemecahan masalah di atas yang tersedia untuk dibagikan ke kolaborator lain.
Langkah selanjutnya
- Jika Anda masih mengalami masalah, lihat halaman Referensi.