Skip to content
LIVE FEED

BlogTài Liệu Tri Thức: Networking Cơ Bản

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
7ApplicationGiao thức người dùng cuối — định nghĩa Ý NGHĨA dữ liệuData
6PresentationĐịnh dạng/encode/mã hóa dữ liệu (ASN.1, TLS thường xếp đây hoặc layer 4)Data
5SessionThiết lập/duy trì/kết thúc “phiên” logic giữa 2 bênData
4TransportTruyền end-to-end, có thể đảm bảo reliable/orderedSegment (TCP) / Datagram (UDP) / Packet (SCTP)
3NetworkĐịa chỉ logic (IP) + routing giữa các mạngPacket
2Data LinkĐịa chỉ vật lý (MAC) + framing trong 1 mạng cục bộFrame
1PhysicalBit 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 LayerGộp từ OSIVí dụ
4 — ApplicationOSI 5+6+7HTTP, DNS, Diameter, SIP
3 — TransportOSI 4TCP, UDP, SCTP
2 — InternetOSI 3IP, ICMP
1 — Link (Network Access)OSI 1+2Ethernet, 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ứcOSI LayerTCP/IP LayerTransport bên dưới
Diameter74 (App)SCTP hoặc TCP
SIP74 (App)UDP/TCP/TLS
GTP-C / GTP-U7*4 (App)UDP
MAP (qua SIGTRAN)74 (App)SCCP → M3UA → SCTP
SCTP43 (Transport)IP
IP32 (Internet)Ethernet
Ethernet1-21 (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 == 46 hoặ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.

CIDRSubnet maskTổng số địa chỉ (2^(32-N))Host khả dụng (-2)
/24255.255.255.0256254
/27255.255.255.2243230
/28255.255.255.2401614
/29255.255.255.24886
/30255.255.255.25242

/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)

BlockRangeSố địa chỉ
10.0.0.0/810.0.0.0 – 10.255.255.255~16.7 triệu
172.16.0.0/12172.16.0.0 – 172.31.255.255~1 triệu
192.168.0.0/16192.168.0.0 – 192.168.255.25565,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ấtHost khả dụngGhi chú
GĐ1 — FreeDiameter 2-node (5.4)10.10.1.0/2814DEA=10.10.1.1, HSS giả lập=10.10.1.2
GĐ2 — SS7/Osmocom (6.2)10.10.2.0/2814
GĐ2 — GTP/Open5GS EPC+5GC (6.4, 6.8)10.10.3.0/24254Open5GS cần nhiều subnet con (UE pool, N2/N3/N4) — /24 đủ rộng
GĐ2 — SIP/OpenSIPS (6.5)10.10.4.0/2814
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:

LinkSubnetIP đầu AIP đầu B
AS1 ↔ AS210.20.0.0/3010.20.0.110.20.0.2
AS2 ↔ AS310.20.0.4/3010.20.0.510.20.0.6
AS3 ↔ AS110.20.0.8/3010.20.0.910.20.0.10
Loopback AS110.20.255.1/32—(prefix bị “hijack” trong demo 6.7 có thể chính là loopback này)
Loopback AS210.20.255.2/32—
Loopback AS310.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):

DestinationNext-hopInterface
10.0.10.0/24directly connectedeth0
10.0.1.0/30directly connectedeth1
10.0.2.0/3010.0.1.2 (B)eth1
10.0.20.0/2410.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 RoutingDiameter Realm Routing
Layer3 (Network)7 (Application)
Key tra cứuIP prefix (CIDR)Chuỗi Realm (Destination-Realm AVP)
Khi nào chạyMỖI packet, MỖI hopMỖI Diameter message, mỗi Diameter agent/relay
Bảng tra cứuRouting table (3.1)Realm Routing Table (RFC 6733 §6, roadmap 5.2/6.3)
Kết quả nếu saiPacket bị drop/đi sai hướng — KHÔNG đến được peerPacket ĐẾ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 MAC trong 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ùng 10.10.1.0/28 từ 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-diameter và 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ằng ip link add link eth0 name eth0.10 type vlan id 10 trê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.

Contact
Facebook
TOP