Những quan niệm sai lầm mà lập trình viên thường tin về mạng LAN

Khi phát triển phần mềm, đặc biệt là các ứng dụng chạy trong môi trường doanh nghiệp hoặc hạ tầng nội bộ, chúng ta thường mặc định mạng LAN (Local Area Network) đơn giản và ổn định hơn so với Internet. Tuy nhiên, thực tế cho thấy có rất nhiều giả định sai lầm có thể dẫn đến những lỗi khó chịu, khó gỡ rối.

Bài viết dưới đây điểm qua các "falsehoods" (quan niệm sai) kinh điển về mạng LAN mà lập trình viên thường tin, được nhóm theo các chủ đề chính.

Những hiểu lầm về NAT

NAT (Network Address Translation) thường bị hiểu nhầm là một thành phần bắt buộc của mạng LAN. Nhiều lập trình viên cho rằng mọi mạng nội bộ đều đứng sau NAT, hoặc chỉ có một lớp NAT duy nhất.

Trên thực tế, mạng LAN chạy IPv6 thuần túy có thể không cần tới NAT. Trong những hệ thống phức tạp (nhiều tầng mạng, VPN chồng nhau), thiết bị có thể nằm sau nhiều lớp NAT. Ngược lại, một địa chỉ RFC 1918 (như 192.168.x.x) không đảm bảo bạn đang ở sau NAT, vì bạn có thể đang kết nối trực tiếp vào mạng nội bộ không có khả năng định tuyến ra ngoài.

Ngoài ra, NAT không chỉ thay đổi địa chỉ IP và cổng — nó có thể ảnh hưởng đến giao thức ICMP, phân mảnh gói tin, hay các trường tùy chọn trong TCP header. Một số thiết bị còn thực hiện Deep Packet Inspection trên nền NAT để sửa lỗi checksum.

Giao thức chạy trên LAN

Nhiều người tin rằng mạng LAN chỉ chạy mỗi IPv4, hoặc thậm chí chỉ có IP. Trong thực tế, một mạng LAN có thể chạy song song nhiều giao thức tầng mạng, khá phổ biến ở các môi trường cũ: IPX/SPX (trên mạng Novell), AppleTalk (máy Mac cũ), hay các giao thức SNA trong hệ thống máy tính lớn (mainframe).

Ngay cả với IP, mạng LAN có thể chạy đồng thời cả IPv4 lẫn IPv6. Và bạn thường không thể ép toàn bộ lưu lượng (ví dụ: chặn một loại giao thức nào đó) trên một LAN vật lý vì nhiều thiết bị mạng chuyển mạch (switch) vốn dĩ không hỗ trợ lọc theo ý muốn của bạn.

"Tôi biết mình đang chạy cái gì trên LAN" — Đây chính là một trong những quan niệm sai lầm nguy hiểm nhất khi bảo mật mạng nội bộ.

Địa chỉ MAC — không hề "bất biến"

Một trong những lỗi nghiêm trọng nhất là tin rằng địa chỉ MAC là duy nhất toàn cầu. Trên thực tế, các nhà sản xuất phần cứng có thể tái sử dụng dãy MAC (nhất là trong các lô sản xuất giá rẻ), và một card mạng có thể được gán địa chỉ MAC tùy chỉnh thông qua phần mềm (MAC spoofing).

Ngoài ra, MAC address dài 48 bit là chuẩn truyền thống, nhưng chuẩn mới (EUI-64) sử dụng 64 bit. Ba byte đầu của MAC 48-bit thường là vendor-unique, nhưng không phải luôn luôn đúng cho tất cả các khối (có khối MA-M, MA-S ngắn hơn).

Một giả định khác: "Chỉ có một máy với một địa chỉ MAC cụ thể". Khi sử dụng bonding/teaming, nhiều interface có thể dùng chung một MAC. Máy ảo thường đổi MAC ảo khi clone. Do đó, không thể dùng MAC để định danh duy nhất một thiết bị trong hệ thống.

Hiệu suất và khả năng truy cập

Mọi lập trình viên đều yêu thích mạng LAN vì tin rằng nó "rất nhanh". Thực tế, một mạng Wi-Fi đông người dùng có thể có độ trễ (latency) cao hơn cả đường Internet cáp quang trong một số tình huống. Độ giật (jitter) trên Wi-Fi cũng là một vấn đề đáng lo ngại.

Hai host trên cùng một subnet không phải lúc nào cũng có thể nói chuyện trực tiếp với nhau. Có thể có ACL (Access Control List) trên switch chặn, hoặc tính năng "client isolation" trong Wi-Fi (thường bật ở các điểm phát sóng công cộng) sẽ chặn host này truy cập host khác — dù cùng tầng mạng.

Wi-Fi client và Ethernet client được đối xử khác nhau: trên Wi-Fi, tất cả các client dùng chung một kênh truyền bán song công (half-duplex), trong khi trên Ethernet switch hiện đại, mỗi cổng là một collision domain riêng biệt. Do đó, không bao giờ nên giả định Wi-Fi có hành vi giống hệt Ethernet.

MTU (Maximum Transmission Unit) không đồng nhất giữa các thiết bị trên cùng một LAN. IPv6 có thể không cần MTU tối thiểu như IPv4, và một số tunnel (GRE, PPPoE) làm giảm MTU xuống đáng kể.

DHCP — luôn luôn phức tạp

Một số giả định về DHCP có thể trở nên sai trong các mạng có nhiều DHCP server (khi đó, IP có thể bị xung đột), hoặc khi mạng không sử dụng DHCP (cấu hình tĩnh) — khi đó máy không nhận được IP nào cả.

Trong nhiều mạng doanh nghiệp, DHCP server và gateway không nằm trên cùng một thiết bị. Có thể DHCP không trả về gateway (nếu bạn đang trên một mạng không có routing ra ngoài — ví dụ lab nội bộ cô lập) — hoặc không trả về DNS server nào.

Nhiều người cho rằng địa chỉ 169.254.0.0/16 (link-local) chỉ xuất hiện khi DHCP thất bại. Thực tế, Windows và một số hệ điều hành khác luôn tự gán link-local khi không tìm thấy DHCP, nhưng các thiết bị mạng cấu hình tĩnh (như máy in) có thể không bao giờ rơi vào trạng thái này.

Địa chỉ IP — những giả định căn bản

Cuối cùng, một số lỗi lầm khó tránh nhất: tin rằng mỗi thiết bị chỉ có một IP. Trong thực tế, máy tính có thể có nhiều interface mạng, máy di động nối qua Wi-Fi lẫn USB tethering, và server có thể gắn nhiều IP trên một interface (IP aliasing).

Và nhiều người vẫn nghĩ chỉ có dải RFC 1918 (10.x.x.x, 172.16-31.x.x, 192.168.x.x) là "private". Nhưng một mạng LAN có thể sử dụng IPv6 ULA (fc00::/7) hoặc thậm chí dùng IP public mà không có NAT — ví dụ trong các phòng lab giáo dục hoặc môi trường thử nghiệm với IP công khai được cấp phát tĩnh trong một tổ chức.

Lời khuyên cho lập trình viên

Những "falsehood" trên không có nghĩa là mọi mạng LAN đều phức tạp. Nhưng khi bạn viết code cho một hệ thống quản lý mạng, thiết bị IoT hoặc ứng dụng đồng bộ dữ liệu peer-to-peer nội bộ, hãy luôn:

• Không giả định mạng LAN của bạn bao giờ cũng an toàn, nhanh và trong suốt.
• Sử dụng các giao thức có khả năng tự khám phá (mDNS, SSDP) nhưng phải có fallback.
• Kiểm tra thực tế hạ tầng mạng của khách hàng trước khi tối ưu theo hướng "same subnet = cùng phòng".

Chỉ khi bạn chấp nhận rằng mọi thứ có thể khác đi, bạn mới có thể viết ra những phần mềm robust, dễ vận hành trong thế giới mạng thực — vốn không bao giờ đơn giản như trong sách giáo khoa.