Ethernet, MAC và ARP: tìm đúng thiết bị trong mạng LAN
Phân tích Ethernet frame, ARP request/reply và ba bảng route, ARP, MAC. Dùng cùng một topology để khoanh vùng lỗi LAN mà không xóa cache vội.
Hai máy cùng phòng, cắm vào cùng một switch nhưng không ping được nhau. Trong khi đó, một máy vẫn mở được Internet. Nếu chỉ kết luận “switch đang tốt vì Internet vẫn chạy”, ta có thể bỏ qua VLAN, subnet mask, firewall hoặc một ánh xạ ARP sai. Muốn khoanh vùng, cần tách quá trình tìm next hop khỏi quá trình chuyển frame.
Bài này tiếp tục mô hình của bài đường đi ra Internet: Ethernet, IPv4 và một VLAN người dùng. Client A là 192.168.10.20/24, client B là 192.168.10.30/24, gateway R1 là 192.168.10.1. Topology và output dưới đây là ví dụ biên tập, chưa phải kết quả chạy trên thiết bị thật.
1. Phân biệt frame Ethernet, gói IPv4 và bảng ánh xạ
Địa chỉ IPv4 phục vụ quyết định chuyển gói ở lớp mạng. Ethernet dùng địa chỉ MAC để giao frame trong phạm vi Layer 2. ARP giúp tìm MAC tương ứng với một địa chỉ IPv4 trên liên kết; switch lại học MAC xuất hiện ở port/VLAN nào. Hai bảng cùng có MAC nhưng trả lời hai câu hỏi khác nhau.
Trong mô hình Ethernet II không gắn thẻ VLAN tại cổng client, phần frame được minh họa gồm MAC đích 6 byte, MAC nguồn 6 byte, EtherType 2 byte, payload và FCS 4 byte. Với IPv4, EtherType là 0x0800; với ARP là 0x0806. ARP được mang trực tiếp trong Ethernet, không nằm bên trong một gói IPv4.
RFC 894 mô tả việc mang IP trên Ethernet. Hình dưới tách preamble/SFD khỏi phần frame từ địa chỉ đích đến FCS. Không đưa inter-frame gap vào kích thước frame. Khi học cách đếm byte, phải chốt quy ước trước, nếu không hai con số có thể khác nhau dù đang mô tả cùng một truyền dẫn.
Trên điện thoại: cuộn ngang sơ đồ hoặc chạm để mở ảnh gốc.
Payload quá ngắn cần padding để đạt kích thước tối thiểu của Ethernet. Với quy ước trong hình, frame không gắn thẻ thường từ 64 đến 1518 byte, tính từ MAC đích đến FCS; không dùng con số này để bao quát VLAN tag hoặc jumbo frame. Capture trên host còn có thể không hiện FCS do cách card mạng và driver cung cấp dữ liệu.
MAC cũng không phải dấu định danh bất biến của một con người hoặc một thiết bị. Phần mềm có thể đặt địa chỉ quản trị cục bộ; hệ điều hành có thể dùng địa chỉ riêng tư trong một số kết nối. Khi kiểm kê hoặc điều tra, kết hợp MAC với port, VLAN, thời điểm và dữ liệu quản lý khác thay vì chỉ dựa vào tiền tố nhà sản xuất.
2. Chọn IP cần phân giải trước khi gửi ARP
A muốn gửi gói cho B. Với mask /24 và không có route đặc biệt, A xác định 192.168.10.30 nằm trên mạng kết nối trực tiếp. IP cần tìm MAC là IP của B. Nếu A gửi tới 203.0.113.80, tuyến mặc định dẫn qua R1, nên địa chỉ cần tìm MAC lại là 192.168.10.1.
Quy trình đầy đủ bắt đầu từ tra bảng tuyến, chọn interface/next hop rồi phân giải địa chỉ trên liên kết tương ứng. Câu “cùng subnet thì ARP trực tiếp” chỉ đủ trong topology đơn giản đang dùng. Một route cụ thể, VPN hoặc nhiều interface có thể làm thay đổi lựa chọn. Hãy kiểm tra route mà hệ điều hành thực sự dùng khi thực tế không khớp sơ đồ.
| A muốn gửi tới | IP cần phân giải trong ví dụ | MAC đích của frame dữ liệu |
|---|---|---|
| B: 192.168.10.30 | 192.168.10.30 | MAC của B |
| Server: 203.0.113.80 | 192.168.10.1 | MAC cổng LAN R1 |
| Gateway: 192.168.10.1 | 192.168.10.1 | MAC cổng LAN R1 |
Trong cả trường hợp server ở xa, IP đích của gói vẫn là server. Không thay trường IP đích thành gateway chỉ vì đang gửi frame tới gateway. Phân biệt này giúp đọc packet capture mà không nhầm một gói chuyển tiếp là kết nối ứng dụng đang mở tới router.
3. Lần theo ARP request và reply giữa hai máy
Gán MAC A là 02:00:00:00:10:20, MAC B là 02:00:00:00:10:30. Nếu A chưa có ánh xạ dùng được của B, nó tạo ARP request. Ethernet destination là broadcast ff:ff:ff:ff:ff:ff. Trong ARP payload, sender mang cặp địa chỉ của A, còn target protocol address là IP của B.
Cần phân biệt Ethernet destination với trường target hardware address bên trong ARP request. Ở ví dụ, trường target hardware chưa biết được biểu diễn bằng các byte 0; điều đó không biến Ethernet destination thành 0. Hai trường thuộc hai cấu trúc khác nhau. RFC 826 là đặc tả nền tảng cho cách phân giải địa chỉ này.
Trên điện thoại: cuộn ngang sơ đồ hoặc chạm để mở ảnh gốc.
Switch học MAC nguồn của A trên port nhận, rồi flood broadcast tới các port đủ điều kiện khác trong VLAN. B nhận ra target IP là địa chỉ của mình và thông thường gửi ARP reply unicast về A. Sau khi có ánh xạ, A gửi frame dữ liệu unicast với MAC đích của B. Không có yêu cầu mỗi gói IPv4 đều phải mở đầu bằng một ARP broadcast mới.
Router thông thường không chuyển tiếp broadcast ARP sang subnet khác. Trong trường hợp đích xa, A hỏi R1 trên LAN, còn R1 có thể thực hiện một lần phân giải riêng cho next hop trên interface ra Ethernet. Một miền Layer 2 có thể trải qua nhiều switch, nên “không qua router” không có nghĩa “chỉ nằm trong một switch vật lý”.
Proxy ARP là một ngoại lệ cần nhận biết: router có thể trả lời thay cho địa chỉ khác khi điều kiện và cấu hình cho phép. Vì vậy một IP trả về MAC của router chưa luôn chứng minh máy đích nằm tại router. Trong mô hình bài này không dùng proxy ARP; khi phân tích mạng thật, kiểm tra cấu hình trước khi áp quy tắc đơn giản.
4. Đọc đúng ba bảng: route, ARP và MAC
Bảng tuyến chọn cách đi tới prefix IP. Bảng ARP lưu ánh xạ IPv4 với địa chỉ Layer 2 trên interface phù hợp. Bảng MAC của switch ánh xạ MAC tới port/VLAN mà switch đã học hoặc được cấu hình. Một mục ở một bảng không tự kéo theo mục tương ứng ở hai bảng còn lại.
Ví dụ, switch có thể đã học MAC B từ lưu lượng trước đó, trong khi A vừa hết hạn cache ARP. A vẫn phải phân giải IP của B. Chiều ngược lại, A có mục ARP nhưng switch đã aging mục MAC; frame unicast có thể bị flood cho đến khi switch học lại. Cơ chế này khác ARP broadcast dù người quan sát đều thấy frame xuất hiện ở nhiều port.
Trên Windows 11, bắt đầu bằng các lệnh đọc trạng thái. Get-NetNeighbor chạy trong PowerShell; tên interface và số lượng mục thay đổi theo máy. Đối chiếu interface đang dùng vì Wi-Fi, Ethernet, VPN và adapter ảo có thể cùng tồn tại.
ipconfig /all
route print -4
Get-NetNeighbor -AddressFamily IPv4
arp -aTrên Linux dùng ip -4 addr, ip -4 route và ip neigh. Trên Cisco IOS/IOS XE có thể đọc show ip arp; trên switch phù hợp dùng show mac address-table dynamic. Cú pháp, quyền và trường hiển thị phụ thuộc phiên bản, nên kiểm tra trợ giúp trước khi tự động hóa.
Ví dụ minh họa trên A, không phải output đã chạy:
192.168.10.1 -> 02:00:00:00:10:01 trên interface LAN
192.168.10.30 -> 02:00:00:00:10:30 trên interface LANMục hoàn chỉnh cho thấy hệ thống đã biết một ánh xạ theo trạng thái cache; chưa chứng minh host đang trả lời mọi giao thức. Trạng thái như STALE trên Linux có ý nghĩa riêng về kiểm tra khả năng tiếp cận, không đồng nghĩa thiết bị đã hỏng. Cần đọc trạng thái theo tài liệu của hệ điều hành.
5. Khoanh vùng lỗi bằng dữ kiện trước khi xóa cache
Giả sử A không ping được B. Đầu tiên kiểm tra A/B có đúng IP và mask dự kiến không, interface có hoạt động không, hai port có thực sự cùng VLAN không. Hai máy cùng cắm vào một switch vẫn có thể thuộc hai miền quảng bá khác nhau. Tên phòng ban hoặc vị trí bàn làm việc không xác định subnet.
Trên điện thoại: cuộn ngang sơ đồ hoặc chạm để mở ảnh gốc.
Nếu route chọn đúng LAN mà mục neighbor liên tục không hoàn tất, cần xem request có rời A và reply có trở về không. Có thể B không hoạt động, port sai VLAN, broadcast bị chặn, địa chỉ đích sai hoặc chính sách bảo vệ loại gói. Chỉ từ một mục incomplete chưa thể kết luận cáp hỏng. Capture ở host cũng không nhìn thấy toàn bộ traffic trên một switched LAN.
Nếu có ánh xạ nhưng ping thất bại, kiểm tra độ tin cậy của ánh xạ, trạng thái B, firewall và chính sách ICMP. ARP chạy ở lớp khác ICMP; một hệ thống có thể trả lời ARP nhưng bỏ ping. Thử dịch vụ được cho phép ở B sẽ bổ sung bằng chứng, nhưng chỉ thử trong phạm vi quản trị của bạn.
Địa chỉ trùng có thể khiến một IP xuất hiện với các MAC khác nhau theo thời điểm. Tuy nhiên MAC đổi cũng có thể do dự phòng gateway, di chuyển VM hoặc cơ chế hợp lệ khác. Hãy đối chiếu log, DHCP, port và thời điểm; không gọi một lần thay đổi là tấn công ARP chỉ dựa vào ảnh chụp bảng cache.
Không xóa toàn bộ ARP cache hoặc bảng MAC ngay ở bước đầu. Bạn có thể làm mất bằng chứng và buộc các kết nối học lại, gây gián đoạn ngắn trong một số điều kiện. Nếu đã xác định một mục cần làm mới, dùng thao tác có phạm vi trên thiết bị được phép quản trị, ghi lại trước/sau và làm theo hướng dẫn đúng hệ điều hành.
6. Nhận biết giới hạn của ARP và của phép quan sát
ARP truyền thống không cung cấp xác thực mật mã cho cặp IP/MAC được quảng bá. Một thiết bị không đáng tin trong cùng miền truy cập có thể đưa thông tin sai. Biện pháp bảo vệ cần thiết kế ở tầng truy cập và quản trị, ví dụ phân đoạn, DHCP snooping/DAI trên nền tảng hỗ trợ và chính sách kiểm soát thiết bị.
Không áp dụng các tính năng đó như một công tắc sửa mọi lỗi ARP. DAI phụ thuộc dữ liệu và cách xác định port tin cậy; môi trường IP tĩnh có thể cần xử lý riêng. Bật cấu hình chưa hiểu có thể loại cả lưu lượng hợp lệ. Phần bảo vệ Layer 2 của series sẽ phân tích điều kiện triển khai; bài này dừng ở hiểu cơ chế và dấu hiệu.
IPv6 không dùng ARP cho nhiệm vụ tương đương. Nó dùng Neighbor Discovery với ICMPv6 và những quy tắc riêng, được mô tả trong RFC 4861. Đừng kết luận một client IPv6 không phân giải được neighbor chỉ vì arp -a không hiện địa chỉ đang tìm.
7. Tự kiểm tra trước khi học TCP và UDP
Hãy vẽ lại hai trường hợp: A gửi B cùng subnet và A gửi server qua gateway. Với mỗi trường hợp, ghi IP đích trong gói, IP target của ARP và MAC đích của frame dữ liệu. Kết quả cần đạt là giải thích được vì sao trường hợp thứ hai có ba vai trò địa chỉ khác nhau mà vẫn nhất quán.
Tiếp theo, thử tình huống A có cache B nhưng switch chưa học MAC B. Câu trả lời cần nhắc tới unknown unicast flooding, không đổi nó thành ARP request. Cuối cùng, nêu một lý do khiến ARP thành công nhưng ping thất bại. Khi phân biệt được ba tình huống này, bạn đã có nền tảng để học kết nối TCP, UDP và cách đọc timeout trong lộ trình các bài tiếp theo.