Linux network commands: ip, ss, ping, traceroute, dig at curl para sa network diagnostics

Halos lahat ng pang-araw-araw na network diagnostics sa Linux ay kayang gawin ng ilang linya lang: ipinapakita ng ip ang mga address at route, ipinapakita ng ss ang bukas na port at koneksyon, sinusuri ng ping at traceroute kung abot ang host, sinusuri ng dig ang DNS, at ipinapakita ng curl ang sagot ng web service. Nasa ibaba ang cheat sheet na may mga flag at ang hakbang-hakbang na pagkakasunod-sunod para hanapin ang sanhi kapag "walang network".

Cheat sheet: linux network commands sa isang table

ip: mga address, interface at route

Pinalitan ng command na ip mula sa package na iproute2 ang lumang ifconfig at route. Puwedeng paikliin ang mga subcommand: ip a = ip addr, ip r = ip route. Ang flag na -br ay nagbibigay ng maikling output, at ang -c naman ay nagkukulay dito.

$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             192.168.1.25/24 fe80::a00:27ff:fe4e:66a1/64
docker0          DOWN           172.17.0.1/16

Kung walang address ang interface mula sa tamang network o nasa estadong DOWN, hindi mo na kailangang hanapin pa sa ibang lugar. Nasa layer na iyon ang problema.

Paano magdagdag ng IP address at buksan ang interface

sudo ip link set eth0 up
sudo ip addr add 192.168.1.50/24 dev eth0
sudo ip addr del 192.168.1.50/24 dev eth0

Ang mga pagbabagong ginawa gamit ang ip ay tatagal hanggang sa mag-reboot. Ang permanenteng setting ay nasa configuration ng system: netplan sa Ubuntu, NetworkManager (nmcli) sa Fedora at RHEL, at systemd-networkd sa mga server.

Mga route at default gateway

$ ip route
default via 192.168.1.1 dev eth0 proto dhcp metric 100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.25

$ ip route get 10.20.0.5
10.20.0.5 via 192.168.1.1 dev eth0 src 192.168.1.25 uid 1000

Ang linyang default via ay ang gateway kung saan napupunta ang lahat ng hindi tumugma sa mas tiyak na route. Kapag wala ang linyang ito, walang internet kahit gumagana ang lokal na network. Para magdagdag ng route: sudo ip route add 10.20.0.0/16 via 192.168.1.254.

ss: aling port ang bukas at sino ang nakikinig dito

Ang ss ang pumalit sa netstat at mas mabilis ito. Ang pinakakaraniwang kombinasyon ay ss -tulpn:

$ sudo ss -tulpn
Netid State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
tcp   LISTEN 0      511          0.0.0.0:80         0.0.0.0:*     users:(("nginx",pid=812,fd=6))
tcp   LISTEN 0      128          0.0.0.0:22         0.0.0.0:*     users:(("sshd",pid=640,fd=3))
tcp   LISTEN 0      151        127.0.0.1:3306       0.0.0.0:*     users:(("mysqld",pid=901,fd=21))

Bigyang-pansin ang address: ang 0.0.0.0 ay nangangahulugang tumatanggap ang serbisyo ng koneksyon mula sa lahat ng interface, habang ang 127.0.0.1 ay lokal lamang. Ito ang madalas na dahilan kung bakit hindi "sumasagot" ang database mula sa ibang makina.

Paano malaman kung sino ang gumagamit ng port

sudo ss -ltnp 'sport = :8080'
sudo ss -tn dst 10.0.0.7          # mga koneksyon papunta sa partikular na address
ss -tan state time-wait | wc -l   # ilang socket ang nasa TIME-WAIT

ping: abot ba ang host

Nagpapadala ang ping ng ICMP echo request at ipinapakita ang oras ng sagot at ang nawalang packet. Sa Linux, tumatakbo ito nang walang katapusan, kaya itakda ang bilang ng packet gamit ang flag na -c.

$ ping -c 4 8.8.8.8
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=12.4 ms
...
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 12.1/12.5/13.0/0.3 ms

Mga kapaki-pakinabang na flag: -i 0.2 para sa interval, -W 2 para sa timeout ng sagot, -4/-6 para sa bersyon ng protocol, at -s 1472 -M do para suriin ang MTU nang walang fragmentation. Tandaan na maraming server at cloud ang humaharang sa ICMP, kaya ang kawalan ng sagot sa ping ay hindi pa nangangahulugang hindi abot ang host.

traceroute at mtr: saan nawawala ang mga packet

Ipinapakita ng traceroute ang mga node sa daan papunta sa target. Normal ang mga asterisk sa ilang hop, dahil maaaring hindi sumagot ang ilang router sa gitna. Ang nakababahalang senyales ay kapag mula sa isang hop pataas ay puro asterisk na hanggang dulo.

traceroute -n example.com        # walang DNS name, mas mabilis
sudo traceroute -T -p 443 example.com   # TCP sa halip na UDP, nakakalusot sa firewall
tracepath example.com            # walang root, at ipinapakita rin ang MTU

Pinagsasama ng mtr ang ping at traceroute at ina-update ang estadistika ng pagkawala sa bawat hop nang real time. Para sa ulat: mtr -rwc 50 example.com.

dig: pagsusuri ng DNS

Ang dig, na galing sa package na dnsutils (bind-utils sa RHEL), ang pangunahing tool para suriin ang DNS. Ang maikling anyo ay nagbabalik lamang ng sagot:

$ dig +short example.com
93.184.215.14

$ dig example.com MX +short
$ dig @8.8.8.8 example.com A       # magtanong sa partikular na server
$ dig -x 8.8.8.8 +short            # reverse record (PTR)
$ dig +trace example.com           # sundan ang kadena mula sa root servers

Sa buong output, tingnan ang status: ang NOERROR ay nangangahulugang may nakitang record, ang NXDOMAIN ay walang ganoong domain, at ang SERVFAIL ay hindi nakasagot ang server (madalas na problema sa DNSSEC o hindi maabot na authoritative server). Kung sumasagot ang dig @8.8.8.8 pero hindi ang karaniwang dig, ang lokal na resolver ang may problema: tingnan ang /etc/resolv.conf at resolvectl status.

Tandaan na hindi binabasa ng dig ang /etc/hosts. Para subukan ang pag-resolve ng pangalan na gaya ng ginagawa ng application, gamitin ang getent hosts example.com.

curl: pagsusuri ng HTTP at API

Sinasagot ng curl ang huling tanong: tumutugon ba ang serbisyo at ano ang ibinabalik nito.

$ curl -s -o /dev/null -w '%{http_code} %{time_connect} %{time_total}\n' https://example.com
200 0.041 0.187

Malinaw ang mga error message ng curl kung aling layer ang may problema: ang Could not resolve host ay DNS, ang Connection refused ay sarado ang port o walang nakikinig, ang Connection timed out ay hinaharangan ng firewall ang packet o walang route, at ang SSL certificate problem ay may problema sa certificate.

Pagkakasunod-sunod ng diagnostics: kapag "hindi gumagana ang network"

1. Interface at address: ip -br addr. Dapat UP ang interface at may address ito.
2. Gateway: ip route. Dapat may default via; pagkatapos ping -c 3 <gateway>.
3. Panlabas na network sa pamamagitan ng IP: ping -c 3 1.1.1.1. Kung gumagana ito, maayos ang routing.
4. DNS: dig +short example.com. Kung walang sagot o may error habang gumagana ang ping sa IP, ang resolver ang problema.
5. Port: nc -zv host 443 o curl -v. Sa server, gamitin ang ss -tulpn para tingnan kung nakikinig ang serbisyo at sa aling address.
6. Firewall: sudo nft list ruleset, sudo iptables -L -n, sudo ufw status.
7. Application: curl -I at mga log ng serbisyo (journalctl -u nginx).

Mula ibaba pataas ang pagsusuri at huwag laktawan ang mga hakbang. Sa ganitong paraan, makikita mo sa loob ng ilang minuto kung nasaang layer ang problema, sa halip na i-restart ang lahat nang walang plano.

Mga lumang command at mga bagong kapalit

Sa mga bagong distribution, madalas hindi na naka-install ang net-tools, kaya mas mabuting masanay na sa mga bagong command.

Buod

Para sa pang-araw-araw na diagnostics, sapat na ang anim na linux network commands: ip, ss, ping, traceroute, dig at curl. Suriin layer by layer (address, route, DNS, port, application) at mabilis mong makikita ang sanhi ng problema. Ang mga network command at ang pagsusuri ng karaniwang aberya ay ipinapaliwanag din nang praktikal sa kursong Linux.