/ tất cả bài học → CHẶNG 01 · Networking ( CCNA )

Bài 02

IP, MAC, Packet — 3 khái niệm nền tảng mà ai cũng nhầm

04 tháng 5, 2026 · 30 phút đọc

Bài 02 — IP, MAC, Packet — 3 khái niệm nền tảng mà ai cũng nhầm

Chặng 01 — Networking | Bài 02 | Thời lượng: 60–90 phút

Tiền đề: Đã setup môi trường lab (Bài 01). Biết mở terminal Linux.

Phần 1 — Tại sao bài này quan trọng với DevOps?

Có ba từ mà gần như mọi tài liệu network đều dùng: IP, MAC, packet. Người mới vào nghề thường tưởng đã hiểu — vì ai cũng nghe rồi. Nhưng khi gặp câu hỏi: "Vì sao container có IP nhưng không có MAC riêng?", "Vì sao máy bạn có 2 IP cùng lúc?", "tcpdump show ra packet — đó là frame hay packet thật?" — đa số đứng hình.

Ba khái niệm này giống như chữ cái A, B, C — chưa thuộc thì không đọc được chữ. Mọi bài sau (subnetting, switch, router, TCP, container network) đều giả định bạn phân biệt được. Nhầm lẫn ở đây sẽ kéo theo nhầm lẫn ở mọi nơi.

Mình sẽ không dạy theo kiểu định nghĩa khô — mà sẽ làm rõ vì sao cần cả ba, mỗi cái giải quyết vấn đề gì khác nhau, và chúng chồng lên nhau như thế nào trong một packet thật mà bạn bắt được bằng tcpdump.

Phần 2 — Bản chất vấn đề

Để hiểu vì sao mạng cần đến cả ba khái niệm này, hãy nghĩ về vấn đề thật:

Bạn đứng ở Hà Nội, muốn gửi một bức thư cho người ở Sài Gòn. Có hai câu hỏi cần trả lời:

Câu 1: Người nhận là ai? → Cần một địa chỉ.
Câu 2: Đi qua những ai để tới? → Cần biết người trung gian (bưu điện, hãng vận chuyển).

Và một câu hỏi thứ ba ít người nghĩ tới:

Câu 3: Làm sao biết kiện hàng cụ thể này là của ai khi tới? → Cần một mã định danh duy nhất.

Mạng máy tính đối mặt với chính ba câu hỏi đó:

IP trả lời câu 1 — "máy nào, ở đâu trong mạng".
MAC trả lời câu 3 — "card mạng nào cụ thể là người nhận trong cùng một LAN".
Packet là kiện hàng đó — đơn vị vận chuyển.

Ẩn dụ rõ hơn:

MAC address  ≈ Số CMND của card mạng
              (Cố định khi sản xuất, in vào phần cứng)
              
IP address   ≈ Địa chỉ nhà của bạn
              (Thay đổi khi chuyển nhà — bạn ở quán cà phê thì IP khác,
               về nhà thì IP khác)
              
Packet       ≈ Bức thư có phong bì
              (Bên ngoài ghi địa chỉ — bên trong là nội dung)

Người nhận có thể chuyển nhà (IP đổi), nhưng số CMND của họ (MAC) không đổi. Khi bạn gửi thư đến địa chỉ nhà, bưu tá tới nhà → kiểm tra CMND → đúng người mới giao.

Trong mạng cũng vậy: packet đi qua nhiều router (mỗi router chỉ cần đọc IP để biết next hop), nhưng đến chặng cuối — trong cùng một LAN — switch dùng MAC để giao cho đúng card mạng vật lý.

Hiểu được ẩn dụ này, bạn đã hiểu 80% bài này. Phần dưới đi vào kỹ thuật.

Phần 3 — Đi sâu vào kỹ thuật

3.1 IP Address — địa chỉ logic

IPv4 là phiên bản đang dùng phổ biến. Cấu trúc: 32 bit, chia thành 4 octet (8-bit), viết dạng 192.168.1.10.

   192      .    168      .     1       .     10
11000000      10101000      00000001      00001010
└─8 bit──┘  └──8 bit──┘  └──8 bit──┘  └──8 bit──┘

32 bit cho ra 2³² ≈ 4.3 tỷ địa chỉ. Nghe nhiều, nhưng không đủ cho 8 tỷ người + IoT + cloud servers. Đó là lý do có NAT (Bài 05) và IPv6.

IPv6 dùng 128 bit, viết dạng hex: 2001:0db8:85a3::8a2e:0370:7334. Số lượng địa chỉ là 2¹²⁸ — đủ để gán mỗi hạt cát trên Trái Đất một IP. DevOps cần biết IPv6 tồn tại và đọc được dạng viết của nó, nhưng đa số production hiện vẫn IPv4 — nên khoá này tập trung IPv4.

Quan trọng: Một máy có thể có nhiều IP cùng lúc. Mỗi network interface mang một IP (hoặc nhiều IP). Ví dụ:

lo (loopback)          → 127.0.0.1
eth0 (cáp/wifi)        → 192.168.1.10
docker0 (Docker bridge)→ 172.17.0.1

Đây là điều bạn intern H trong câu chuyện ở Bài 01 không hiểu — 127.0.0.1 và 192.168.1.10 là hai IP khác nhau trên cùng một máy. Bind app vào IP nào ảnh hưởng việc ai connect được tới app.

Đặc biệt: 0.0.0.0 không phải một IP cụ thể — nó là cách nói "bind vào TẤT CẢ interface". Bind 0.0.0.0:3000 nghĩa là app sẵn sàng nhận connection từ mọi nguồn — từ chính máy này, từ máy khác trong LAN, từ Internet (nếu có public IP).

3.2 MAC Address — định danh phần cứng

MAC (Media Access Control) address gắn với card mạng vật lý. Cấu trúc: 48 bit, viết dạng aa:bb:cc:11:22:33.

  aa : bb : cc :  11 : 22 : 33
└──── 24 bit ────┘└──── 24 bit ────┘
   OUI (vendor)      Serial (unique)

24 bit đầu là OUI (Organizationally Unique Identifier) — định danh hãng sản xuất. Ví dụ 00:0c:29:xx:xx:xx là VMware, 00:50:56:xx:xx:xx cũng VMware, b8:27:eb:xx:xx:xx là Raspberry Pi. Tra OUI tại https://standards-oui.ieee.org.

24 bit còn lại do hãng tự gán cho từng card. Lý thuyết: mỗi MAC trên thế giới là duy nhất.

Thực tế: MAC có thể đổi được bằng phần mềm (gọi là MAC spoofing — ip link set dev eth0 address aa:bb:cc:dd:ee:ff). Nhưng nó không đổi vĩnh viễn — reboot là về mặc định in trong firmware.

Lưu ý cho DevOps:

VM (VirtualBox, KVM, ESXi) tự sinh MAC giả khi tạo interface ảo.
Container Linux mặc định có MAC trên interface veth (cặp veth là kỹ thuật của Bài 21). MAC này được sinh ngẫu nhiên mỗi lần container start.
Cloud VM có MAC do hypervisor cấp.

Vậy khi nào DevOps cần quan tâm MAC? Hai trường hợp chính:

Debug Layer 2: ARP table sai, MAC flapping trên switch, VM/container không nhận được packet.
Security: Một số nơi dùng MAC filtering trên switch để chặn thiết bị lạ. Hết.

3.3 Packet — đơn vị vận chuyển

Packet không phải một thứ "đơn lẻ" — nó là dữ liệu được đóng gói nhiều lớp. Và mỗi tầng OSI gọi nó bằng một tên khác nhau:

Tầng              Tên gọi            Header gắn thêm
────────────────────────────────────────────────────────────
Application       Data / Message     (không có header network)
Transport (L4)    Segment (TCP)      TCP header (port nguồn/đích, seq, ack...)
                  Datagram (UDP)     UDP header
Network (L3)      Packet             IP header (IP nguồn/đích, TTL, protocol...)
Data Link (L2)    Frame              Ethernet header (MAC nguồn/đích)
Physical (L1)     Bits / Signal      (không header — tín hiệu thật)

Đa số người gọi chung "packet" cho mọi cái — và trong cuộc nói chuyện hằng ngày, OK. Nhưng khi đọc tài liệu chính xác hoặc nghe senior nói "frame này có MAC sai" — họ đang nói tầng 2 cụ thể.

Cấu trúc một IP packet đơn giản:

┌─────────────────────────────────────────────────────────┐
│  IP HEADER (20–60 bytes)                                │
│  ├─ Version (IPv4/IPv6)                                 │
│  ├─ Total length                                        │
│  ├─ TTL (Time To Live — bài 07)                         │
│  ├─ Protocol (TCP=6, UDP=17, ICMP=1)                    │
│  ├─ Source IP   (32 bit)                                │
│  ├─ Destination IP (32 bit)                             │
│  └─ ... (option, checksum, ...)                         │
├─────────────────────────────────────────────────────────┤
│  PAYLOAD                                                │
│  (TCP segment / UDP datagram / ICMP message ...)        │
│                                                         │
└─────────────────────────────────────────────────────────┘

Khi tcpdump hay Wireshark show ra một dòng, nó đã bóc Ethernet frame ra để bạn nhìn thấy IP header bên trong. Nếu tcpdump -e thì nó show cả MAC nữa.

3.4 Liên hệ ba khái niệm

Khi laptop bạn gửi request curl https://google.com:

App tạo HTTP request (data) → đóng vào TCP segment (port nguồn 54321 → port đích 443).
TCP segment đóng vào IP packet — IP nguồn = IP của laptop (192.168.1.10), IP đích = IP của Google (142.250.x.x).
IP packet đóng vào Ethernet frame — MAC nguồn = MAC của card wifi laptop, MAC đích = MAC của router gateway (không phải MAC của Google!).

Tại sao MAC đích là router chứ không phải Google? Vì Google ở rất xa — laptop bạn không biết MAC của Google, và không cần biết. Laptop chỉ cần đưa packet cho router gateway, router lo phần còn lại.

Khi packet qua mỗi router:

IP source/destination KHÔNG đổi (vẫn là laptop ↔ Google).
MAC source/destination thay đổi ở mỗi hop (router viết lại MAC để giao cho thiết bị tiếp theo).

Đây là điểm mấu chốt: IP định danh logic xuyên đầu cuối, MAC chỉ có ý nghĩa trong từng đoạn LAN.

Phần 4 — Câu chuyện hiện trường

💡 Một lần ở production...

Tháng 11/2022, công ty mình mở văn phòng mới ở Đà Nẵng. Team IT bên đó setup một router/switch mới, cấu hình DHCP để cấp IP tự động cho máy nhân viên.

Tuần đầu chạy ổn. Đầu tuần thứ hai, bắt đầu có khiếu nại: "Mạng văn phòng chậm như rùa, lúc được lúc không, lúc thì share file LAN không thấy nhau."

Mình bay ra Đà Nẵng. Ngồi trong phòng họp, mở laptop:
ip addr show
Thấy IP 192.168.10.45. Bình thường. ping 8.8.8.8 → loss 30%. Bất thường.

Mở terminal khác:
# Bắt arp packet để xem có gì lạ trên LAN
sudo tcpdump -i wlan0 -n arp
Trong vòng 1 phút, log đổ ra một dòng làm mình giật mình:
14:23:11.127 ARP, Reply 192.168.10.1 is-at 00:0c:29:aa:bb:cc
14:23:11.589 ARP, Reply 192.168.10.1 is-at 5c:5e:ab:11:22:33
Hai MAC khác nhau cùng claim là 192.168.10.1 — IP của default gateway. ARP "battle" — máy của mình lúc thì gửi packet ra MAC này, lúc thì MAC kia. Một trong hai không phải gateway thật → packet đi vào hư không → loss 30%.

Mình tra OUI: 00:0c:29 là VMware, 5c:5e:ab là Cisco (router thật). Vậy có một con VM nào đó đang giả làm gateway.

Lần ngược tới phòng server, đúng là một server cũ chạy VMware, có một VM được technician đặt static IP 192.168.10.1 từ thời chưa có router (để test cái gì đó). Ai đó quên gỡ. DHCP của router mới sau này lại đặt gateway là .1 — IP conflict.

Fix: gỡ static IP đó khỏi VM. Mạng ổn ngay sau 5 phút (đợi ARP cache trên các máy hết hạn).

Bài học rút ra:

IP conflict là một class lỗi vẫn rất hay gặp trong môi trường có cả static IP và DHCP. Network không bao giờ "tự phát hiện" — nó đơn giản là loop bất ổn.

arp là vũ khí debug Layer 2 — không có nó, mình ngồi đoán cả ngày không ra. Lệnh đầy đủ: ip neigh (modern) hoặc arp -n (legacy).

Tra OUI giúp nhanh chóng: chỉ cần 24 bit đầu của MAC, biết được vendor → biết loại thiết bị → đoán được nguồn của vấn đề.

Đừng đặt static IP trùng với DHCP pool. Đây là lỗi kinh điển — và bài 14 (DHCP) sẽ nói rõ cách phòng tránh.

Phần 5 — Lab thực hành: Khám phá IP, MAC, Packet trên máy thật

Mục tiêu: Sau lab này bạn sẽ tự tay xem được IP và MAC trên máy mình, quan sát ARP hoạt động, bắt được một packet và phân tích được header IP/MAC trong đó.

Môi trường: VM Ubuntu đã setup ở Bài 01.

Các bước

Bước 1 — Xem các interface và IP

# Liệt kê tất cả network interface và IP của chúng
ip addr show

Bạn sẽ thấy ít nhất 2 interface. Ví dụ:

1: lo: <LOOPBACK,UP,LOWER_UP> ...
    inet 127.0.0.1/8 scope host lo
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> ...
    link/ether 08:00:27:aa:bb:cc brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global ...

Đọc hiểu:

lo là loopback — IP 127.0.0.1, MAC không có (vì là interface ảo nội bộ).
enp0s3 là card mạng ảo (do VirtualBox tạo). MAC 08:00:27:... — 08:00:27 là OUI của Oracle/VirtualBox.

Bước 2 — Xác định gateway và xem ARP table

# Xem default gateway - IP nào được dùng để ra Internet
ip route show default

# Xem ARP table - MAC tương ứng với IP nào trong cùng LAN
ip neigh show

Bạn sẽ thấy default gateway, ví dụ 10.0.2.2. Trong ip neigh bạn có thể thấy hoặc chưa thấy MAC của gateway — phụ thuộc đã có liên lạc gần đây hay không.

Bước 3 — Trigger ARP bằng cách ping

# Xoá ARP cache để chắc chắn ARP request được gửi mới
sudo ip neigh flush all

# Ping gateway 1 lần để máy phải hỏi MAC của gateway
ping -c 1 10.0.2.2  # thay bằng gateway thật của bạn

# Xem lại ARP table - bây giờ phải thấy MAC của gateway
ip neigh show

Bạn sẽ thấy dòng đại loại như:

10.0.2.2 dev enp0s3 lladdr 52:54:00:12:35:02 REACHABLE

Tức là máy bạn vừa hỏi "ai có IP 10.0.2.2?", và một thiết bị trả lời "tôi, MAC tôi là 52:54:00:12:35:02". Đó là ARP — bài học sống.

Bước 4 — Bắt packet và xem MAC + IP cùng lúc

Mở 2 terminal trên VM (hoặc dùng tmux cho gọn).

Terminal 1 — chạy tcpdump với cờ -e (show MAC):

# -i: interface, -n: không resolve DNS, -e: show Ethernet header (có MAC)
# host: chỉ bắt traffic đi/về 8.8.8.8
sudo tcpdump -i any -n -e host 8.8.8.8

Terminal 2 — gửi 3 ping:

ping -c 3 8.8.8.8

Quay lại Terminal 1 quan sát. Bạn sẽ thấy đại loại:

14:32:01.123 08:00:27:aa:bb:cc > 52:54:00:12:35:02, ethertype IPv4,
             10.0.2.15 > 8.8.8.8: ICMP echo request, ...
14:32:01.234 52:54:00:12:35:02 > 08:00:27:aa:bb:cc, ethertype IPv4,
             8.8.8.8 > 10.0.2.15: ICMP echo reply, ...

Đọc kỹ dòng đầu tiên:

MAC nguồn 08:00:27:aa:bb:cc = MAC của VM bạn (từ Bước 1).
MAC đích 52:54:00:12:35:02 = MAC của gateway (từ Bước 3) — KHÔNG phải MAC của Google 8.8.8.8.
IP nguồn 10.0.2.15 = IP của VM bạn.
IP đích 8.8.8.8 = IP của Google DNS.

Đây chính là điều mình nói ở Phần 3.4: IP đi xuyên đầu cuối, MAC chỉ tới hop kế tiếp.

Bước 5 — Quan sát loopback (không có MAC)

# Bắt traffic trên loopback - xem có MAC không
sudo tcpdump -i lo -n -e -c 5 &
# Gửi traffic qua loopback
ping -c 3 127.0.0.1

Bạn sẽ thấy MAC field hiển thị toàn 00:00:00:00:00:00 hoặc bị skip — vì lo không có Ethernet header thật, là interface ảo.

Kết quả mong đợi:

Bạn xác định được IP và MAC của VM mình.
Bạn quan sát được ARP request/reply qua ip neigh.
Bạn thấy được MAC đích trong packet là MAC của gateway, không phải IP đích cuối cùng.

Self-check:

Nếu bạn đổi MAC bằng sudo ip link set dev enp0s3 address aa:aa:aa:bb:bb:bb, sau đó ping ra Google, traffic vẫn đi được không? Vì sao? (Gợi ý: gateway gửi reply về theo MAC nào?)
Trong output Bước 4, vì sao MAC đích không phải MAC của 8.8.8.8?
Một container Docker chạy trên máy bạn — nó có IP riêng. Container có MAC riêng không? (Sẽ trả lời rõ ở chặng Container — bạn thử đoán trước.)

Phần 6 — Best practices

1. Luôn biết các IP của máy mình

WHY: Sự cố network thường do bind sai IP hoặc nhầm interface. Biết rõ máy có những IP gì giảm 50% case nhầm lẫn.

HOW: Trước khi run service, chạy ip addr show xem có những interface nào. Chú ý phân biệt 127.0.0.1, IP LAN, và IP của các bridge (Docker, VM).

2. Bind đúng IP cho service

WHY: Bind 127.0.0.1 thì chỉ gọi được từ chính máy đó. Bind 0.0.0.0 thì mọi nơi gọi được — tiện nhưng có rủi ro security. Chọn đúng theo yêu cầu.

HOW: Dev local một mình dùng 127.0.0.1. Container/server muốn được gọi từ ngoài bind 0.0.0.0. Production có nhiều interface (public + private) cân nhắc bind cụ thể IP private.

3. Đọc OUI để đoán nguồn của thiết bị lạ

WHY: Khi debug, thấy MAC lạ trong ARP table mà không biết của ai → tra OUI nhanh.

HOW: Lấy 24 bit đầu của MAC, tra ở https://maclookup.app hoặc https://standards-oui.ieee.org. VMware là 00:0c:29, 00:50:56. VirtualBox là 08:00:27. Cisco có nhiều OUI.

4. Khi nói về "packet", chú ý đang nói tầng nào

WHY: Senior nói "frame" và "packet" có nghĩa khác nhau. Đáp lại sai = lộ là chưa hiểu.

HOW: Frame = L2 (có MAC). Packet = L3 (có IP). Segment = TCP. Datagram = UDP. Khi đọc tcpdump, mặc định nó show packet (L3), trừ khi -e để show frame (L2).

5. Đừng tin "MAC là duy nhất" tuyệt đối

WHY: MAC có thể spoof. Cloud VM tái tạo có thể trùng MAC. Container interface mỗi lần start sinh MAC mới.

HOW: Dùng MAC để debug, đừng dùng làm cơ chế security duy nhất. Auth nên dựa vào key, certificate, không dựa MAC.

Phần 7 — Pitfalls — Lỗi thường gặp

Pitfall 1: Nhầm 127.0.0.1 và 0.0.0.0

Triệu chứng: App chạy trên máy A, chạy curl http://machine-A-ip:port từ máy B → connection refused.
Nguyên nhân: App bind 127.0.0.1 thay vì 0.0.0.0. 127.0.0.1 chỉ accept loopback traffic từ chính máy A.
Phòng tránh: Khi expose service ra ngoài, luôn bind 0.0.0.0. Dùng ss -tlnp để verify đã bind đúng.

Pitfall 2: Tưởng mỗi máy chỉ có 1 IP

Triệu chứng: Config app gọi tới IP của host theo 192.168.x.x, từ trong container không gọi được.
Nguyên nhân: Trong container, IP 192.168.x.x không tồn tại. Container thấy host qua bridge IP (thường 172.17.0.1 cho Docker default).
Phòng tránh: Hiểu rõ máy có nhiều interface. Dùng host.docker.internal hoặc IP của bridge khi container muốn gọi host.

Pitfall 3: Cố đọc IP của remote bằng MAC

Triệu chứng: "Em muốn biết MAC của server Google 8.8.8.8."
Nguyên nhân: Hiểu sai bản chất MAC. MAC chỉ có ý nghĩa trong cùng LAN. Bạn chỉ thấy được MAC của default gateway, không bao giờ thấy MAC của server xa.
Phòng tránh: Nhớ nguyên tắc: MAC = ý nghĩa local, IP = ý nghĩa global.

Pitfall 4: Lẫn lộn ip neigh và arp -n

Triệu chứng: arp -n báo "command not found" trên Ubuntu mới.
Nguyên nhân: arp (từ package net-tools) đã legacy. Modern Linux dùng ip neigh (từ package iproute2).
Phòng tránh: Ưu tiên dùng ip family (ip addr, ip route, ip neigh, ip link). Cài net-tools chỉ khi cần backward compat.

Pitfall 5: Hiểu sai về ARP cache

Triệu chứng: Đổi IP của một máy trong LAN, máy khác vẫn không liên lạc được trong vài phút.
Nguyên nhân: ARP cache trên các máy chưa hết hạn — vẫn nhớ MAC cũ tương ứng với IP mới (không khớp).
Phòng tránh: Khi đổi IP/MAC, có thể sudo ip neigh flush all để xoá cache ngay. Trong production, ARP timeout mặc định khoảng 60 giây — chờ là được.

Phần 8 — Liên kết với DevOps thực tế

Bài 03 (TCP/IP & OSI): IP và MAC chính là Layer 3 và Layer 2. Bài 03 đào sâu vai trò của từng tầng.
Bài 06 (Switch): Switch hoạt động bằng cách học MAC table — kế thừa thẳng kiến thức MAC bài này.
Chặng 04 (Container): Mỗi container có network namespace riêng, có IP riêng, có MAC riêng (trên veth). Hiểu IP/MAC bài này là tiền đề bắt buộc.
Chặng 05 (Kubernetes): Pod CIDR, Service CIDR, Cluster IP — toàn bộ dựa trên cách quy hoạch IP. Bài 04 (Subnetting) tới đây sẽ cùng nhau cốt lõi.
Cloud: AWS/GCP VPC subnet, ENI (Elastic Network Interface) đều liên quan IP và MAC. Một số case bug khi VM bị thay ENI → MAC đổi → license/firewall dựa MAC bị fail.

Phần 9 — Dùng AI thông minh khi học phần này

Prompt tốt 1 — Hỏi để debug:

Tao có VM Ubuntu, output `ip addr show` như sau: [paste].
Output `ip route show` như sau: [paste].
Tao chạy `ping 8.8.8.8` thì 100% packet loss.
Hãy phân tích từng bước packet đi qua đâu, nguyên nhân khả dĩ ở đâu.

Prompt tốt 2 — Đào sâu khái niệm:

Khi container A (IP 172.17.0.2) ping container B (IP 172.17.0.3) trên cùng máy host,
packet đi qua MAC nào, IP source/dest là gì ở mỗi bước?
Vẽ ra ASCII diagram.

Cảnh báo:

AI có thể nói sai về OUI — hỏi "OUI của VMware là gì" có khi ra số khác nhau qua các lần. Tra trực tiếp https://maclookup.app chính xác hơn.
AI có thể trộn lẫn IPv4/IPv6 trong câu trả lời nếu không nói rõ. Luôn ghi rõ "IPv4" trong prompt.

Phần 10 — Tóm tắt: 3 điều cần khắc cốt

MAC là số CMND của card mạng (cố định, local). IP là địa chỉ logic (đổi được, global). Packet là kiện hàng — bên trong có nhiều lớp header. Ba thứ này phối hợp để dữ liệu đi từ A đến B.
Một máy có nhiều IP, nhiều interface. Bind đúng IP rất quan trọng. 127.0.0.1 và 0.0.0.0 không thay thế nhau.
MAC nguồn/đích thay đổi ở mỗi hop, IP nguồn/đích KHÔNG đổi xuyên đầu cuối. Nguyên tắc này dùng để debug mọi sự cố routing và Layer 2.

Phần 11 — Câu hỏi tự kiểm tra

Một packet đi từ laptop của bạn (IP 192.168.1.10) tới google.com (IP 142.250.x.x), qua một router gateway (IP 192.168.1.1). Tại đoạn từ laptop tới router, IP source/destination là gì? MAC source/destination là gì?
Bạn chạy ip addr show trên VM thấy 3 interface: lo, enp0s3, docker0. Mỗi interface đại diện cho cái gì? Interface nào không có MAC?
Lệnh ip neigh show cho thấy điều gì? Nội dung của nó được sinh ra như thế nào?
Trong câu chuyện ở Phần 4, mình tra OUI và thấy 00:0c:29 là VMware. Nếu MAC giả mạo là aa:bb:cc:11:22:33 (OUI ngẫu nhiên không có trong cơ sở dữ liệu), bạn có cách nào khác để lần ra nguồn không?
Bind app ở 0.0.0.0:8080 so với 127.0.0.1:8080 — sự khác biệt là gì? Trong trường hợp nào nên dùng 0.0.0.0, trường hợp nào nên dùng 127.0.0.1?
Một packet TCP 1500-byte đi qua mạng. Tại Layer 2 (Ethernet) gọi nó là gì? Layer 3 (IP) gọi là gì? Layer 4 (TCP) gọi là gì?
Hai máy A và B đặt cùng static IP 192.168.1.50 trong LAN. Triệu chứng sẽ thế nào? Bạn dùng lệnh gì trên máy thứ ba để phát hiện ra?

Bài tiếp theo: Bài 03 — TCP/IP và mô hình OSI ✅ (đã có).