Ketika saya bekerja dalam peran yang berfokus pada jaringan, salah satu tantangan terbesar selalu menjembatani kesenjangan antara rekayasa jaringan dan sistem. Sysadmin, kurang visibilitas ke jaringan, sering menyalahkan jaringan untuk pemadaman atau masalah aneh. Admin jaringan, yang tidak dapat mengontrol server dan lelah dengan sikap "bersalah sampai terbukti tidak bersalah" terhadap jaringan, sering kali menyalahkan titik akhir jaringan.
Tentu saja, menyalahkan tidak menyelesaikan masalah. Meluangkan waktu untuk memahami dasar-dasar domain seseorang dapat sangat membantu meningkatkan hubungan dengan tim lain dan mengarahkan penyelesaian masalah yang lebih cepat. Fakta ini terutama berlaku untuk sysadmin. Dengan memiliki pemahaman dasar tentang pemecahan masalah jaringan, kami dapat memberikan bukti yang lebih kuat kepada rekan jaringan kami ketika kami menduga bahwa jaringan mungkin salah. Demikian pula, kita sering dapat menghemat waktu dengan melakukan beberapa pemecahan masalah awal sendiri.
Dalam artikel ini, kami akan membahas dasar-dasar pemecahan masalah jaringan melalui baris perintah Linux.
Tinjauan singkat model TCP/IP
Pertama, mari luangkan waktu sejenak untuk meninjau dasar-dasar model jaringan TCP/IP. Sementara kebanyakan orang menggunakan model Open Systems Interconnection (OSI) untuk membahas teori jaringan, model TCP/IP lebih akurat mewakili rangkaian protokol yang digunakan di jaringan modern.
Lapisan dalam model jaringan TCP/IP, secara berurutan, meliputi:
- Lapisan 5: Aplikasi
- Lapisan 4: Transportasi
- Lapisan 3: Jaringan/Internet
- Lapisan 2: Tautan Data
- Lapisan 1: Fisik
Saya akan berasumsi bahwa Anda sudah familiar dengan model ini, dan akan melanjutkan dengan membahas cara untuk memecahkan masalah di tumpukan Lapisan 1 sampai 4. Di mana untuk memulai pemecahan masalah tergantung pada situasi. Misalnya, jika Anda dapat SSH ke server, tetapi server tidak dapat terhubung ke database MySQL, masalahnya tidak mungkin pada lapisan fisik atau tautan data di server lokal. Secara umum, adalah ide yang baik untuk bekerja dengan cara Anda ke bawah tumpukan. Mulailah dengan aplikasi, lalu pecahkan masalah setiap lapisan bawah secara bertahap hingga Anda berhasil mengisolasi masalahnya.
Dengan latar belakang itu, mari lompat ke baris perintah dan mulai pemecahan masalah.
Lapisan 1:Lapisan fisik
Kita sering mengabaikan lapisan fisik ("apakah Anda memastikan kabel terpasang?"), tetapi kita dapat dengan mudah memecahkan masalah lapisan fisik dari baris perintah Linux. Itu jika Anda memiliki konektivitas konsol ke host, yang mungkin tidak berlaku untuk beberapa sistem jarak jauh.
Mari kita mulai dengan pertanyaan paling mendasar:Apakah antarmuka fisik kita sudah siap? ip link show perintah memberitahu kita:
# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:82:d6:6e brd ff:ff:ff:ff:ff:ff
Perhatikan indikasi BAWAH pada output di atas untuk antarmuka eth0. Hasil ini berarti bahwa Layer 1 tidak muncul. Kami mungkin mencoba memecahkan masalah dengan memeriksa kabel atau ujung koneksi jarak jauh (mis., sakelar) untuk menemukan masalah.
Namun, sebelum Anda mulai memeriksa kabel, ada baiknya untuk memastikan bahwa antarmuka tidak hanya dinonaktifkan. Mengeluarkan perintah untuk memunculkan antarmuka dapat mengatasi masalah ini:
# ip link set eth0 up
Output dari ip link show bisa sulit untuk diurai secara sekilas. Untungnya, -br switch mencetak output ini dalam format tabel yang lebih mudah dibaca:
# ip -br link show
lo UNKNOWN 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eth0 UP 52:54:00:82:d6:6e <BROADCAST,MULTICAST,UP,LOWER_UP>
Sepertinya ip link set eth0 up berhasil, dan eth0 kembali beroperasi.
Perintah-perintah ini bagus untuk memecahkan masalah fisik yang jelas, tetapi bagaimana dengan masalah yang lebih berbahaya? Antarmuka dapat bernegosiasi pada kecepatan yang salah, atau tabrakan dan masalah lapisan fisik dapat menyebabkan hilangnya paket atau kerusakan yang mengakibatkan transmisi ulang yang mahal. Bagaimana kami mulai memecahkan masalah tersebut?
Kita dapat menggunakan -s tandai dengan ip perintah untuk mencetak statistik tambahan tentang antarmuka. Output di bawah ini menunjukkan antarmuka yang sebagian besar bersih, dengan hanya beberapa paket penerima yang jatuh dan tidak ada tanda-tanda masalah lapisan fisik lainnya:
# ip -s link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 52:54:00:82:d6:6e brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
34107919 5808 0 6 0 0
TX: bytes packets errors dropped carrier collsns
434573 4487 0 0 0 0
Untuk pemecahan masalah Lapisan 1 yang lebih lanjut, ethtool utilitas adalah pilihan yang sangat baik. Kasus penggunaan yang sangat baik untuk perintah ini adalah memeriksa untuk melihat apakah antarmuka telah menegosiasikan kecepatan yang benar. Antarmuka yang telah menegosiasikan kecepatan yang salah (misalnya antarmuka 10Gbps yang hanya melaporkan kecepatan 1Gbps) dapat menjadi indikator masalah perangkat keras/kabel, atau kesalahan konfigurasi negosiasi di satu sisi tautan (misalnya, port sakelar yang salah konfigurasi).
Hasil kami mungkin terlihat seperti ini:
# ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: on (auto)
Supports Wake-on: d
Wake-on: d
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
Perhatikan bahwa keluaran di atas menunjukkan tautan yang telah dinegosiasikan dengan benar ke kecepatan 1000Mbps dan dupleks penuh.
Lapisan 2:Lapisan tautan data
Lapisan tautan data bertanggung jawab atas lokal konektifitas jaringan; dasarnya, komunikasi frame antara host pada domain Layer 2 yang sama (biasa disebut jaringan area lokal). Protokol Layer 2 yang paling relevan untuk sebagian besar sysadmin adalah Address Resolution Protocol (ARP), yang memetakan alamat IP Layer 3 ke alamat MAC Ethernet Layer 2. Ketika sebuah host mencoba menghubungi host lain di jaringan lokalnya (seperti gateway default), host tersebut kemungkinan memiliki alamat IP host lain, tetapi tidak mengetahui alamat MAC host lain. ARP memecahkan masalah ini dan mencari tahu alamat MAC untuk kami.
Masalah umum yang mungkin Anda temui adalah entri ARP yang tidak terisi, terutama untuk gateway default host Anda. Jika localhost Anda tidak berhasil menyelesaikan alamat MAC Layer 2 gateway-nya, maka itu tidak akan dapat mengirim lalu lintas apa pun ke jaringan jarak jauh. Masalah ini mungkin disebabkan oleh konfigurasi alamat IP yang salah untuk gateway, atau mungkin masalah lain, seperti port switch yang salah dikonfigurasi.
Kami dapat memeriksa entri di tabel ARP kami dengan ip neighbor perintah:
# ip neighbor show
192.168.122.1 dev eth0 lladdr 52:54:00:11:23:84 REACHABLE
Perhatikan bahwa alamat MAC gateway diisi (kita akan berbicara lebih banyak tentang cara menemukan gateway Anda di bagian selanjutnya). Jika ada masalah dengan ARP, maka kita akan melihat kegagalan resolusi:
# ip neighbor show
192.168.122.1 dev eth0 FAILED
Penggunaan umum lainnya dari ip neighbor perintah melibatkan memanipulasi tabel ARP. Bayangkan tim jaringan Anda baru saja mengganti router upstream (yang merupakan gateway default server Anda). Alamat MAC mungkin telah berubah juga karena alamat MAC adalah alamat perangkat keras yang ditetapkan di pabrik.
Catatan: Sementara alamat MAC unik ditetapkan ke perangkat di pabrik, dimungkinkan untuk mengubah atau memalsukan ini. Banyak jaringan modern juga sering menggunakan protokol seperti Virtual Router Redundancy Protocol (VRRP), yang menggunakan alamat MAC yang dihasilkan.
Linux menyimpan entri ARP untuk jangka waktu tertentu, jadi Anda mungkin tidak dapat mengirim lalu lintas ke gateway default Anda sampai entri ARP untuk gateway Anda habis. Untuk sistem yang sangat penting, hasil ini tidak diinginkan. Untungnya, Anda dapat menghapus entri ARP secara manual, yang akan memaksa proses penemuan ARP baru:
# ip neighbor show
192.168.122.170 dev eth0 lladdr 52:54:00:04:2c:5d REACHABLE
192.168.122.1 dev eth0 lladdr 52:54:00:11:23:84 REACHABLE
# ip neighbor delete 192.168.122.170 dev eth0
# ip neighbor show
192.168.122.1 dev eth0 lladdr 52:54:00:11:23:84 REACHABLE
Dalam contoh di atas, kita melihat entri ARP yang terisi untuk 192.168.122.70 di eth0. Kami kemudian menghapus entri ARP dan dapat melihat bahwa entri tersebut telah dihapus dari tabel.
Lapisan 3:Lapisan jaringan/internet
Layer 3 melibatkan bekerja dengan alamat IP, yang harus akrab dengan sysadmin apapun. Pengalamatan IP menyediakan host dengan cara untuk menjangkau host lain yang berada di luar jaringan lokal mereka (meskipun kami sering menggunakannya di jaringan lokal juga). Salah satu langkah pertama untuk pemecahan masalah adalah memeriksa alamat IP lokal mesin, yang dapat dilakukan dengan ip address perintah, sekali lagi menggunakan -br tandai untuk menyederhanakan keluaran:
# ip -br address show
lo UNKNOWN 127.0.0.1/8 ::1/128
eth0 UP 192.168.122.135/24 fe80::184e:a34d:1d37:441a/64 fe80::c52f:d96e:a4a2:743/64
Kita dapat melihat bahwa antarmuka eth0 kita memiliki alamat IPv4 192.168.122.135. Jika kami tidak memiliki alamat IP, maka kami ingin memecahkan masalah itu. Kurangnya alamat IP dapat disebabkan oleh kesalahan konfigurasi lokal, seperti file konfigurasi antarmuka jaringan yang salah, atau dapat disebabkan oleh masalah dengan DHCP.
Alat garis depan paling umum yang digunakan sebagian besar sysadmin untuk memecahkan masalah Layer 3 adalah ping kegunaan. Ping mengirimkan paket ICMP Echo Request ke remote host, dan mengharapkan balasan ICMP Echo Reply. Jika Anda mengalami masalah konektivitas ke host jarak jauh, ping adalah utilitas umum untuk memulai pemecahan masalah Anda. Menjalankan ping sederhana dari baris perintah mengirimkan gema ICMP ke host jarak jauh tanpa batas waktu; Anda harus CTRL+C untuk mengakhiri ping atau meneruskan -c <num pings> bendera, seperti:
# ping www.google.com
PING www.google.com (172.217.165.4) 56(84) bytes of data.
64 bytes from yyz12s06-in-f4.1e100.net (172.217.165.4): icmp_seq=1 ttl=54 time=12.5 ms
64 bytes from yyz12s06-in-f4.1e100.net (172.217.165.4): icmp_seq=2 ttl=54 time=12.6 ms
64 bytes from yyz12s06-in-f4.1e100.net (172.217.165.4): icmp_seq=3 ttl=54 time=12.5 ms
^C
--- www.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 12.527/12.567/12.615/0.036 ms
Perhatikan bahwa setiap ping menyertakan jumlah waktu yang diperlukan untuk menerima respons. Saat ping bisa menjadi cara mudah untuk mengetahui apakah host masih hidup dan merespons, ini sama sekali tidak pasti. Banyak operator jaringan memblokir paket ICMP sebagai tindakan pencegahan keamanan, meskipun banyak yang tidak setuju dengan praktik ini. Gotcha umum lainnya mengandalkan bidang waktu sebagai indikator latensi jaringan yang akurat. Paket ICMP dapat dibatasi kecepatannya oleh peralatan jaringan perantara, dan paket tersebut tidak boleh diandalkan untuk memberikan representasi latensi aplikasi yang sebenarnya.
Alat berikutnya dalam sabuk alat pemecahan masalah Lapisan 3 adalah traceroute memerintah. Traceroute memanfaatkan bidang Time to Live (TTL) dalam paket IP untuk menentukan jalur yang dilalui lalu lintas ke tujuannya. Traceroute akan mengirimkan satu paket pada satu waktu, dimulai dengan TTL satu paket. Karena paket kedaluwarsa dalam perjalanan, router upstream mengirimkan kembali paket ICMP Time-to-Live Exceeded. Traceroute kemudian menambah TTL untuk menentukan hop berikutnya. Output yang dihasilkan adalah daftar router perantara yang dilalui paket dalam perjalanannya ke tujuan:
# traceroute www.google.com
traceroute to www.google.com (172.217.10.36), 30 hops max, 60 byte packets
1 acritelli-laptop (192.168.122.1) 0.103 ms 0.057 ms 0.027 ms
2 192.168.1.1 (192.168.1.1) 5.302 ms 8.024 ms 8.021 ms
3 142.254.218.133 (142.254.218.133) 20.754 ms 25.862 ms 25.826 ms
4 agg58.rochnyei01h.northeast.rr.com (24.58.233.117) 35.770 ms 35.772 ms 35.754 ms
5 agg62.hnrtnyaf02r.northeast.rr.com (24.58.52.46) 25.983 ms 32.833 ms 32.864 ms
6 be28.albynyyf01r.northeast.rr.com (24.58.32.70) 43.963 ms 43.067 ms 43.084 ms
7 bu-ether16.nycmny837aw-bcr00.tbone.rr.com (66.109.6.74) 47.566 ms 32.169 ms 32.995 ms
8 0.ae1.pr0.nyc20.tbone.rr.com (66.109.6.163) 27.277 ms * 0.ae4.pr0.nyc20.tbone.rr.com (66.109.1.35) 32.270 ms
9 ix-ae-6-0.tcore1.n75-new-york.as6453.net (66.110.96.53) 32.224 ms ix-ae-10-0.tcore1.n75-new-york.as6453.net (66.110.96.13) 36.775 ms 36.701 ms
10 72.14.195.232 (72.14.195.232) 32.041 ms 31.935 ms 31.843 ms
11 * * *
12 216.239.62.20 (216.239.62.20) 70.011 ms 172.253.69.220 (172.253.69.220) 83.370 ms lga34s13-in-f4.1e100.net (172.217.10.36) 38.067 ms
Traceroute tampak seperti alat yang hebat, tetapi penting untuk memahami keterbatasannya. Seperti ICMP, router perantara dapat memfilter paket yang traceroute bergantung pada, seperti pesan ICMP Time-to-Live Exceeded. Namun yang lebih penting, jalur yang dilalui lalu lintas ke dan dari tujuan tidak harus simetris, dan tidak selalu sama. Traceroute dapat menyesatkan Anda dengan berpikir bahwa lalu lintas Anda mengambil jalur linier yang bagus ke dan dari tujuannya. Namun, situasi ini jarang terjadi. Lalu lintas dapat mengikuti jalur kembali yang berbeda, dan jalur dapat berubah secara dinamis karena berbagai alasan. Sementara traceroute dapat memberikan representasi jalur yang akurat di jaringan perusahaan kecil, sering kali tidak akurat saat mencoba melacak di seluruh jaringan besar atau internet.
Masalah umum lainnya yang mungkin Anda hadapi adalah kurangnya gateway upstream untuk rute tertentu atau kurangnya rute default. Ketika sebuah paket IP dikirim ke jaringan yang berbeda, itu harus dikirim ke gateway untuk diproses lebih lanjut. Gateway harus tahu bagaimana merutekan paket ke tujuan akhirnya. Daftar gateway untuk rute yang berbeda disimpan dalam tabel perutean , yang dapat diperiksa dan dimanipulasi menggunakan ip route perintah.
Kita dapat mencetak tabel routing menggunakan ip route show perintah:
# ip route show
default via 192.168.122.1 dev eth0 proto dhcp metric 100
192.168.122.0/24 dev eth0 proto kernel scope link src 192.168.122.135 metric 100
Topologi sederhana seringkali hanya memiliki gateway default yang dikonfigurasi, diwakili oleh entri "default" di bagian atas tabel. Gateway default yang hilang atau salah adalah masalah umum.
Jika topologi kita lebih kompleks dan kita memerlukan rute yang berbeda untuk jaringan yang berbeda, kita dapat memeriksa rute untuk awalan tertentu:
# ip route show 10.0.0.0/8
10.0.0.0/8 via 192.168.122.200 dev eth0
Dalam contoh di atas, kami mengirimkan semua lalu lintas yang ditujukan ke jaringan 10.0.0.0/8 ke gateway yang berbeda (192.168.122.200).
Meskipun bukan protokol Layer 3, ada baiknya menyebutkan DNS saat kita berbicara tentang pengalamatan IP. Antara lain, Domain Name System (DNS) menerjemahkan alamat IP menjadi nama yang dapat dibaca manusia, seperti www.redhat.com . Masalah DNS sangat umum, dan terkadang tidak jelas untuk dipecahkan. Banyak buku dan panduan online telah ditulis tentang DNS, tetapi kami akan fokus pada dasar-dasarnya di sini.
Tanda masalah DNS adalah kemampuan untuk terhubung ke host jarak jauh berdasarkan alamat IP tetapi bukan nama hostnya. Melakukan nslookup quick cepat pada nama host dapat memberi tahu kami sedikit (nslookup adalah bagian dari bind-utils paket pada sistem berbasis Linux Red Hat Enterprise):
# nslookup www.google.com
Server: 192.168.122.1
Address: 192.168.122.1#53
Non-authoritative answer:
Name: www.google.com
Address: 172.217.3.100
Output di atas menunjukkan server bahwa pencarian dilakukan terhadap 192.168.122.1 dan alamat IP yang dihasilkan adalah 172.217.3.100.
Jika Anda melakukan nslookup untuk host tetapi ping atau traceroute coba gunakan alamat IP yang berbeda, Anda mungkin melihat masalah entri file host. Akibatnya, periksa file host untuk masalah:
# nslookup www.google.com
Server: 192.168.122.1
Address: 192.168.122.1#53
Non-authoritative answer:
Name: www.google.com
Address: 172.217.12.132
# ping -c 1 www.google.com
PING www.google.com (1.2.3.4) 56(84) bytes of data.
^C
--- www.google.com ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
# cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
1.2.3.4 www.google.com
Perhatikan bahwa pada contoh di atas, alamat untuk www.google.com diselesaikan ke 172.217.12.132. Namun, ketika kami mencoba melakukan ping ke host, lalu lintas dikirim ke 1.2.3.4. Lihatlah /etc/hosts file, kita dapat melihat sebuah override yang seseorang harus telah menambahkan sembarangan. Masalah penggantian file host sangat umum, terutama jika Anda bekerja dengan pengembang aplikasi yang sering kali perlu melakukan penggantian ini untuk menguji kode mereka selama pengembangan.
Lapisan 4:Lapisan transport
Lapisan transport terdiri dari protokol TCP dan UDP, dengan TCP sebagai protokol berorientasi koneksi dan UDP tanpa koneksi. Aplikasi mendengarkan di soket , yang terdiri dari alamat IP dan port. Lalu lintas yang ditujukan ke alamat IP pada port tertentu akan diarahkan ke aplikasi pendengar oleh kernel. Diskusi lengkap tentang protokol ini berada di luar cakupan artikel ini, jadi kami akan fokus pada cara memecahkan masalah konektivitas pada lapisan ini.
Hal pertama yang mungkin ingin Anda lakukan adalah melihat port apa yang didengarkan di localhost. Hasilnya dapat berguna jika Anda tidak dapat terhubung ke layanan tertentu di mesin, seperti web atau server SSH. Masalah umum lainnya terjadi ketika daemon atau layanan tidak dapat dimulai karena ada hal lain yang mendengarkan di port. ss perintah sangat berharga untuk melakukan jenis tindakan ini:
# ss -tunlp4
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
udp UNCONN 0 0 *:68 *:* users:(("dhclient",pid=3167,fd=6))
udp UNCONN 0 0 127.0.0.1:323 *:* users:(("chronyd",pid=2821,fd=1))
tcp LISTEN 0 128 *:22 *:* users:(("sshd",pid=3366,fd=3))
tcp LISTEN 0 100 127.0.0.1:25 *:* users:(("master",pid=3600,fd=13))
Mari kita hancurkan bendera ini:
- -t - Tampilkan port TCP.
- -u - Tampilkan port UDP.
- -n - Jangan mencoba untuk menyelesaikan nama host.
- -l - Hanya tampilkan port mendengarkan.
- -p - Tampilkan proses yang menggunakan soket tertentu.
- -4 - Hanya tampilkan soket IPv4.
Melihat output, kita dapat melihat beberapa layanan mendengarkan. sshd aplikasi mendengarkan pada port 22 pada semua alamat IP, dilambangkan dengan *:22 keluaran.
ss command adalah alat yang ampuh, dan tinjauan halaman manual singkatnya dapat membantu Anda menemukan tanda dan opsi untuk menemukan apa pun yang Anda cari.
Skenario pemecahan masalah umum lainnya melibatkan konektivitas jarak jauh. Bayangkan mesin lokal Anda tidak dapat terhubung ke port jarak jauh, seperti MySQL pada port 3306. Alat yang tidak biasa, tetapi biasanya diinstal, dapat menjadi teman Anda saat memecahkan masalah jenis ini:telnet . telnet perintah mencoba membuat koneksi TCP dengan host dan port apa pun yang Anda berikan. Fitur ini sempurna untuk menguji konektivitas TCP jarak jauh:
# telnet database.example.com 3306
Trying 192.168.1.10...
^C
Pada output di atas, telnet hang sampai kita membunuhnya. Hasil ini memberi tahu kami bahwa kami tidak dapat mencapai port 3306 pada mesin jarak jauh. Mungkin aplikasi tidak mendengarkan, dan kita perlu menggunakan langkah pemecahan masalah sebelumnya menggunakan ss pada host jarak jauh—jika kita memiliki akses. Kemungkinan lain adalah host atau firewall perantara yang menyaring lalu lintas. Kami mungkin perlu bekerja dengan tim jaringan untuk memverifikasi konektivitas Layer 4 di seluruh jalur.
Telnet bekerja dengan baik untuk TCP, tapi bagaimana dengan UDP? netcat alat menyediakan cara sederhana untuk memeriksa port UDP jarak jauh:
# nc 192.168.122.1 -u 80
test
Ncat: Connection refused.
netcat utilitas dapat digunakan untuk banyak hal lain, termasuk menguji konektivitas TCP. Perhatikan bahwa netcat mungkin tidak diinstal pada sistem Anda, dan sering kali dianggap sebagai risiko keamanan jika dibiarkan tergeletak begitu saja. Anda mungkin ingin mempertimbangkan untuk mencopot pemasangannya setelah menyelesaikan pemecahan masalah.
Contoh di atas membahas utilitas umum dan sederhana. Namun, alat yang jauh lebih kuat adalah nmap . Seluruh buku telah dikhususkan untuk nmap fungsionalitasnya, jadi kami tidak akan membahasnya di artikel pemula ini, tetapi Anda harus mengetahui beberapa hal yang dapat dilakukannya:
- mesin jarak jauh pemindaian port TCP dan UDP.
- Sidik jari OS.
- Menentukan apakah port jarak jauh ditutup atau hanya difilter.
Menutup
Kami membahas banyak dasar jaringan pengantar dalam artikel ini, meningkatkan tumpukan jaringan dari kabel dan beralih ke alamat IP dan port. Alat yang dibahas di sini akan memberi Anda titik awal yang baik untuk memecahkan masalah konektivitas jaringan dasar, dan alat tersebut akan terbukti membantu saat mencoba memberikan detail sebanyak mungkin kepada tim jaringan Anda.
Saat Anda maju dalam perjalanan pemecahan masalah jaringan, Anda pasti akan menemukan flag perintah yang sebelumnya tidak dikenal, one-liner yang mewah, dan alat baru yang canggih (tcpdump dan Wireshark adalah favorit saya) untuk menggali penyebab masalah jaringan Anda. Bersenang-senanglah, dan ingat:Paket tidak bohong!