BlogTài Liệu Tri Thức: Networking Cơ Bản
Bố cục bài viết
Trang này
Ngày tạo
31/08/2026
Cập nhật
Lượt xem
6
Đọc
16m
Tài Liệu Tri Thức: Networking Cơ Bản (Roadmap Phần 1.1)
Nội dung học chi tiết cho Phần 1.1 của roadmap — 4 chủ đề: Mô hình OSI/TCP-IP, IPv4/Subnetting/CIDR, Routing cơ bản, Switching. Mỗi chủ đề có lý thuyết NGẮN + một ví dụ trọng tâm được giải đến mức byte/số cụ thể, liên hệ trực tiếp tới case DEA-HSS và các lab sắp tới (GĐ1-2).
1. Mô Hình OSI 7 Layer & TCP/IP 4 Layer
1.1 — OSI 7 Layer: Mỗi Layer Làm Gì
| # | Layer (OSI) | Vai trò | Đơn vị dữ liệu |
|---|---|---|---|
| 7 | Application | Giao thức người dùng cuối — định nghĩa Ý NGHĨA dữ liệu | Data |
| 6 | Presentation | Định dạng/encode/mã hóa dữ liệu (ASN.1, TLS thường xếp đây hoặc layer 4) | Data |
| 5 | Session | Thiết lập/duy trì/kết thúc “phiên” logic giữa 2 bên | Data |
| 4 | Transport | Truyền end-to-end, có thể đảm bảo reliable/ordered | Segment (TCP) / Datagram (UDP) / Packet (SCTP) |
| 3 | Network | Địa chỉ logic (IP) + routing giữa các mạng | Packet |
| 2 | Data Link | Địa chỉ vật lý (MAC) + framing trong 1 mạng cục bộ | Frame |
| 1 | Physical | Bit lên đường truyền (điện/quang/radio) | Bit |
1.2 — TCP/IP 4 Layer: Gộp Lại Thực Dụng Hơn
| TCP/IP Layer | Gộp từ OSI | Ví dụ |
|---|---|---|
| 4 — Application | OSI 5+6+7 | HTTP, DNS, Diameter, SIP |
| 3 — Transport | OSI 4 | TCP, UDP, SCTP |
| 2 — Internet | OSI 3 | IP, ICMP |
| 1 — Link (Network Access) | OSI 1+2 | Ethernet, Wi-Fi, ARP* |
*ARP là trường hợp đặc biệt — về chức năng nó “dịch” IP (layer 3) sang MAC (layer 2), nên thường được gọi là “layer 2.5”, không nằm gọn trong 1 layer nào.
1.3 — Bảng Map: Giao Thức Telecom Vào 2 Mô Hình
| Giao thức | OSI Layer | TCP/IP Layer | Transport bên dưới |
|---|---|---|---|
| Diameter | 7 | 4 (App) | SCTP hoặc TCP |
| SIP | 7 | 4 (App) | UDP/TCP/TLS |
| GTP-C / GTP-U | 7* | 4 (App) | UDP |
| MAP (qua SIGTRAN) | 7 | 4 (App) | SCCP → M3UA → SCTP |
| SCTP | 4 | 3 (Transport) | IP |
| IP | 3 | 2 (Internet) | Ethernet |
| Ethernet | 1-2 | 1 (Link) | — |
*GTP-U về chức năng “đóng gói” lại một packet IP khác bên trong — về OSI nó được xem là application-layer protocol nhưng payload của nó lại là một packet IP hoàn chỉnh khác (tunneling) — đây là lý do GTP-U thường bị nhầm là “layer 3”.
Ghi chú SS7 truyền thống (không qua SIGTRAN): MTP1/MTP2/MTP3 map gần đúng với OSI 1/2/3; MAP/ISUP qua SCCP/TCAP nằm ở các layer trên nhưng SS7 KHÔNG được thiết kế theo OSI từ đầu nên việc map chỉ là tương đối. Với SIGTRAN (SCTP-based, đang dùng), bảng trên map khá sạch.
1.4 — VÍ DỤ TRỌNG TÂM: Trace 1 Bản Tin Diameter CER Qua Từng Layer
Đây CHÍNH XÁC là cách Wireshark hiển thị (Frame → Ethernet → IP → SCTP → DIAMETER, từ ngoài vào trong) — đi NGƯỢC (từ trong ra ngoài) là encapsulation khi GỬI, đi THUẬN (từ ngoài vào trong) là decapsulation khi NHẬN.
┌─────────────────────────────────────────────────────────────────┐
│ LAYER 7 — Diameter CER (20-byte header + AVPs) │
│ Version(1B) | Msg Length(3B) | Cmd Flags(1B) | Cmd Code(3B)=257 │
│ Application-ID(4B)=0 | Hop-by-Hop ID(4B) | End-to-End ID(4B) │
│ AVPs: Origin-Host, Origin-Realm, Host-IP-Address, Vendor-Id, │
│ Product-Name, Auth-Application-Id, ... │
└───────────────────────────┬────────────────────────────────────-┘
│ trở thành "User Data" của SCTP DATA chunk
▼
┌─────────────────────────────────────────────────────────────────┐
│ LAYER 4 — SCTP packet │
│ Common Header (12B): Src Port(2B) | Dst Port(2B)=3868 │
│ | Verification Tag(4B) | Checksum(4B) │
│ DATA Chunk Header (16B): Type=0 | Flags | Length | TSN(4B) │
│ | Stream ID(2B) | Stream Seq(2B) │
│ | Payload Protocol ID(4B)=46 (DIAMETER) │
│ → [Diameter CER từ Layer 7] │
└───────────────────────────┬────────────────────────────────────-┘
│ trở thành payload của IP packet
▼
┌─────────────────────────────────────────────────────────────────┐
│ LAYER 3 — IPv4 packet (20-byte header, không option) │
│ Version/IHL | ToS | Total Length(2B) | Identification(2B) │
│ Flags/Fragment Offset(2B) | TTL(1B) | Protocol(1B)=132 (SCTP) │
│ Header Checksum(2B) | Source IP(4B) | Destination IP(4B) │
│ → [SCTP packet từ Layer 4] │
└───────────────────────────┬────────────────────────────────────-┘
│ trở thành payload của Ethernet frame
▼
┌─────────────────────────────────────────────────────────────────┐
│ LAYER 1-2 — Ethernet frame │
│ Header (14B): Dest MAC(6B) | Src MAC(6B) | EtherType(2B)=0x0800 │
│ → [IP packet từ Layer 3] │
│ Trailer: FCS/CRC (4B) │
└─────────────────────────────────────────────────────────────────┘
│
▼
Bit lên cáp/cổng vật lý (Layer 1)
Hai số cần nhớ vì hay dùng để filter trong Wireshark/khi viết script (Phần 5.5):
- IP Protocol field = 132 khi payload là SCTP (
ip.proto == 132). - SCTP Payload Protocol Identifier = 46 khi payload là Diameter (
sctp.ppi == 46hoặc Wireshark tự nhận diện và hiển thị tầng DIAMETER ngay dưới SCTP).
Bài tập áp dụng ngay: mở pcap case DEA-HSS, click vào 1 frame chứa CER (nếu đã có) hoặc một SCTP DATA chunk bất kỳ, expand từng tầng trong panel “Packet Details” — đối chiếu từng giá trị (Total Length của IP, Verification Tag của SCTP, PPI=46…) với bảng trên. Nếu case hiện tại CHƯA có CER (đúng tình trạng hiện tại), thử với chunk COOKIE-ACK — vẫn đủ để thấy đầy đủ Layer 1-4, chỉ thiếu phần Layer 7 (đúng là root cause của case).
2. IPv4 Addressing, Subnetting, CIDR
2.1 — Định Dạng IPv4
32 bit, viết dưới dạng 4 octet (8 bit) thập phân phân tách bằng dấu chấm. Ví dụ 192.168.10.77:
192 . 168 . 10 . 77
11000000 . 10101000 . 00001010 . 01001101
2.2 — Subnet Mask & CIDR
Subnet mask cũng là 32 bit: bit 1 = phần network, bit 0 = phần host. CIDR /N = N bit 1 đầu tiên.
| CIDR | Subnet mask | Tổng số địa chỉ (2^(32-N)) | Host khả dụng (-2) |
|---|---|---|---|
| /24 | 255.255.255.0 | 256 | 254 |
| /27 | 255.255.255.224 | 32 | 30 |
| /28 | 255.255.255.240 | 16 | 14 |
| /29 | 255.255.255.248 | 8 | 6 |
| /30 | 255.255.255.252 | 4 | 2 |
/30 đặc biệt quan trọng cho lab BGP (6.7) — 2 host khả dụng = ĐÚNG đủ cho 2 interface router ở 2 đầu một liên kết point-to-point.
2.3 — VÍ DỤ TRỌNG TÂM (1): Tính Network/Broadcast/Host Range Từ CIDR
Cho 192.168.10.77/27 — tính network address, broadcast address, range khả dụng.
Địa chỉ: 192.168.10.77 = 11000000.10101000.00001010.01001101
Mask /27: 11111111.11111111.11111111.11100000
└─ 27 bit 1, 5 bit 0
Bước 1 — Block size (số địa chỉ/subnet) = 2^(32-27) = 2^5 = 32
Bước 2 — Octet cuối (77) thuộc block nào? 77 ÷ 32 = 2 dư 13 → block bắt đầu từ 2×32 = 64
Bước 3 — Network address = 192.168.10.64
Bước 4 — Broadcast address = 64 + 32 - 1 = 95 → 192.168.10.95
Bước 5 — Range khả dụng = 192.168.10.65 → 192.168.10.94 (30 host)
Kiểm tra bằng AND/OR bit: 01001101 AND 11100000 = 01000000 (=64) ✓; 01000000 OR 00011111 = 01011111 (=95) ✓.
2.4 — VLSM: Chia Một Block Lớn Thành Nhiều Subnet Nhỏ
VLSM (Variable Length Subnet Mask) = chia một block lớn thành các block NHỎ HƠN với CIDR khác nhau, theo nhu cầu thực tế từng phần — không chia đều cứng. Ví dụ chia 10.10.0.0/22 (1024 địa chỉ):
10.10.0.0/22
├── 10.10.0.0/24 (256 addr) — lab A (cần nhiều host)
├── 10.10.1.0/28 (16 addr) — lab B (chỉ 2-3 node)
├── 10.10.1.16/28 (16 addr) — lab C
└── ... còn dư phần lớn /22 cho mở rộng
2.5 — Private IP Ranges (RFC 1918)
| Block | Range | Số địa chỉ |
|---|---|---|
| 10.0.0.0/8 | 10.0.0.0 – 10.255.255.255 | ~16.7 triệu |
| 172.16.0.0/12 | 172.16.0.0 – 172.31.255.255 | ~1 triệu |
| 192.168.0.0/16 | 192.168.0.0 – 192.168.255.255 | 65,536 |
Với SỐ LƯỢNG lab dự kiến (Diameter, SS7, GTP, 5G SBA, SIP, BGP…), 10.0.0.0/8 cho nhiều “không gian” nhất — nên dùng 10.x.x.x làm base, chia mỗi nhóm lab một block riêng theo VLSM (2.4).
2.6 — VÍ DỤ TRỌNG TÂM (2): Sơ Đồ Địa Chỉ Cho Toàn Bộ Lab Trong Roadmap
| Lab (tham chiếu roadmap) | Block đề xuất | Host khả dụng | Ghi chú |
|---|---|---|---|
| GĐ1 — FreeDiameter 2-node (5.4) | 10.10.1.0/28 | 14 | DEA=10.10.1.1, HSS giả lập=10.10.1.2 |
| GĐ2 — SS7/Osmocom (6.2) | 10.10.2.0/28 | 14 | |
| GĐ2 — GTP/Open5GS EPC+5GC (6.4, 6.8) | 10.10.3.0/24 | 254 | Open5GS cần nhiều subnet con (UE pool, N2/N3/N4) — /24 đủ rộng |
| GĐ2 — SIP/OpenSIPS (6.5) | 10.10.4.0/28 | 14 | |
| GĐ2 — BGP/RPKI containerlab (6.7) | 10.20.0.0/22 | — | Chia /30 cho link point-to-point + /32 loopback, xem bảng dưới |
Chi tiết lab BGP (6.7, topology 3 AS hình tam giác) — đây là nơi /30 (2.2) và loopback /32 (thường dùng làm BGP router-id, ổn định hơn IP của interface vật lý) cùng xuất hiện:
| Link | Subnet | IP đầu A | IP đầu B |
|---|---|---|---|
| AS1 ↔ AS2 | 10.20.0.0/30 | 10.20.0.1 | 10.20.0.2 |
| AS2 ↔ AS3 | 10.20.0.4/30 | 10.20.0.5 | 10.20.0.6 |
| AS3 ↔ AS1 | 10.20.0.8/30 | 10.20.0.9 | 10.20.0.10 |
| Loopback AS1 | 10.20.255.1/32 | — | (prefix bị “hijack” trong demo 6.7 có thể chính là loopback này) |
| Loopback AS2 | 10.20.255.2/32 | — | |
| Loopback AS3 | 10.20.255.3/32 | — |
3. Routing Cơ Bản
3.1 — Routing Table & Default Gateway
Mỗi router/host giữ một routing table: danh sách (Destination network, Next-hop, Interface, Metric). Khi có packet cần gửi, router so khớp Destination IP với từng entry (chọn entry có prefix dài nhất khớp — “longest prefix match”), gửi packet ra Interface tới Next-hop.
0.0.0.0/0 = default route (“route of last resort”) — dùng khi không entry cụ thể nào khớp. Trên host thường gọi là default gateway.
3.2 — Static vs Dynamic Routing
- Static: route được CẤU HÌNH TAY, không tự đổi. Đơn giản, phù hợp topology nhỏ/ổn định (lab 2-3 node). Nhược điểm: nếu 1 link down, route cũ vẫn “tồn tại” trong table nhưng KHÔNG còn dùng được — không tự tìm đường khác.
- Dynamic: router TỰ trao đổi thông tin với nhau, tự build/update routing table. Hai protocol quan trọng nhất:
- OSPF (Open Shortest Path First) — IGP (Interior Gateway Protocol): router trong CÙNG MỘT AS chia sẻ “link-state” (mình kết nối tới đâu, cost bao nhiêu), mỗi router tự tính đường ngắn nhất (Dijkstra) đến mọi đích.
- BGP (Border Gateway Protocol) — EGP (Exterior Gateway Protocol): router ở CÁC AS KHÁC NHAU trao đổi route kèm AS-PATH (danh sách AS đã đi qua) — chọn route theo POLICY, không chỉ “ngắn nhất”. Đào sâu ở roadmap 6.7.
AS (Autonomous System): một mạng dưới MỘT đơn vị quản lý, định danh bằng ASN (số 16-bit hoặc 32-bit). Mỗi operator/IPX provider có ASN riêng — đây là “đơn vị” mà BGP vận hành giữa các đơn vị đó.
3.3 — VÍ DỤ TRỌNG TÂM (1): Routing Table 3-Node & Trace Packet
Topology tuyến tính (A — B — C), minh họa multi-hop routing cơ bản (khác với lab BGP tam giác ở Phần 2.6 — đây là ví dụ generic):
[H1]──10.0.10.0/24──[ A ]──10.0.1.0/30──[ B ]──10.0.2.0/30──[ C ]──10.0.20.0/24──[H2]
10.0.10.5 .1│ │.1 .2│ │.1 .2│ │.1 10.0.20.5
eth0 eth1 eth0 eth1 eth0 eth1
Routing table trên A (static):
| Destination | Next-hop | Interface |
|---|---|---|
| 10.0.10.0/24 | directly connected | eth0 |
| 10.0.1.0/30 | directly connected | eth1 |
| 10.0.2.0/30 | 10.0.1.2 (B) | eth1 |
| 10.0.20.0/24 | 10.0.1.2 (B) | eth1 |
Trace gói tin H1 (10.0.10.5) → H2 (10.0.20.5):
1. H1 → default gateway A (10.0.10.1)
2. A: lookup 10.0.20.0/24 → next-hop B (10.0.1.2) → forward qua eth1
3. B: lookup 10.0.20.0/24 → next-hop C (10.0.2.2) → forward qua eth1
4. C: lookup 10.0.20.0/24 → directly connected → deliver tới H2
Điểm yếu của static thấy ngay ở đây: nếu link A-B down, route 10.0.20.0/24 via 10.0.1.2 trên A vẫn nằm trong table nhưng VÔ DỤNG — A không tự tìm đường khác (giả sử có). OSPF sẽ phát hiện link down (qua hello/link-state) và TỰ tính lại nếu có path thay thế.
3.4 — VÍ DỤ TRỌNG TÂM (2): IP Routing vs Diameter Realm Routing — Hai Tầng Độc Lập
Đây là phần quan trọng nhất của Phần 3, vì nó generalize chính insight đã giải case DEA-HSS (SCTP role ≠ Diameter FSM role là 2 tầng độc lập) sang một cặp khái niệm khác:
| IP Routing | Diameter Realm Routing | |
|---|---|---|
| Layer | 3 (Network) | 7 (Application) |
| Key tra cứu | IP prefix (CIDR) | Chuỗi Realm (Destination-Realm AVP) |
| Khi nào chạy | MỖI packet, MỖI hop | MỖI Diameter message, mỗi Diameter agent/relay |
| Bảng tra cứu | Routing table (3.1) | Realm Routing Table (RFC 6733 §6, roadmap 5.2/6.3) |
| Kết quả nếu sai | Packet bị drop/đi sai hướng — KHÔNG đến được peer | Packet ĐẾN ĐÚNG peer (về IP) nhưng peer trả lỗi (vd DIAMETER_REALM_NOT_SERVED) hoặc không route tiếp được |
Hệ quả thực tế (tổng quát hóa từ case DEA-HSS): một Diameter message có thể:
(a) IP routing ĐÚNG + Realm routing ĐÚNG → mọi thứ hoạt động
(b) IP routing ĐÚNG + Realm routing SAI → CER/ULR đến đúng host,
nhưng bị reject ở application layer (Origin-Realm/Destination-Realm
không khớp Realm Routing Table) — TRANSPORT OK, APPLICATION SAI
(c) IP routing SAI → message KHÔNG BAO GIỜ đến
được application layer của peer — đây là dạng vấn đề case DEA-HSS
ĐÃ KHÔNG GẶP PHẢI (SCTP handshake thành công nghĩa là IP routing
đã đúng), nhưng case lại rơi vào (b)-tương-tự ở MỘT TẦNG THẤP HƠN
NỮA: ngay cả CER cũng chưa được GỬI (FSM layer, dưới Diameter
routing nhưng trên SCTP)
Nói cách khác: “IP routing vs Diameter realm routing” và “SCTP transport role vs Diameter FSM role” là HAI CẶP “tầng độc lập” KHÁC NHAU, nhưng cùng một LOẠI lỗi tư duy — nhầm “tầng dưới OK” thành “tầng trên OK”. Nhận ra pattern này là kỹ năng debug quan trọng nhất xuyên suốt mọi giao thức trong roadmap.
4. Switching
4.1 — MAC Address & CAM Table
MAC address: 48-bit, dạng XX:XX:XX:XX:XX:XX, gắn vào NIC. Switch hoạt động theo nguyên tắc học (learn) → chuyển tiếp (forward):
- Học: với mỗi frame đến, switch ghi
(Source MAC, port nhận)vào CAM table (MAC address table). - Forward: tra
Destination MACtrong CAM table — nếu CÓ, gửi CHỈ tới port đó (unicast); nếu KHÔNG (chưa học), flood ra mọi port trừ port nhận (“unknown unicast flooding”). - Broadcast (dest MAC =
FF:FF:FF:FF:FF:FF, vd ARP request) — LUÔN flood ra mọi port.
4.2 — Broadcast Domain & VLAN
Không có VLAN: toàn bộ port trên 1 switch = 1 broadcast domain — mọi device thấy broadcast (ARP…) của mọi device khác. VLAN chia LOGIC 1 switch thành nhiều broadcast domain — device ở VLAN 10 không thấy traffic broadcast của VLAN 20 dù cắm cùng switch vật lý. Lợi ích: cách ly (an toàn/tổ chức) + giảm broadcast traffic.
4.3 — 802.1Q Tag & Loại Port
- Access port: thuộc CHÍNH XÁC 1 VLAN, frame trên dây KHÔNG có tag — dùng cho end device.
- Trunk port: mang NHIỀU VLAN trên 1 dây — mỗi frame được chèn 802.1Q tag (4 byte, chứa VLAN ID 12-bit) để switch 2 đầu biết frame thuộc VLAN nào — dùng cho link switch-switch hoặc switch-router.
4.4 — VÍ DỤ TRỌNG TÂM: Docker Network & Containerlab = “Switch Ảo”
Đây là cách áp dụng 4.1-4.3 TRỰC TIẾP vào lab sắp làm (5.4 và 6.7):
- Docker bridge network (
docker network create lab-diameter) = 1 virtual switch = 1 broadcast domain = 1 VLAN. Container attach vào cùng network này thấy nhau qua ARP/broadcast — đúng 4.1-4.2. Đây là lựa chọn cho lab 5.4 (DEA + HSS-giả-lập cùng10.10.1.0/28từ Phần 2.6 → cùng 1 Docker network). - containerlab link (giữa 2 router-container trong lab 6.7) = một veth pair — về bản chất là 1 dây cáp NỐI TRỰC TIẾP 2 interface, KHÔNG qua switch trung gian → đây CHÍNH XÁC là một segment
/30(Phần 2.6) — “VLAN” với chỉ 2 thành viên (trường hợp suy biến nhỏ nhất của broadcast domain). - Container nhiều network (vd 1 “router” container nối cả
lab-diametervàlab-ss7): mỗi network là 1 bridge RIÊNG — container có 2 interface, mỗi interface trên 1 broadcast domain khác nhau. Đây giống có 2 access port trên 2 switch khác nhau hơn là 1 trunk port (Docker mặc định KHÔNG làm 802.1Q tagging giữa các bridge). Nếu cần test 802.1Q THẬT (tag thực sự trong frame), có thể tạo VLAN sub-interface bằngip link add link eth0 name eth0.10 type vlan id 10trên Linux — nằm ngoài phạm vi lab Docker mặc định nhưng tốt để biết khi cần.
Bài Tập Tổng Hợp: Áp Dụng Cho Lab 5.4 (FreeDiameter 2-Node)
Ghép cả 4 phần thành MỘT bài tập cho lab SẮP LÀM:
Cấu hình (theo 2.6): DEA = 10.10.1.1, HSS-giả-lập = 10.10.1.2,
cùng subnet 10.10.1.0/28 → cùng 1 Docker bridge network (4.4) = 1 VLAN.
Câu hỏi 1 (Routing, Phần 3): DEA gửi CER tới 10.10.1.2 — có cần
routing table tra "next-hop" không? → KHÔNG, vì 10.10.1.2 nằm CÙNG
subnet /28 với DEA — DEA chỉ cần ARP để biết MAC của 10.10.1.2, sau
đó switch (Docker bridge) forward trực tiếp (4.1). Routing CHỈ cần
khi đích ở subnet KHÁC.
Câu hỏi 2 (Encapsulation, Phần 1): Vẽ lại sơ đồ 1.4 với giá trị CỤ
THỂ — Source IP=10.10.1.1, Dest IP=10.10.1.2, IP Protocol=132, SCTP
Dest Port=3868, SCTP PPI=46, Diameter Command Code=257 (CER).
Câu hỏi 3 (Mở rộng — chuẩn bị cho 6.3): nếu thêm 1 node thứ 3
("MME-sim") ở subnet 10.10.5.0/28 (khác subnet), muốn MME-sim gửi
ULR tới HSS qua DEA làm Diameter relay — bây giờ CẢ HAI tầng routing
ở Phần 3.4 đều vào việc: (a) IP routing — MME-sim→subnet 10.10.1.0/28
cần route qua DEA (nếu DEA đóng vai router) hoặc qua gateway Docker;
(b) Diameter realm routing — DEA cần Realm Routing Table biết
Destination-Realm trong ULR của MME-sim nên forward đến HSS nào.
Đây là tình huống lab 6.3 (Diameter attack class) sẽ dùng.
Hoàn thành Câu hỏi 2 (vẽ sơ đồ với số liệu thật, đối chiếu Wireshark) chính là “Output tự kiểm” của Phần 1.1 trong roadmap — đến đây, nền tảng networking đã đủ để bắt đầu 5.4 ngay.