Ne propunem analizăm antetul IP al pachetelor ce sunt generate de stațiile red, green și blue și au ca destinație o rețea din Internet. Pentru acest lucru vom folosi utilitarul de captură tcpdump.

Pe stația red porniți comanda ping către 8.8.8.8.:

root@red:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=127 time=42.0 ms
[...]

Pentru a urmări traficul, pe stația host rulați comanda

root@host:~# tcpdump -n -i eth0 ip dst 8.8.8.8
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:59:20.976707 IP host.local > google-public-dns-a.google.com: ICMP echo request, id 625, seq 6, length 64
12:59:21.977708 IP host.local > google-public-dns-a.google.com: ICMP echo request, id 625, seq 7, length 64

Observați că adresa IP sursă este host.local chiar dacă stația red este cea care execută comanda ping și generează pachetele de tip ICMP echo request.

Porniți tcpdump pe interfața veth-red în loc de eth0:

0 packets dropped by kernel
root@host:~# tcpdump -i veth-red dst 8.8.8.8
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on veth-red, link-type EN10MB (Ethernet), capture size 65535 bytes
13:01:12.557692 IP red > google-public-dns-a.google.com: ICMP echo request, id 626, seq 6, length 64
13:01:13.559726 IP red > google-public-dns-a.google.com: ICMP echo request, id 626, seq 7, length 64

Observați că pe interfața veth-red adresa IP sursă este cea a lui red. Motivul este reprezentat de faptul că pachetele ce intră pe intefața veth-red sunt capturate înainte de rutare, iar procesul NAT este aplicat după rutare (vezi 01. [15p] Observare porturi deschise pe o stație.

Repetați testele de mai sus pentru stația green.