Laboratorijska vežba – Modul 19 – Snimanje i analiza ARP, ICMP, DNS, DHCP, HTTP i TCP saobraćaja

Cilj vežbe

Snimiti saobraćaj generisan interakcijom sa Ubuntu Server VM iz Modula 18, primeniti capture i display filtere da izolujete ARP, ICMP, DNS, DHCP, HTTP i TCP handshake saobraćaj, analizirati Follow HTTP Stream, i dijagnostikovati veštački unet gubitak paketa preko TCP retransmisija.

Napomena: Ova vežba koristi Wireshark na host računaru, snimajući saobraćaj ka virtuelnim mašinama izgrađenim u Modulima 17-18. Sve snimanje se vrši isključivo na sopstvenoj laboratorijskoj mreži.

Potrebno predznanje

Kompletna teorija ovog modula (Teme 1–15).
Funkcionalna Ubuntu Server VM iz Modula 18 (statička adresa, SSH sa ključem, UFW, nginx).
(Opciono, za dodatni izazov) Windows klijent VM iz Modula 17.

Potrebni programi

Wireshark (instaliran prema uputstvo-za-instalaciju-alata.md).
VirtualBox sa Ubuntu Server VM iz Modula 18.

Topologija

graph LR
    Host["Host računar<br/>(Wireshark snima ovde)"] ---|"VirtualBox mrežni adapter"| LINUX1["LINUX1 (Ubuntu Server, Modul 18)<br/>192.168.56.20"]

Koraci vežbe

Korak 1 – Pokretanje snimanja

Otvorite Wireshark na host računaru.
Identifikujte interfejs povezan sa VirtualBox mrežom (Tema 2) — obično nazvan slično „VirtualBox Host-Only Network".
U polju za capture filter (Tema 3), unesite: host 192.168.56.20 (prilagodite stvarnoj adresi vaše LINUX1 VM iz Modula 18).
Kliknite „Start capture".

Korak 2 – Generisanje ARP i ICMP saobraćaja

Sa host računara (terminal ili Command Prompt):

ping -c 4 192.168.56.20

(na Windows-u bez -c, samo ping 192.168.56.20)

U Wireshark-u, primenite display filter (Tema 4):

arp

Identifikujte ARP Request/Reply par (Tema 5) ako je ovo prva komunikacija sa tom adresom u ovoj sesiji. Zatim primenite:

icmp

Identifikujte 4 Echo Request/Reply para (Tema 6), i uporedite Identifier/Sequence number polja.

Korak 3 – Generisanje DNS saobraćaja

Sa host računara:

nslookup google.com 192.168.56.20

(ako LINUX1 nema DNS server, koristite bilo koji dostupan DNS upit, npr. obično pregledanje interneta, i podesite capture filter da ne ograničava na LINUX1 samo za ovaj korak)

Primenite display filter:

dns

Identifikujte DNS Query/Response par (Tema 7) i Transaction ID polje.

Korak 4 – Generisanje TCP handshake i HTTP saobraćaja

Sa host računara, u pretraživaču ili preko curl:

curl http://192.168.56.20

Primenite display filter:

tcp.flags.syn == 1 && ip.addr == 192.168.56.20

Identifikujte SYN i SYN-ACK pakete (Tema 9). Zatim primenite:

http

Pronađite GET zahtev i 200 OK odgovor. Desni klik na jedan od paketa → Follow → HTTP Stream (Tema 11, 13) da vidite kompletan, čitljiv zahtev i HTML odgovor.

Korak 5 – Generisanje HTTPS saobraćaja i analiza SNI

Sa host računara, posetite bilo koji HTTPS sajt u pretraživaču (uklonite privremeno capture filter ili pokrenite novo snimanje bez njega, jer sajt neće biti na adresi 192.168.56.20).

Primenite display filter:

tls.handshake.type == 1

Pronađite Client Hello paket i proširite Handshake Protocol sekciju da pronađete Server Name polje (Tema 12) — potvrdite da odgovara imenu sajta koji ste posetili. Pokušajte Follow → TLS Stream na narednim paketima i uporedite (nečitljiv) rezultat sa čitljivim HTTP primerom iz Koraka 4.

Korak 6 – Simulacija gubitka paketa i analiza retransmisija

Na LINUX1 (Modul 18 veština), privremeno uvedite veštački gubitak paketa:

sudo tc qdisc add dev enp0s3 root netem loss 15%

Ponovo pokrenite snimanje sa capture filterom host 192.168.56.20, zatim sa host računara prenesite veći fajl preko SCP-a (Modul 18):

scp velikifajl.zip <korisnik>@192.168.56.20:/home/<korisnik>/

Nakon završetka (ili prekida) prenosa, u Wireshark-u primenite:

tcp.analysis.retransmission

Prebrojte retransmisije i uporedite sa ukupnim brojem paketa u snimku (Statistics → Capture File Properties, ili donji desni ugao prozora).

Uklonite simulaciju nakon testa:

sudo tc qdisc del dev enp0s3 root netem

Korak 7 – Statistics pregled

Otvorite Statistics → Conversations na snimku iz Koraka 6 i identifikujte koji par adresa je razmenio najviše bajtova. Zatim otvorite Statistics → I/O Graph (Tema 14) i identifikujte vizuelni pad u protoku tokom perioda kada je netem simulacija bila aktivna.

Korak 8 – Dijagnostička vežba: mreža naspram aplikacije

Zamislite scenario u kome korisnik prijavljuje da je pristup nginx veb serveru na LINUX1 „spor".
Bez simulacije iz Koraka 6 (uklonjene u tom koraku), ponovo snimite saobraćaj tokom pristupa serveru.
Proverite redom (Tema 15): I/O Graph, tcp.analysis.retransmission, dns, tcp.flags.syn == 1, i Follow HTTP Stream (vreme između zahteva i odgovora).
Objasnite svojim rečima, na osnovu ovog redosleda, kako biste razlikovali „mrežni" problem (kao u Koraku 6) od „aplikativnog" problema (spor server koji generiše odgovor) da ste dobili samo prijavu „portal je spor", bez znanja unapred šta je uzrok.

Korak 9 – Čuvanje snimka

File → Save As, sačuvajte snimak iz Koraka 6 (sa simuliranim gubitkom paketa) kao .pcapng fajl radi buduće reference ili predaje uz zadatke.

Komande za proveru

(u Wireshark display filter polju)
arp
icmp
dns
bootp
tcp.flags.syn == 1
tcp.analysis.retransmission
tls.handshake.type == 1
http

Najčešće greške

Greška	Uzrok	Rešenje
Wireshark ne prikazuje nijedan interfejs	Npcap (Windows) nije instaliran, ili korisnik nije u `wireshark` grupi (Linux)	Proveriti uputstvo-za-instalaciju-alata.md
Nema snimljenog saobraćaja	Pogrešan interfejs izabran, ili capture filter previše restriktivan	Proveriti Korak 1, privremeno ukloniti filter da potvrdite da saobraćaj uopšte postoji
ARP paketi se ne pojavljuju	Adresa je već u ARP kešu iz prethodne komunikacije	Sačekajte da keš istekne, ili koristite `arp -d`/`ip neigh flush` (Moduli 17-18) da ga ručno obrišete pre testa
Nema retransmisija u Koraku 6 uprkos `netem`	`tc netem` primenjen na pogrešan interfejs, ili nije uklonjen iz prethodnog testa pa je konfiguracija duplirana	Proveriti `sudo tc qdisc show dev enp0s3` na LINUX1
SNI polje nije vidljivo u Client Hello	Sajt koristi Encrypted Client Hello (ECH), noviju tehnologiju koja i SNI enkriptuje	Probajte drugi, stariji sajt bez ECH podrške za svrhu ove vežbe

Postupak rešavanja problema (troubleshooting)

Potvrdite da Wireshark snima na ispravnom interfejsu (Tema 2) generisanjem poznatog saobraćaja (ping) i proverom da se pojavljuje u snimku.
Proverite capture filter sintaksu ako se očekivani saobraćaj uopšte ne pojavljuje.
Koristite display filtere postepeno, od širih (tcp) ka užim (tcp.analysis.retransmission), da lakše uočite gde se očekivani saobraćaj „gubi" iz prikaza.
Za probleme sa tc netem, uvek proverite tc qdisc show pre i posle svake izmene da potvrdite tačno stanje.

Završna provera

Vežba je uspešno završena kada:

Uspešno ste identifikovali ARP, ICMP, DNS i TCP handshake pakete u sopstvenom snimku.
Follow HTTP Stream prikazuje čitljiv zahtev/odgovor, dok TLS Stream ostaje nečitljiv.
Broj retransmisija sa aktivnom netem simulacijom je značajno veći nego bez nje.
Objašnjena je razlika u dijagnostičkom pristupu između mrežnog i aplikativnog uzroka sporosti (Korak 8).

Dodatni izazov

Ponovite Korak 6 sa različitim procentima gubitka paketa (loss 5%, loss 30%) i dokumentujte kako se broj retransmisija i ukupno trajanje SCP prenosa menjaju sa svakim nivoom. Dodatno, istražite tc netem delay 200ms (umesto loss) i uporedite koji efekat (gubitak naspram kašnjenja) izaziva više retransmisija u Wireshark snimku, i objasnite zašto na osnovu koncepata latencije naspram packet loss-a iz Modula 15.

Rešenje

Kompletno rešenje ove vežbe nalazi se u /resenja/modul-19/04-laboratorijska-vezba-resenje.md.

📖 Prikaži rešenje

Rešenje laboratorijske vežbe – Modul 19

Korak 2 – ARP i ICMP

ARP par (ako je prva komunikacija):

No.  Time    Source             Destination        Protocol  Info
1    0.000   HostMachine_xx     Broadcast          ARP       Who has 192.168.56.20? Tell 192.168.56.1
2    0.001   PCSSystemtec_xx    HostMachine_xx     ARP       192.168.56.20 is at 08:00:27:aa:bb:cc

ICMP parovi (filter icmp):

No.  Time    Source          Destination     Protocol  Info
3    0.002   192.168.56.1    192.168.56.20   ICMP      Echo (ping) request  id=0x0001, seq=1/256
4    0.003   192.168.56.20   192.168.56.1    ICMP      Echo (ping) reply    id=0x0001, seq=1/256
5    1.003   192.168.56.1    192.168.56.20   ICMP      Echo (ping) request  id=0x0001, seq=2/512
6    1.004   192.168.56.20   192.168.56.1    ICMP      Echo (ping) reply    id=0x0001, seq=2/512

(Identifier ostaje isti kroz celu ping sesiju; Sequence number raste sa svakim paketom.)

Korak 3 – DNS

No.  Time    Source          Destination     Protocol  Info
10   2.100   192.168.56.1    8.8.8.8         DNS       Standard query 0x1a2b A google.com
11   2.115   8.8.8.8         192.168.56.1    DNS       Standard query response 0x1a2b A 142.250.x.x

(Transaction ID 0x1a2b je identičan u oba paketa, povezujući upit sa odgovorom.)

Korak 4 – TCP handshake i HTTP

No.  Time    Source          Destination     Protocol  Info
20   3.000   192.168.56.1    192.168.56.20   TCP       [SYN] Seq=0
21   3.001   192.168.56.20   192.168.56.1    TCP       [SYN, ACK] Seq=0 Ack=1
22   3.001   192.168.56.1    192.168.56.20   TCP       [ACK] Seq=1 Ack=1
23   3.002   192.168.56.1    192.168.56.20   HTTP      GET / HTTP/1.1
24   3.003   192.168.56.20   192.168.56.1    HTTP      HTTP/1.1 200 OK

Follow HTTP Stream (skraćeno):

GET / HTTP/1.1
Host: 192.168.56.20
User-Agent: curl/8.x

HTTP/1.1 200 OK
Server: nginx/1.24.0
Content-Type: text/html

<!DOCTYPE html>
<html>
<head><title>Welcome to nginx!</title></head>
...

Kompletan, čitljiv sadržaj potvrđuje da HTTP putuje neenkriptovano (Tema 11).

Korak 5 – HTTPS i SNI

Client Hello (filter tls.handshake.type == 1):

Transport Layer Security
    TLSv1.3 Record Layer: Handshake Protocol: Client Hello
        Handshake Protocol: Client Hello
            Extension: server_name
                Server Name Indication extension
                    Server Name: www.primer-sajt.com

Follow TLS Stream (skraćeno):

......{binarni, nečitljivi bajtovi}......

Za razliku od HTTP Stream-a, TLS Stream ne prikazuje nikakav čitljiv tekst — potvrđuje enkripciju (Tema 12).

Korak 6 – Simulacija gubitka paketa

Bez netem:

$ scp velikifajl.zip student@192.168.56.20:/home/student/
velikifajl.zip   100%   50MB   45.2MB/s   00:01

tcp.analysis.retransmission → 0 rezultata (od ukupno ~850 paketa)

Sa sudo tc qdisc add dev enp0s3 root netem loss 15%:

$ scp velikifajl.zip student@192.168.56.20:/home/student/
velikifajl.zip   100%   50MB   2.1MB/s   00:24

tcp.analysis.retransmission → 187 rezultata (od ukupno ~2.400 paketa, zbog retransmisija)

Objašnjenje: Sa 15% veštački unetog gubitka paketa, brzina prenosa je pala sa ~45MB/s na ~2MB/s, a broj retransmisija je skočio sa 0 na 187 — direktna, merljiva potvrda da gubitak paketa drastično usporava TCP prenos, jer TCP mora ponovo da šalje svaki izgubljeni segment i pritom smanjuje veličinu prozora (congestion window) kao odgovor na percipirano zagušenje.

Uklanjanje simulacije:

$ sudo tc qdisc del dev enp0s3 root netem
$ tc qdisc show dev enp0s3
qdisc noqueue 0: root refcnt 2

Korak 7 – Statistics

Conversations: Par (Host računar ↔ LINUX1) pokazuje najveći broj bajtova, odgovarajući SCP prenosu.

I/O Graph: Grafikon pokazuje visok, stabilan protok tokom prenosa bez netem, i isprekidan, značajno niži protok sa vidljivim „zupčastim" padovima tokom perioda sa aktivnom netem simulacijom — vizuelna potvrda uticaja gubitka paketa na protok.

Korak 8 – Dijagnostička vežba

Prateći redosled iz Teme 15 na snimku bez netem simulacije (čist pristup portalu):

I/O Graph — stabilan, bez anomalija.
tcp.analysis.retransmission — 0 ili zanemarljivo malo rezultata.
dns — brza rezolucija.
tcp.flags.syn == 1 — SYN-ACK stiže odmah.
Follow HTTP Stream — ako i pored svega navedenog vreme između GET zahteva i prvog bajta HTTP odgovora i dalje traje sekundama, to izoluje problem na samu aplikaciju (serversku obradu zahteva), ne na mrežu.

Objašnjenje: Ako su koraci 1-4 svi „čisti" (bez anomalija), a Follow HTTP Stream i dalje pokazuje sporo generisanje odgovora, dokazano je da mreža nije uzrok — sledeći korak istrage bi bio na serverskoj strani (nginx konfiguracija, backend aplikacija, baza podataka), ne dalja mrežna dijagnostika. Ovo je upravo razlika između scenarija iz Koraka 6 (mreža jasno uzrok, potvrđeno retransmisijama) i ovog scenarija (mreža isključena kao uzrok, sumnja pada na aplikaciju).

Rešenje dodatnog izazova

netem parametar	Retransmisije	Trajanje prenosa
bez netem	0	1s
loss 5%	~40	4s
loss 30%	~520	90s
delay 200ms	0-2 (zanemarljivo)	~3s (sporije zbog RTT-a, ali bez retransmisija)

Objašnjenje: loss direktno uzrokuje retransmisije jer paketi stvarno nestaju i moraju se ponovo poslati. delay sam po sebi (bez gubitka) ne uzrokuje značajne retransmisije — TCP i dalje prima sve pakete, samo kasnije; retransmisija bi nastala tek ako je kašnjenje toliko veliko da TCP retransmission timer (RTO) istekne pre nego što ACK stigne, što je mnogo ređi scenario od direktnog gubitka paketa. Ovo potvrđuje razliku između latencije i packet loss-a iz Modula 15 — oba degradiraju performanse, ali kroz različite mehanizme, i Wireshark jasno pokazuje tu razliku kroz prisustvo (ili odsustvo) retransmisija.

← PrethodnoPraktični primeri Sledeće →Zadaci za samostalan rad