Tarkibga o'tish

Tarmoq diagnostikasi

Bu moduldagi oldingi beshta maqola — manzillash va routing, DHCP, DNS, doimiy konfiguratsiya va vaqtni sinxronlash — har biri o'z qatlamida ishlaydigan alohida mexanizmni ko'rib chiqdi. Amalda muammo paydo bo'lganda u qaysi qatlamda ekanini avval bilmasdan boshlashning iloji yo'q: "nega serverni ping qila olmayapman" degan savolning o'zi kamida to'rt xil sababga ega bo'lishi mumkin. Modulning yakunlovchi maqolasi sifatida bu maqola Troubleshooting jarayoni maqolasidagi besh bosqichli metodologiyani aynan tarmoq muammolariga ping, traceroute/tracepath, ss, tcpdump va oddiy port tekshiruvi yordamida qo'llaydi.

ping: birinchi va eng tez tekshiruv

ping -c 3 example.com

PING example.com (93.184.216.34) 56(84) bytes of data.
64 bytes from 93.184.216.34: icmp_seq=1 ttl=56 time=24.1 ms
64 bytes from 93.184.216.34: icmp_seq=2 ttl=56 time=23.8 ms
64 bytes from 93.184.216.34: icmp_seq=3 ttl=56 time=24.5 ms

--- example.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 23.800/24.133/24.500/0.292 ms

-c 3 uchta so'rovdan keyin to'xtaydi; usiz ping Ctrl+C bosilmaguncha ishlashda davom etadi. Muhim maydonlar:

  • resolve qilingan IP (93.184.216.34) — bu qatorning o'zi DNS ishlayotganini tasdiqlaydi;
  • time — borish-qaytish vaqti (RTT), javob qaytishi uchun qancha vaqt ketgani;
  • packet loss — yo'qolgan paketlar foizi; 0% har bir so'rovga javob kelganini bildiradi.

ping natijalari asosidagi diagnostika daraxti

  • nom bo'yicha ping ishlamaydi, IP bo'yicha ping esa ishlaydi → muammo tarmoqning o'zida emas, DNS qatlamida;
  • lokal tarmoqdagi hostga (masalan, gateway’ga) ping ishlamaydi → muammo interfeysda, kabelda yoki lokal xizmatda (IP va routing vositalari maqolasidagi ip link/ip address bilan tekshiring);
  • lokal tarmoq ishlaydi, lekin masofaviy (internet) host javob bermaydi → muammo routing'da yoki yuqori oqimda (routing jadvali ni tekshiring);
  • bitta muayyan masofaviy host (masalan, google.com) javob bermaydi, boshqalari esa javob beradi — bu o'sha host albatta "ishlamayapti" degani emas: ko'p tashkilotlar xavfsizlik siyosati sifatida ICMP’ni ataylab to'sadi. Xulosaga kelishdan oldin ishlashi ma’lum bo'lgan boshqa hostlarni tekshiring.

Note

Bitta muvaffaqiyatsiz ping hali "server ishlamayapti" degani emas. Har doim kamida ikkinchi, mustaqil tekshiruv bilan — boshqa host yoki boshqa vosita bilan — tasdiqlang.

traceroute va tracepath: yo'lni ko'rish

ping faqat "yetib boradi" yoki "yetib bormaydi" deydi; traceroute esa paket qaysi routerlar (hop’lar) orqali o'tishini ko'rsatadi — yo'lning aynan qayerida javob kelmay qolishini aniqlash uchun foydali.

traceroute -n example.com

traceroute to example.com (93.184.216.34), 30 hops max, 60 byte packets
 1  192.168.1.1  0.412 ms  0.389 ms  0.371 ms
 2  10.10.0.1  1.203 ms  1.198 ms  1.150 ms
 3  * * *
 4  203.0.113.5  8.921 ms  8.877 ms  8.812 ms
 ...
  • -n — hop IP’larini DNS orqali nomlarga aylantirmaydi; natija tezroq keladi va bu DNS’ning o'zi shubhali bo'lganda foydali;
  • har bir qator — bitta hop va uchta sinov paketi uchun javob vaqti;
  • * * * — o'sha hop’dan javob yo'q. Bu ko'pincha oraliq router traceroute trafigini ataylab past ustuvorlikda qayta ishlashi yoki umuman javob bermasligi sababli bo'ladi — agar keyingi hop’lar javob bersa, bu albatta haqiqiy muammo emas.

traceroute ishlatiladigan paket turi va portga qarab ayrim tizimlarda root huquqlarini yoki maxsus capability’ni talab qiladi. Bunday ruxsati bo'lmagan tizimlarda muqobil:

tracepath example.com

 1?: [LOCALHOST]                      pmtu 1500
 1:  192.168.1.1                                            0.417ms
 2:  10.10.0.1                                               1.212ms
 3:  no reply
 4:  203.0.113.5                                              8.903ms reached
     Resume: pmtu 1500 hops 4 back 4

tracepath root huquqlarisiz ishlaydi va PMTU ni ham aniqlaydi (path MTU — butun yo'l bo'ylab ruxsat etilgan eng kichik paket hajmi), lekin natijalarini traceroute ko'rsatadigan aniq raqamlangan hop guruhlari ko'rinishida emas, olingan har bir javob uchun bitta qator sifatida taqdim etadi.

mtr: traceroute va ping birlashtirilgan, uzluksiz

traceroute yo'lning bitta lahzalik ko'rinishini oladi; bitta hop’dagi vaqti-vaqti bilan bo'ladigan yo'qotishni faqat uchta sinov bilan o'tkazib yuborish oson. mtr (my traceroute) traceroute’ni uzluksiz ishga tushiradi va har bir hop bo'yicha statistikani to'playdi. Shu sababli u yo'lning qayerida vaqt davomida paketlar yo'qolayotganini aniqlashning standart vositasi:

mtr -n --report --report-cycles 100 example.com

HOST: webprod01                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1                0.0%   100    0.4   0.5   0.3   1.2   0.1
  2.|-- 10.10.0.1                  0.0%   100    1.2   1.3   1.1   2.0   0.2
  3.|-- 203.0.113.5               12.0%   100    8.9   9.1   8.7  15.3   1.1

--report belgilangan sondagi sikllarni (--report-cycles 100) bajaradi va jonli ko'rinish o'rniga xulosa chiqaradi; -n DNS resolution’ni o'tkazib yuboradi. Muhim ustun — Loss% va uni to'g'ri o'qish butun mahoratning o'zi: bitta hop’da birinchi marta paydo bo'lib, keyingi har bir hop’da saqlanib qoladigan yo'qotish o'sha hop’ni haqiqiy aybdor sifatida ko'rsatadi; bitta hop’da paydo bo'lib, undan keyingi hop’larda yo'qoladigan yo'qotish esa deyarli har doim routerning o'z ICMP javoblarini past ustuvorlikda qayta ishlashi, xolos — haqiqiy trafik yo'qotishi emas. Bitta traceroute lahzalik ko'rinishi aynan shu farqni ko'rsata olmaydi.

ss: qaysi jarayon qaysi portni tinglayapti

Zamonaviy tizimlar eski netstat o'rniga ss (socket statistics) dan foydalanadi — u kernel ma’lumotlarini to'g'ridan-to'g'ri o'qigani uchun ulanishlar soni ko'p bo'lganda ham tez ishlaydi.

sudo ss -tlnp

State    Recv-Q  Send-Q  Local Address:Port   Peer Address:Port  Process
LISTEN   0       128     0.0.0.0:22            0.0.0.0:*          users:(("sshd",pid=812,fd=3))
LISTEN   0       511     127.0.0.1:5432         0.0.0.0:*          users:(("postgres",pid=1204,fd=6))
LISTEN   0       128     0.0.0.0:80             0.0.0.0:*          users:(("nginx",pid=1590,fd=8))

Flag'lar:

  • -t — faqat TCP socket’lar (UDP uchun -u);
  • -l — faqat tinglayotgan socket’lar;
  • -n — portlar va manzillarni nomlar o'rniga raqamlar sifatida ko'rsatish (masalan, ssh o'rniga 22);
  • -p — portga qaysi jarayon (nomi va PID i) egalik qilishini ko'rsatish; odatda root talab qilinadi.

127.0.0.1:5432 bu port faqat lokal hostdan ulanishlarni qabul qilishini bildiradi — unga tashqi tarmoqdan yetib bo'lmaydi; 0.0.0.0:80 esa har bir interfeysda ulanishlarni qabul qiladi. Bu farq xizmat nega tashqaridan ko'rinmayotganini tushuntirishning klassik kaliti.

Barcha faol (faqat tinglayotgan emas) TCP ulanishlarni ko'rish:

ss -tn state established

tcpdump: paketning o'ziga qarash

ping va ss yetarli bo'lmaganda — so'rov serverga umuman yetib kelayotganini yoki qanday formatda kelayotganini tasdiqlash kerak bo'lganda — tcpdump xom trafikni ko'rsatadi.

sudo tcpdump -n -i enp0s3 port 80

12:04:01.123456 IP 192.168.1.50.51422 > 192.168.1.10.80: Flags [S], seq 123456, win 64240
12:04:01.123789 IP 192.168.1.10.80 > 192.168.1.50.51422: Flags [S.], seq 987654, ack 123457, win 65160
12:04:01.124011 IP 192.168.1.50.51422 > 192.168.1.10.80: Flags [.], ack 987655, win 64240
  • -n — DNS nomlarini resolve qilish o'rniga sonli manzil/portlarni ko'rsatish;
  • -i enp0s3 — faqat shu interfeysdagi trafik;
  • port 80 — filtr: faqat 80-portga tegishli paketlar;
  • Flags [S], [S.], [.] — TCP handshake bosqichlari (SYN, SYN-ACK, ACK); agar handshake to'liq yakunlansa, ulanish darajasida muammo yo'q — muammo ilova qatlamida bo'lishi mumkin.

HTTP so'rovining o'zini matn ko'rinishida ko'rish:

sudo tcpdump -n -i enp0s3 -A port 80

-A paket mazmunini ASCII’da (o'qiladigan matn sifatida) ham chiqaradi; HTTP kabi matnli protokollar uchun so'ralgan yo'l (masalan, GET /health HTTP/1.1) shu yerda ko'rinadi.

Warning

tcpdump bilan ushlangan trafik, ayniqsa shifrlanmagan protokollarda, parollar, autentifikatsiya tokenlari yoki boshqa maxfiy ma’lumotlarni ochiq matnda o'z ichiga olishi mumkin. Ushlangan faylni faqat kerakli muddat saqlang va endi kerak bo'lmaganda o'chiring; uni hech qachon ishonchsiz yoki umumiy tizimda qoldirmang.

Bitta port ochiq yoki yopiqligini tekshirish

To'liq paket tahlili kerak bo'lmaganda muayyan TCP port ochiqligini tezkor tekshirish:

timeout 3 bash -c 'echo > /dev/tcp/example.com/443' && echo "OPEN" || echo "CLOSED/NO RESPONSE"

Bu Bash’ning o'zining ichki /dev/tcp/ psevdo qurilmasidan foydalanadi — qo'shimcha paket o'rnatish kerak emas. Natijalarni talqin qilish:

  • ulanish darhol muvaffaqiyatli — port ochiq va xizmat tinglayapti;
  • "Connection refused" — hostga yetib borildi, lekin o'sha portni hech narsa tinglamayapti (yoki firewall aniq rad javobini yubordi);
  • umuman javob yo'q, timeout ishga tushguncha kutiladi — paket biror joyda yo'qolgan: firewall trafikni indamay tashlab yuboryapti yoki hostga umuman yetib bo'lmaydi.

Klassik muqobillar — telnet (interaktiv tekshirish uchun) yoki nc (netcat):

nc -zv example.com 443

-z ma’lumot yubormasdan faqat ulanishni tekshiradi; -v batafsil chiqish beradi.

Amaliy vaziyat: veb-xizmat tashqaridan ochilmayapti

Muammo: yangi deploy qilingan veb-ilova serverning o'zida curl localhost bilan ishlaydi, lekin boshqa kompyuterdagi brauzerda ochilmayapti.

1-qadam — muammoni serverning o'zida tasdiqlash:

curl -sS -o /dev/null -w '%{http_code}\n' http://localhost:8080/

Natija 200 bo'lsa, ilovaning o'zi ishlayapti — muammo tashqi ulanish qatlamida.

2-qadam — xizmat qaysi interfeysni tinglayotganini tekshirish:

sudo ss -tlnp | grep 8080

Agar natija 0.0.0.0:8080 emas, 127.0.0.1:8080 ni ko'rsatsa, sabab shu: xizmat faqat lokal hostdan ulanishlarni qabul qiladi va tashqi interfeysdan butunlay ko'rinmaydi.

3-qadam — gipoteza: ilova konfiguratsiyasi uning bind/listen manzilini 127.0.0.1 bilan cheklagan.

4-qadam — bitta o'zgarish bilan sinash: ilova konfiguratsiyasidagi tinglash manzilini 0.0.0.0 ga (yoki muayyan tashqi interfeys IP’siga) o'zgartiring, xizmatni qayta yuklang, so'ng qayta tekshiring:

sudo ss -tlnp | grep 8080

5-qadam — tashqaridan tasdiqlash: ulanishni boshqa hostdan (yoki nc/tcpdump bilan) sinab ko'ring:

nc -zv <server_ip> 8080

Agar baribir ulanmasa, keyingi gipoteza — firewall qoidasi; buni Firewall va UFW maqolasida ko'rilgan vositalar bilan tekshiring.

6-qadam — hujjatlashtirish: muammo aynan qaysi qatlamda bo'lganini (127.0.0.1 ga bog'langan ilova konfiguratsiyasi) va u qanday tuzatilganini qayd qiling.

Keng tarqalgan xatolar

Butun muammoni bitta ping natijasiga qarab aniqlash

Ko'p tashkilotlarda ICMP maxsus siyosat bilan to'sib qo'yilgan; muvaffaqiyatsiz ping avtomatik ravishda "server o'chiq" degani emas. Qo'shimcha ravishda ss, tcpdump yoki port tekshiruvi bilan tasdiqlang.

traceroute dagi * * * ni har doim muammo deb hisoblash

Agar keyingi hop’lar javob bersa, oraliq router shunchaki traceroute trafigini past ustuvorlikda qayta ishlayotgan bo'lishi mumkin — bu yo'ldagi haqiqiy uzilishdan farq qiladi.

Xizmat qaysi interfeysni tinglayotganini tekshirmaslik

127.0.0.1 va 0.0.0.0 o'rtasidagi farqni bilmaslik "ilova ishlayapti, lekin tashqaridan ko'rinmayapti" holatining eng keng tarqalgan yagona sababi. Bu farqni har doim avval ss -tlnp bilan tekshiring.

Shifrlangan trafikda tcpdump chiqishi to'liq o'qiladi deb kutish

TLS bilan shifrlangan ulanishda tcpdump ilova darajasidagi mazmunni emas, faqat handshake va metama’lumotlarni ko'rsatadi. Shifrlangan protokoldagi muammoni aniqlash uchun buning o'rniga ilovaning o'z log'lariga yoki maxsus TLS debugging vositalariga murojaat qiling.

Ushlangan paket faylini keragidan uzoqroq saqlash

tcpdump -w bilan yozilgan fayl maxfiy ma’lumotlarni o'z ichiga olishi mumkin. Muammo hal bo'lgach, uni o'chiring yoki xavfsiz saqlash siyosatiga muvofiq boshqaring.

Intervyuda

Tayyorlanishga arziydigan savol: "xizmat serverning o'zidan curl bilan ishlaydi, lekin boshqa hostdan refused emas, timeout bilan tugaydi. Aynan shu farq sizga nima aytadi?" refused javobi paket hostga yetib borganini va hech narsa tinglamayotganini bildiradi; jim timeout esa odatda paketga umuman javob kelmaganini bildiradi va bu ilovaning bog'lanish (binding) muammosiga emas, trafikni to'g'ridan-to'g'ri tashlab yuborayotgan firewall’ga, routing muammosiga yoki manzil hostiga yetib bo'lmasligiga ishora qiladi. Bu ikki nosozlik turini erta ajratish haqiqiy to'siq tarmoq yoki firewall qatlamida bo'lganda ilovani tekshirishga vaqt yo'qotishning oldini oladi.

Mashqlar

  1. ping -c 3 bilan bir nechta manzilni — lokal gateway, ichki server va tashqi domenni — tekshiring va natijalarni yuqoridagi diagnostika daraxti bo'yicha tasniflang.
  2. Bitta manzil uchun traceroute -n va tracepath chiqishlarini solishtiring va chiqish formatidagi farqni qayd qiling.
  3. sudo ss -tlnp chiqishidan kamida uchta xizmatni toping va har biri 127.0.0.1 ni yoki 0.0.0.0 ni tinglayotganini aniqlang.
  4. Sinov VM’ida faqat 127.0.0.1 ga bog'langan oddiy HTTP server ishga tushiring (masalan, python3 -m http.server), so'ng muammoni yuqoridagi amaliy vaziyatdagidek aniqlang va tuzating.

Mashqni bajardim deyish uchun: 4-mashqdagi tuzatishingizdan keyin ss -tlnp xizmat 0.0.0.0 ni (yoki muayyan tashqi interfeys manzilini) tinglayotganini ko'rsatishi va ikkinchi hostdan ulanish sinovi muvaffaqiyatli bo'lishi kerak — faqat serverdagi lokal curl natijasini o'zgartiradigan tuzatish yetarli emas.

Manbalar

  • man7.org: ping(8): https://man7.org/linux/man-pages/man8/ping.8.html
  • man7.org: traceroute(8): https://man7.org/linux/man-pages/man8/traceroute.8.html
  • man7.org: tracepath(8): https://man7.org/linux/man-pages/man8/tracepath.8.html
  • man7.org: ss(8): https://man7.org/linux/man-pages/man8/ss.8.html
  • TCPDUMP/LIBPCAP ochiq repozitoriysi — tcpdump(1): https://www.tcpdump.org/manpages/tcpdump.1.html
  • man7.org: nc(1) (netcat-openbsd): https://man7.org/linux/man-pages/man1/nc.1.html
  • GNU Bash Reference Manual — /dev/tcp yo'naltirishi: https://www.gnu.org/software/bash/manual/html_node/Redirections.html