Router Không Cấp IP, Tràn DHCP Trên DrayTek/MikroTik: Nguyên Nhân Và Cách Xử Lý

Router Không Cấp IP Tràn DHCP DrayTek

Sáng thứ Hai, nhân viên mới cắm cáp mạng vào cổng LAN, mở laptop lên – không vào được internet. Ping tới router vẫn thành công, nhưng gõ `ipconfig /all` thì thấy toàn IP dạng 169.254.x.x. Các máy khác trong văn phòng đang chạy bình thường, chỉ riêng thiết bị mới cắm vào là không nhận được địa chỉ IP. Đây là dấu hiệu điển hình của tràn DHCP (DHCP pool exhaustion) – và nó xảy ra trên cả router DrayTek và MikroTik, không phân biệt thương hiệu.

Dấu hiệu tràn DHCP là gì và vì sao thiết bị mới không lấy được IP?

Mỗi khi một thiết bị kết nối vào mạng, nó thực hiện chu trình DHCP theo 4 bước chuẩn hóa trong RFC 2131 gọi tắt là DORA: Discover (thiết bị phát yêu cầu tìm DHCP server) – Offer (router đề xuất một IP còn trống) – Request (thiết bị xin chính thức IP đó) – Ack (router xác nhận cấp). Vấn đề nằm ở bước Offer: router chỉ có một dải IP (DHCP pool) với số lượng địa chỉ hữu hạn, ví dụ 192.168.1.100 – 192.168.1.200 chỉ có 100 địa chỉ. Khi toàn bộ 100 địa chỉ này đã bị chiếm giữ (leased) và chưa được giải phóng, router không còn IP nào để Offer cho thiết bị mới – nó buộc phải im lặng hoặc từ chối yêu cầu.

Khi không nhận được phản hồi từ DHCP server, hệ điều hành Windows/macOS sẽ tự gán một địa chỉ dạng APIPA (169.254.x.x) để thiết bị vẫn “có mạng LAN” nhưng hoàn toàn không kết nối được ra ngoài. Đây là lý do thiết bị cũ (đã có lease từ trước, chưa hết hạn) vẫn chạy bình thường, còn thiết bị mới – hoặc thiết bị vừa hết hạn lease và đang xin cấp lại – là nạn nhân đầu tiên.

Tràn DHCP do đâu? 3 nguyên nhân gốc rễ cần phân biệt rõ

Một số nội dung hiện có trên mạng khi nói về tràn DHCP trên DrayTek thường gắn liền trực tiếp với các mã lỗ hổng bảo mật đã công bố, ví dụ CVE-2024-51138 và CVE-2024-51139 (tràn bộ đệm/tràn số nguyên trong xử lý URL dẫn tới thực thi mã từ xa không xác thực – RCE) hoặc CVE-2024-41335/41336 (lộ mật khẩu quản trị dạng văn bản thô). Đây đều là các lỗ hổng thật đã được ghi nhận, nhưng cần lưu ý: các CVE này về bản chất là lỗ hổng RCE/lộ thông tin, không phải nguyên nhân trực tiếp và duy nhất gây tràn DHCP. Việc gộp chung hai vấn đề này khiến nhiều người đọc hoang mang không cần thiết. Trên thực tế, tràn DHCP có thể xuất phát từ 3 nhóm nguyên nhân hoàn toàn khác nhau:

  1. Tấn công có chủ đích (DHCP Starvation Attack):kẻ tấn công dùng công cụ giả lập hàng loạt địa chỉ MAC ảo, gửi liên tục yêu cầu DHCP Discover để chiếm hết toàn bộ pool trong vài phút, khiến thiết bị hợp pháp không còn IP để dùng. Đây là kỹ thuật tấn công lớp 2 đã được biết đến từ lâu trong an ninh mạng, không phụ thuộc vào một lỗ hổng CVE cụ thể nào của router.
  2. Cấu hình sai (lease time quá dài hoặc pool quá nhỏ):nếu quản trị viên đặt lease time 7 ngày cho một mạng có nhiều thiết bị di động (laptop khách, điện thoại nhân viên ra vào liên tục) nhưng pool chỉ cấu hình 50 địa chỉ, pool sẽ nhanh chóng bị lấp đầy bởi các lease “chết” – thiết bị đã rời khỏi mạng từ lâu nhưng IP chưa được giải phóng vì lease time còn hiệu lực.
  3. Quá tải hợp pháp:văn phòng phát triển thêm nhiều thiết bị IoT (camera, máy chấm công, loa thông minh), mạng WiFi khách mở cho nhiều lượt truy cập mỗi ngày – tổng số thiết bị thực tế đã vượt quá thiết kế pool ban đầu.

Bảng dưới đây giúp phân biệt nhanh 3 nhóm nguyên nhân dựa trên dấu hiệu quan sát được:

Dấu hiệu quan sátDo tấn công (DHCP Starvation)Do cấu hình saiDo quá tải hợp pháp
Tốc độ pool bị lấp đầyRất nhanh (vài phút)Chậm, tăng dần theo ngàyTăng dần theo giờ làm việc
Số MAC lạ trong bảng DHCP leaseRất nhiều MAC không quen, dạng ngẫu nhiênÍt MAC lạ, chủ yếu là thiết bị quenNhiều MAC quen (điện thoại, IoT đã biết)
Router có dấu hiệu treo/khởi động lại liên tụcCó thể có, nếu đi kèm khai thác lỗ hổng RCEHiếm khi xảy raKhông xảy ra
Hướng xử lý ưu tiênChặn truy cập quản trị từ WAN, cập nhật firmware, xem log tấn côngĐiều chỉnh lease time, mở rộng poolChia VLAN riêng, mở rộng pool theo nhu cầu thực tế

Cách kiểm tra DHCP pool trên DrayTek đang đầy hay không?

Trước khi đưa ra kết luận, cần xác nhận thực tế pool có đang cạn hay không:

  • Qua Web GUI:đăng nhập giao diện quản trị DrayTek, vào mục Online Status hoặc DHCP Table (tùy dòng sản phẩm và phiên bản firmware, tên mục có thể khác nhau). Danh sách hiển thị sẽ cho thấy số lượng IP đã cấp (leased) so với tổng dung lượng pool đã cấu hình trong LAN > DHCP Server Configuration.
  • Qua CLI (Telnet/SSH): với các dòng hỗ trợ dòng lệnh quản trị, có thể dùng lệnh dạng `show dhcp` để xem nhanh bảng lease mà không cần mở giao diện web. Cú pháp chính xác và tên lệnh có thể thay đổi theo từng phiên bản firmware với đúng model và firmware đang sử dụng trước khi áp dụng.
  • Đối chiếu số lượng MAC trong bảng lease: nếu thấy hàng loạt MAC address lạ, không trùng với thiết bị thực tế trong văn phòng, khả năng cao đây là dấu hiệu tấn công thay vì quá tải thông thường.

Cách kiểm tra DHCP lease trên MikroTik RouterOS?

Phần lớn nội dung hiện có trên mạng về lỗi tràn DHCP chỉ tập trung vào DrayTek, trong khi rất nhiều doanh nghiệp tại Việt Nam đang dùng MikroTik cho hạ tầng mạng nội bộ. Cách kiểm tra trên RouterOS:

  • Qua Winbox (giao diện đồ họa):vào menu IP > DHCP Server > Leases, xem danh sách các lease đang active, trạng thái “bound” (đã cấp) hay “waiting” (đang chờ). Vào IP > Pool để xem tổng dung lượng pool đã cấu hình so với số lease hiện tại.
  • Qua Terminal (dòng lệnh):dùng lệnh `/ip dhcp-server lease print` để xem toàn bộ danh sách lease kèm MAC address và thời gian hết hạn; dùng `/ip pool print` để kiểm tra dải IP đã cấu hình; dùng `/ip dhcp-server print` để xem lease-time đang áp dụng.
  • Khi pool cạn, RouterOS thường ghi log dạng cảnh báo hết địa chỉ khả dụng trong dải pool đã cấu hình – có thể xem trong Log > kiểm tra các dòng liên quan đến DHCP để xác nhận thời điểm pool bắt đầu bị lấp đầy.

Cách xử lý khẩn cấp khi router không cấp IP

Trong lúc chưa xác định rõ nguyên nhân gốc rễ, có thể áp dụng ngay các bước sau để khôi phục kết nối tạm thời:

  1. Release lease đã hết hạn nhưng chưa được giải phóng: trên DrayTek vào DHCP Table và xóa các lease không còn thiết bị sử dụng; trên MikroTik dùng lệnh xóa lease cụ thể trong danh sách Leases.
  2. Khởi động lại riêng dịch vụ DHCP (nếu router hỗ trợ) thay vì reboot toàn bộ router, tránh làm gián đoạn các kết nối khác đang hoạt động ổn định.
  3. Với thiết bị cần kết nối gấp, gán IP tĩnh tạm thời nằm ngoài dải DHCP pool để không tranh chấp địa chỉ.

Các bước trên chỉ là giải pháp tạm – nếu nguyên nhân gốc rễ không được xử lý, tình trạng tràn pool sẽ lặp lại sau vài giờ hoặc vài ngày.

Xử lý dứt điểm theo từng nguyên nhân

Nếu xác định là tấn công (DHCP Starvation/khai thác lỗ hổng):

  • Vô hiệu hóa truy cập quản trị từ WAN (tắt HTTP/HTTPS/Telnet management trên cổng WAN), chỉ cho phép quản trị từ mạng LAN nội bộ hoặc qua VPN.
  • Cập nhật firmware lên phiên bản mới nhất theo khuyến nghị chính hãng ngay khi có thông báo vá lỗi (đây là bước bắt buộc, không thể bỏ qua nếu đã xác nhận router thuộc dòng bị ảnh hưởng).
  • Bật DHCP Snooping trên switch (nếu switch hỗ trợ) để chỉ cho phép các cổng được chỉ định đóng vai trò DHCP server hợp lệ, ngăn thiết bị lạ giả mạo DHCP server hoặc tạo lượng lớn yêu cầu giả.

Nếu xác định là cấu hình sai:

  • Giảm lease time xuống mức phù hợp với đặc điểm mạng – mạng có nhiều thiết bị di động ra vào nên dùng lease time ngắn (vài giờ) để nhanh giải phóng IP; mạng có thiết bị cố định (máy tính bàn, camera) có thể dùng lease time dài hơn.
  • Mở rộng dải pool nếu số lượng thiết bị thực tế đã vượt thiết kế ban đầu, đồng thời rà soát để loại bỏ các dải IP đã cấp cố định (static/reserved) nằm trùng trong pool DHCP gây lãng phí địa chỉ.

Nếu xác định là quá tải hợp pháp:

  • Chia VLAN riêng cho từng nhóm thiết bị (mạng nhân viên, mạng khách, mạng IoT/camera) để mỗi VLAN có pool DHCP độc lập, tránh một nhóm thiết bị chiếm hết tài nguyên của nhóm khác.
  • Cân đối lại giữa việc mở rộng pool ngay trên router hiện tại và việc nâng cấp hạ tầng (router có khả năng quản lý nhiều VLAN/pool tốt hơn) – đây là đánh đổi giữa chi phí thấp trước mắt và khả năng mở rộng dài hạn.

Làm sao để phòng ngừa tràn DHCP tái diễn?

  • Bật DHCP Snooping và port security trên switch để ngăn thiết bị lạ giả mạo DHCP server hoặc tạo yêu cầu hàng loạt.
  • Đặt lịch rà soát bảng lease định kỳ (hàng tuần hoặc hàng tháng tùy quy mô mạng) để phát hiện sớm dấu hiệu bất thường trước khi pool cạn hoàn toàn.
  • Theo dõi thông báo PSIRT/bản vá bảo mật từ hãng router đang sử dụng và cập nhật firmware đúng lịch, không chờ đến khi xảy ra sự cố.
  • Thiết kế pool DHCP có biên dự phòng hợp lý (không cấu hình sát khít với số thiết bị hiện tại) để có khoảng đệm khi doanh nghiệp phát triển thêm thiết bị mới.

Khi nào nên gọi kỹ thuật viên thay vì tự xử lý?

Các bước kiểm tra và điều chỉnh cơ bản ở trên phù hợp với mạng quy mô nhỏ, ít VLAN. Nên tìm hỗ trợ kỹ thuật chuyên môn khi: nghi ngờ đây là tấn công có chủ đích (số MAC lạ tăng bất thường, router có dấu hiệu bị truy cập từ xa không rõ nguồn gốc); hệ thống mạng đã được chia nhiều VLAN phức tạp và việc điều chỉnh sai có thể ảnh hưởng dây chuyền tới các thiết bị khác; hoặc đã áp dụng đúng các bước xử lý dứt điểm nêu trên nhưng tình trạng vẫn lặp lại sau một thời gian ngắn.

Gọi kỹ thuật viên Ánh Nhật Telecom kiểm tra router ngay

Câu hỏi thường gặp

Router không cấp IP cho thiết bị mới thì nên làm gì đầu tiên?
Kiểm tra ngay bảng DHCP lease (Online Status/DHCP Table trên DrayTek, hoặc IP > DHCP Server > Leases trên MikroTik) để xác nhận pool có đang đầy hay không, trước khi thử reboot toàn bộ router – reboot chỉ giải quyết tạm thời và có thể làm mất dữ liệu log cần thiết để chẩn đoán nguyên nhân.
Tràn DHCP có phải luôn do bị tấn công không?
Không. Như đã phân tích ở phần nguyên nhân, tràn DHCP có thể do tấn công DHCP Starvation, do cấu hình sai (lease time/pool size), hoặc do quá tải hợp pháp từ số lượng thiết bị thực tế tăng lên. Cần đối chiếu số MAC lạ và tốc độ pool bị lấp đầy để phân biệt trước khi kết luận.
Lease time DHCP nên đặt bao lâu là hợp lý?
Không có một con số cố định áp dụng cho mọi mạng – cần dựa vào đặc điểm thiết bị: mạng có nhiều thiết bị di động ra vào liên tục (khách, nhân viên dùng điện thoại cá nhân) nên dùng lease time ngắn để nhanh giải phóng IP; mạng có thiết bị cố định (máy tính bàn, camera, máy chấm công) có thể dùng lease time dài hơn để giảm tải xử lý DHCP không cần thiết. [CẦN XÁC NHẬN SỐ LIỆU THẬT] với quy mô mạng cụ thể trước khi áp dụng một con số chính xác.
MikroTik báo hết pool (no more addresses) nghĩa là gì?
Thông báo này nghĩa là toàn bộ dải IP đã cấu hình trong IP > Pool đã được cấp hết cho các thiết bị (kể cả lease chưa hết hạn dù thiết bị đã ngắt kết nối), không còn địa chỉ nào để cấp cho yêu cầu DHCP Discover mới – cần kiểm tra danh sách Leases để xóa lease không còn dùng hoặc mở rộng dải pool.
Đổi router khác có giải quyết được lỗi tràn DHCP không?
Không nhất thiết. Nếu nguyên nhân là cấu hình sai hoặc quá tải hợp pháp, đổi router mới mà không điều chỉnh lại lease time/pool size hoặc không chia VLAN thì lỗi vẫn sẽ tái diễn khi số thiết bị tiếp tục tăng. Đổi router chỉ thực sự cần thiết khi thiết bị hiện tại không đủ khả năng quản lý nhiều VLAN/pool hoặc đã lỗi thời không còn được hãng phát hành bản vá bảo mật.

Bài viết liên quan