Đường đi gói tin ra Internet: Ethernet, IP và HTTPS

Máy tính trong văn phòng có IP, biểu tượng mạng vẫn bình thường, nhưng trình duyệt không mở được website. Nếu chỉ nhìn một thông báo “không thể kết nối”, rất dễ đổi DNS, khởi động lại router hoặc tắt firewall mà chưa biết lỗi nằm ở đâu. Một cách tiếp cận tốt hơn là dựng lại những việc phải thành công trước khi trang web xuất hiện.

Bài này theo dõi một kết nối HTTPS từ client qua switch và router biên tới máy chủ. Ta dùng IPv4, Ethernet không gắn thẻ ở cổng client và HTTPS qua TCP với TLS 1.3; không có VPN, proxy hay TLS inspection. DNS đã có kết quả từ trước. Đây là tình huống giả định để giải thích cơ chế, không phải packet capture hoặc phép thử production.

1. Chốt địa chỉ và phạm vi trước khi lần theo dữ liệu

Client A nằm trong mạng 192.168.10.0/24, dùng gateway 192.168.10.1. Một switch Layer 2 nối client với cổng LAN của R1. R1 làm định tuyến và PAT; phía ngoài nó là mạng nhà cung cấp đã được rút gọn. Máy chủ có địa chỉ minh họa 203.0.113.80, nhận HTTPS ở cổng TCP 443.

Thành phần	Địa chỉ dùng trong ví dụ	Vai trò
Client A	192.168.10.20/24; MAC 02:00:00:00:10:20	Khởi tạo TCP từ cổng 51514
R1, cổng LAN	192.168.10.1/24; MAC 02:00:00:00:10:01	Next hop của client
R1, cổng WAN	198.51.100.10; MAC 02:00:00:00:20:10	Địa chỉ nguồn sau PAT
Next hop phía WAN	198.51.100.1; MAC 02:00:00:00:20:01	Router tiếp theo trên đoạn Ethernet WAN giả định
Máy chủ	203.0.113.80, TCP 443	Đích cuối của kết nối

198.51.100.0/24 và 203.0.113.0/24 là dải dành cho tài liệu theo RFC 5737. Không dùng các IP này để kiểm tra Internet thật. Các MAC trong ví dụ là địa chỉ unicast quản trị cục bộ do người viết chọn; chúng không mô tả phần cứng của bạn.

Client A qua switch và R1 tới máy chủ HTTPS trong topology giả định — Switch nối các cổng cùng LAN; R1 định tuyến và PAT. Đường WAN được rút gọn, không thể hiện toàn bộ router của Internet.

Trong mô hình này switch không đóng vai trò default gateway. Một switch Layer 3 có thể làm việc đó trong thiết kế khác. Tương tự, PAT đặt tại R1 là lựa chọn của ví dụ; một đường Internet thực có thể thêm NAT của nhà cung cấp hoặc dùng IPv6 mà không cần phép dịch này.

2. Client quyết định gửi qua gateway, rồi tìm MAC

Client biết IP đích nhưng chưa thể đưa một gói IPv4 trực tiếp lên cáp Ethernet. Nó cần tuyến đi và địa chỉ Layer 2 của next hop. Với bảng tuyến chỉ gồm mạng kết nối trực tiếp và default route, IP đích 203.0.113.80 không thuộc 192.168.10.0/24, nên tuyến mặc định dẫn tới 192.168.10.1.

Điểm dễ nhầm là client không đi tìm MAC của server ở xa. Nó cần MAC của gateway trên chính LAN của mình. Nếu chưa có ánh xạ hợp lệ trong cache, ARP sẽ hỏi ai đang giữ 192.168.10.1. Khi nhận được câu trả lời, client có thể tạo frame đích tới MAC cổng LAN R1. Hướng dẫn ARP của Cisco IOS XE mô tả vai trò ánh xạ địa chỉ giao thức sang địa chỉ phần cứng.

Chưa cần ARP nếu cache đã có mục dùng được. Và phép so subnet ở trên là cách giải thích cho bảng tuyến đơn giản, không thay thế việc tra bảng tuyến thực tế: VPN hoặc tuyến cụ thể hơn có thể chọn một interface khác. Khi kết quả khác dự đoán, hãy kiểm tra route trước khi kết luận ARP làm sai.

Trong frame đầu tiên, MAC nguồn thuộc client, MAC đích thuộc R1; còn IP đích trong gói vẫn là máy chủ. Hai địa chỉ này trả lời hai câu hỏi khác nhau: frame giao cho ai ở chặng hiện tại, và gói cần tới đâu ở lớp IP.

3. HTTPS là một chuỗi trao đổi, không phải một gói duy nhất

Ở ví dụ này, client mở kết nối TCP tới server. Luồng khởi đầu thông thường là SYN, SYN-ACK rồi ACK; số sequence và acknowledgement giúp hai bên quản lý dữ liệu trong kết nối. Một server không trả lời có thể do thiếu đường, lọc gói, dịch vụ không lắng nghe hoặc nhiều nguyên nhân khác. Chỉ nhìn SYN gửi đi chưa chọn được một nguyên nhân.

Sau khi có kết nối phù hợp, hai bên thực hiện TLS để xác lập thông số bảo mật và kiểm tra danh tính server theo cơ chế của trình duyệt. Request HTTP và response sau đó đi trong kênh được bảo vệ. RFC 9293 là đặc tả TCP hiện hành; RFC 8446 mô tả TLS 1.3. Các bước ở đây là mô hình đọc hiểu, không cam kết mỗi bước tương ứng chính xác một packet.

HTTPS trong TLS, TCP, IPv4 và Ethernet cùng lưu ý về nhiều segment — Đóng gói nhìn theo lớp. Một HTTP message có thể trải qua nhiều TCP segment; TLS record và packet không có quan hệ một-một.

Trình duyệt hiện đại còn có thể dùng HTTP/3 qua QUIC trên UDP. Vì vậy “HTTPS luôn là TCP 443” là kết luận quá rộng. Ta chủ động chọn nhánh TCP để học trước; RFC 9000 giải thích nền tảng QUIC. Khi chẩn đoán một kết nối thật, xác định giao thức đang dùng thay vì suy luận chỉ từ URL bắt đầu bằng https://.

DNS được giả định đã hoàn tất để tránh trộn hai quá trình. Trong thực tế, một tên có thể trả nhiều địa chỉ, client có thể ưu tiên IPv6, và kết quả có thể nằm trong cache. “Không thấy DNS request trong capture” chưa đủ để nói rằng ứng dụng không dùng tên miền.

4. Switch chuyển frame, router xử lý chặng IP tiếp theo

Switch nhận frame từ client và học MAC nguồn trên port/VLAN tương ứng. Nếu đã biết MAC đích nằm ở port nối R1, nó chuyển frame theo thông tin đó. Nếu MAC đích chưa có trong bảng, unknown unicast có thể được flood trong VLAN theo chính sách của thiết bị. Switch Layer 2 thông thường không giảm TTL của gói IP chỉ vì chuyển frame qua nó.

R1 nhận frame có MAC đích là cổng LAN của mình, xử lý phần IP và xác định tuyến tới đích. Với chuyển tiếp IPv4 thông thường, TTL bị giảm; nếu hết TTL thì gói không được tiếp tục như bình thường. IP header checksum phải được cập nhật khi các trường liên quan đổi. Yêu cầu chuyển tiếp này được trình bày trong RFC 1812.

R1 không giữ frame Ethernet của client để đưa nguyên vẹn qua mọi mạng. Nếu interface ra cũng là Ethernet, nó tạo frame cho chặng đó: MAC nguồn là cổng WAN R1, MAC đích là MAC của router next hop phía WAN. Đóng gói trên công nghệ đường truyền khác có thể khác; hình trong bài chỉ mô tả hai đoạn Ethernet đã chọn.

Đừng suy ra thứ tự toàn bộ tính năng trong một thiết bị chỉ từ ba đoạn mô tả này. ACL, NAT, policy routing, tăng tốc phần cứng và các dịch vụ khác có quan hệ xử lý phụ thuộc nền tảng, hướng lưu lượng và cấu hình. Ở đây ta theo dõi kết quả địa chỉ trước/sau từng chặng, chưa thiết kế feature pipeline cho một model router cụ thể.

5. PAT thay địa chỉ nguồn và giữ ánh xạ cho đường về

Giả sử R1 dịch luồng 192.168.10.20:51514 thành 198.51.100.10:40001. Đây là ánh xạ minh họa được chọn để thấy sự thay đổi; thiết bị thực có thể giữ nguyên hoặc chọn cổng khác. IP và cổng đích vẫn là 203.0.113.80:443 trong ví dụ source PAT này.

Tài liệu NAT FAQ của Cisco phân biệt các khái niệm địa chỉ và PAT. Phép dịch giúp nhiều luồng chia sẻ địa chỉ, nhưng không tự chứng minh thiết bị đã có tuyến mặc định, firewall cho phép hay server còn hoạt động. Cần đọc translation cùng trạng thái interface, route và chính sách.

MAC đổi theo chặng và IP nguồn đổi bởi PAT trong kết nối mẫu — Source PAT thay IP/cổng nguồn. Ethernet dùng MAC của next hop tại từng chặng; frame phản hồi tới client được tạo lại ở cổng LAN R1.

Response từ server hướng về địa chỉ/cổng đã dịch. Khi tới đúng thiết bị còn giữ ánh xạ hợp lệ và được chính sách cho phép, R1 dịch đích về client rồi chuyển vào LAN. Nếu đường về tránh qua R1 hoặc trạng thái đã hết hạn, việc client gửi đi được không bảo đảm kết nối hoàn tất.

PAT cũng không phải cơ chế mã hóa nội dung. Một kết nối TLS bảo vệ dữ liệu theo phạm vi phiên TLS; router chuyển tiếp và NAT thông thường vẫn xử lý các header cần thiết để đưa lưu lượng tới nơi. Proxy giải mã TLS là thiết kế khác, ngoài mô hình hiện tại.

6. Chọn phép kiểm tra theo chặng đang nghi ngờ

Trước tiên ghi lại IP, mask, gateway và interface đang được dùng. Trên Windows 11, có thể bắt đầu bằng các lệnh đọc trạng thái dưới đây. Thay địa chỉ bằng giá trị của mạng được phép kiểm tra; các IP tài liệu trong bài không có dịch vụ thật.

ipconfig /all
route print -4
arp -a
ping <IP-gateway-thuc-te>
Test-NetConnection -ComputerName <ten-may-chu-thuc-te> -Port 443

Test-NetConnection chạy trong PowerShell; phép thử TCP thành công không kiểm tra đầy đủ chứng chỉ TLS hoặc chức năng website. Ping có thể bị chặn dù TCP được cho phép. Ngược lại, gateway trả lời ping chỉ xác nhận trao đổi ICMP tới gateway tại thời điểm thử. Khi ghi kết quả, luôn kèm thời điểm và đích đã dùng.

Trên Cisco IOS/IOS XE có thể đối chiếu các bảng sau; tên interface và hỗ trợ câu lệnh tùy thiết bị. Lệnh NAT chỉ hữu ích trên thiết bị đang thực hiện NAT và có tính năng tương ứng. Một số lệnh cần quyền EXEC phù hợp; output có thể chứa địa chỉ nội bộ, nên cần biên tập trước khi chia sẻ.

show ip interface brief
show ip route
show ip arp
show mac address-table dynamic
show ip nat translations

Đây là danh sách kiểm tra có định hướng, không phải script để chạy mù trên mọi thiết bị. Không cần bật debug, xóa translation hay xóa toàn bộ bảng ARP ngay từ đầu. Các thao tác đó có thể làm thay đổi trạng thái đang cần quan sát hoặc ảnh hưởng kết nối đang dùng.

7. Chốt kết luận theo bằng chứng, không theo biểu tượng mạng

Nếu chưa phân giải được gateway, tập trung vào LAN, VLAN, mask và interface trước. Nếu gateway đã được phân giải nhưng SYN không có phản hồi, mở rộng sang route, policy và đường về. Nếu TCP đã kết nối mà trình duyệt báo lỗi chứng chỉ, chuyển giả thuyết lên TLS, thời gian hệ thống hoặc tên miền. Mỗi bước thu hẹp phạm vi, không tự kết luận nguyên nhân duy nhất.

Thử tự trả lời ba câu: frame từ A tới R1 có IP đích nào; MAC nào được dùng ở cổng WAN R1; và server trả về cổng nào sau PAT trong ví dụ? Đáp án lần lượt là IP server, MAC next hop WAN và cổng 40001 của địa chỉ đã dịch. Khi nêu được lý do cho từng đáp án, đọc tiếp bài Ethernet, MAC và ARP để phân tích kỹ cách next hop được tìm thấy. Bạn cũng có thể trở lại lộ trình 28 bài để chọn chặng học tiếp.