Hướng dẫn thực hành · MikroTik

Trong trang này

Kiểm thử thủ công toàn hệ thống

Làm theo thứ tự dưới đây. Mỗi bài có điều kiện, thao tác, kết quả mong đợi và cách khôi phục. Tạo kết nối mới khi đổi WAN/WARP; một phiên TCP cũ bị rớt không tự chứng minh failover lỗi.

Nếu kết quả chưa đạt, chạy chẩn đoán nhanh để thu thập trạng thái không xuất token/khóa.

1. Ghi baseline trước khi gây sự cố

Ghi model, RouterOS, sơ đồ cổng, WAN chính/phụ, LAN/VLAN, chế độ routing, QoS và kênh bot. Chụp/ghi counter trước khi test nhưng che IP public, tài khoản và dữ liệu khách hàng nếu chia sẻ. Không xuất Source chứa token/private key.

/system resource print
/interface pppoe-client print
/ip route print where dst-address=0.0.0.0/0
/system scheduler print
/ip firewall mangle print stats
/ip firewall filter print stats
/queue tree print stats
/queue simple print stats

Đạt: đúng tên interface, route active theo thiết kế, CPU bình thường, scheduler chỉ bật nhóm đã chọn. Nếu không đạt: sửa baseline trước, chưa ngắt WAN hay tạo loop.

2. LAN, DNS, VLAN và firewall

Trên máy LAN, renew DHCP: Windows dùng ipconfig /release rồi ipconfig /renew; macOS vào cấu hình mạng TCP/IP, Renew DHCP Lease. Kiểm tra IP/subnet/gateway/DNS thuộc cấu hình vừa tạo. Mở web HTTPS bình thường và phân giải domain.

Trên router:

/ip dhcp-server lease print
/ping 1.1.1.1 count=5
:put [:resolve "example.com"]

Nếu có VLAN, nối máy vào SSID/port đã được AP/switch tag đúng VLAN, renew DHCP. Kiểm tra nhận subnet VLAN, ra Internet được và không vào LAN/VLAN bị cấm. Dùng một dịch vụ biết chắc đang mở trên host đích để test cách ly; ping thất bại có thể chỉ do firewall host. Ma trận chỉ định chiều khởi tạo; established reply được phép.

Đạt: DHCP/DNS đúng, Internet chạy trên từng mạng, truy cập bị chặn/cho phép đúng ma trận. Khôi phục: đưa máy lại SSID/cổng LAN quản trị; không bật bridge VLAN filtering toàn bộ chỉ để chữa sai tag ở AP.

3. Mỗi WAN và failover

Điều kiện: quản trị tại chỗ, có mạng còn lại đã xác nhận tốt. Với một WAN duy nhất, chấp nhận cả mạng mất Internet trong thời gian test. Không test bằng cách rút dây LAN quản trị.

  1. Ghi tên pppoe-out1/pppoe-out2 và port vật lý thật. Kiểm tra từng PPPoE connected.
  2. Ngắt cáp giữa WAN1 và ONT hoặc disable đúng PPPoE thử nghiệm; cách này có tác động toàn bộ khách trên đường đó. Không rút cả ONT dùng chung nhiều VLAN nếu muốn test riêng một PPPoE.
  3. Quan sát PPPoE/route, mở kết nối HTTPS mới từ máy LAN. PCC/ECMP/failover phải dùng đường còn lại khi có route fallback tương ứng.
  4. Cắm lại hoặc enable PPPoE, chờ connected/route active; tạo phiên mới và xác nhận mạng ổn.
  5. Lặp lại cho WAN2 và WAN3/4 nếu generator có tạo. Bot giám sát tối đa 4 WAN đã khai báo; lặp lại cả test mất mạng, phục hồi và các nhóm mở rộng cho từng WAN.

Ví dụ thao tác chỉ dành cho WAN1 đã xác định, chạy riêng, không dán cả hai cùng lúc:

/interface pppoe-client disable [find where name="pppoe-out1"]

Khôi phục:

/interface pppoe-client enable [find where name="pppoe-out1"]

Đạt: mất một WAN không mất các phiên mới qua WAN còn khỏe; hồi phục route theo chính sách. Với một WAN, mất Internet là dự kiến. Không đạt: xem route main/to-wan, probe pinned, gateway/target-scope và mangle, không thay nhiều rule cùng lúc.

Để kiểm tra “PPPoE vẫn connected nhưng ISP mất Internet”, chỉ trên đường/lab có thể kiểm soát upstream: ngắt kết nối upstream sau thiết bị vẫn giữ phiên PPPoE, hoặc dùng công cụ lab gây mất reachability. Xác nhận PPPoE còn connected mà recursive probe không trả lời, route chính inactive. Không có mô hình này thì ghi “chưa test blackhole upstream”; tắt PPPoE không thay bài đó.

4. Test sender mà không gây mất mạng

Sau khi cài nhóm mở rộng, chạy nguyên khối sau. Nó chỉ gửi một tin có nhãn TEST, không giả lập CPU/loop thật:

{ /system script run network-alert-config; :global netAlertSend; :put [$netAlertSend serviceName="manual-test" alertTitle="TEST MIKROTIK" alertBody="Kiem tra gui canh bao thu cong, khong phai su co."] }

Đạt: kết quả true/thành công và chat thực nhận tin. Không đạt: xem log NET-ALERT; kiểm tra kênh/token/Chat ID/CA theo trang bot. Chạy script network-alert-router khi CPU bình thường không buộc phải có tin.

5. DOWN, phục hồi và báo bù

  1. Hoàn tất sender test. Ghi run-count scheduler pppoe-monitor-every-3m và giờ bắt đầu.
  2. Ngắt một WAN giám sát như mục 3, giữ WAN còn lại tốt. Đợi đủ ba chu kỳ lỗi, thường 6–9 phút; xem log fail count và tin DOWN. Ngưỡng ba lần là ba lần script đo, không chỉ ba gói ping.
  3. Khôi phục WAN, chờ lần monitor tiếp theo. Chat phải nhận tin phục hồi có đúng WAN; nhóm WAN nghỉ thêm 5 phút theo config để tránh báo dồn.
  4. Nếu thử lại trong cùng ngày, DOWN có thể bị giới hạn một lần/ngày/WAN. Chỉ trong lab và sau khi đóng sự cố thật mới dùng reset state bên dưới. Không thay interval production để rút ngắn rồi quên trả về.
/system script run pppoe-monitor-reset

Test báo bù: trong thời gian bảo trì, ngắt tất cả WAN nhưng giữ router có điện. Đợi đủ chu kỳ ghi sự cố, không reboot. Chat không thể nhận khi router offline. Khôi phục mạng, chờ monitor; phải có báo bù/recovered-late theo state. Reboot lúc đang offline sẽ làm mất state RAM, không thể đòi lịch sử outage chính xác.

Khôi phục: enable/cắm lại mọi WAN đã thử, xác nhận connected, đúng interval 3m và không còn cảnh báo mở chưa xử lý. Không kết luận mất điện có cảnh báo ngay bằng bài này.

6. Scheduler, reboot, CPU, RAM và WAN quality

Đợi ít nhất hai chu kỳ Scheduler, kiểm tra run-count tăng và log không có lỗi quyền; dùng cùng user/owner của installer. Terminal admin chạy được chưa chứng minh scheduler chạy được.

Nếu có cửa sổ bảo trì, reboot bằng System > Reboot sau khi backup. Router phải lên mạng và gửi một thông báo reboot thành công trong 10 phút đầu; không lặp mỗi phút sau đó. Nếu Internet/CA chưa sẵn sàng trong 10 phút, ghi giới hạn đó thay vì coi sender hỏng.

CPU/RAM/storage không nên test bằng flood trên mạng đang phục vụ. Trong lab, ghi ngưỡng gốc ở network-alert-config, giảm ngưỡng để tạo điều kiện cảnh báo, chạy đúng số mẫu cần thiết, rồi trả lại ngưỡng gốc và xác nhận tin recovery. Config được nạp lại mỗi lần chạy: thay một global tạm ngoài Source có thể bị ghi đè và không tạo bài test hợp lệ. Nếu chỉ gửi TEST sender thì chưa test logic threshold.

Quality/link được đo mỗi 5 lần nhóm WAN chạy; CGNAT mỗi 60 lần. So sánh với ping/counter độc lập cùng WAN. traffic-gen=no có thể chặn flood-ping: lúc đó chỉ đánh giá loss, không ghi latency đã đạt. Không thử bật quyền này từ xa hoặc gây link flap trên dây đang phục vụ để lấy tin mẫu.

Đạt: chu kỳ và ngưỡng đúng config, không gửi dồn sau phục hồi, state không bị mất giữa các lần lịch. Khôi phục: trả mọi ngưỡng, interval và cổng như baseline; ghi bài nào chưa thực hiện.

7. Loop Protect và DHCP lạ: chỉ thử trên mạng lab

Không nối vòng hai cổng trên mạng sản xuất. Dùng router/switch lab tách mạng, giữ cổng quản trị riêng và bật Loop Protect trên đúng cổng thử. Tạo vòng ngắn trong lab, quan sát /interface ethernet print detail có loop-protect-status=disable, chạy/đợi nhóm LAN Security; chat phải nêu đúng cổng. Tháo vòng ngay, chờ hết disable-time và kiểm tra link hoạt động. RSTP có thể chặn trước Loop Protect: khi đó không đạt điều kiện gửi của detector, không được ép bằng tắt RSTP trên mạng thật.

DHCP lạ: trong lab có detector đúng interface và Valid Servers đúng, bật một DHCP server phụ không nằm allowlist. Chờ detector tìm thấy, kiểm tra IP/MAC/interface trong tin. Tắt server phụ, kiểm tra thiết bị nhận lease từ server hợp lệ. Không bật DHCP giả trên LAN sản xuất; detector chỉ cảnh báo, không ngăn lease sai.

Đạt: sự kiện vật lý được quan sát và tin đúng dữ kiện. Khôi phục: tháo vòng, tắt DHCP phụ, trả port/lease về baseline. Một tin TEST thủ công không thay hai bài detector này.

8. WARP bình thường, mất tunnel và quay về WAN

Điều kiện: mục 1–5 đạt, WARP đã cài và có handshake. Trong WireGuard > Peers, xem handshake/Rx/Tx; đọc Netwatch và counter:

/tool netwatch print detail where comment="WARP-Watchdog"
/ip firewall mangle print stats where comment~"WARP"
/ping 1.1.1.2 count=5

Mở lại Telegram/domain trong WARP_LIST và một web ngoài danh sách. Counter mark/NAT WARP phải tăng chỉ với đích chọn; web thường vẫn đi WAN. Test tin bot từ router riêng với test trên máy LAN, vì chúng dùng output/prerouting khác nhau.

Trong cửa sổ bảo trì, tắt riêng peer WARP:

/interface wireguard peers disable [find where interface=wg-warp]

Chờ Netwatch down (sau startup delay nếu mới khởi động), kiểm tra rule Mark WARP disabled, web thường vẫn ra WAN. Đích bị ISP chặn có thể vẫn không dùng được dù fallback đúng; ghi kết quả routing và khả năng truy cập tách biệt.

Khôi phục:

/interface wireguard peers enable [find where interface=wg-warp]

Chờ handshake và canary up, xác nhận rule Mark được bật lại. Đóng/mở ứng dụng để có kết nối mới qua WARP; không xóa toàn bộ connection tracking. Đạt: tunnel down/up không phá LAN/DHCP/PCC, routing hoạt động như mô tả và tin bot phù hợp đường ra thực tế.

9. QoS, PCQ, port-forward và nghiệm thu

QoS: dùng cùng máy LAN, cùng server test, cùng WAN, so sánh ping khi rảnh và lúc tải download/upload. Xem queue counter tăng, tốc độ gần giới hạn đã chọn và /tool profile cpu=all. Dừng tải nếu CPU bão hòa/mạng bị ảnh hưởng. Không chạy bandwidth-test trên chính router rồi dùng đó làm kết luận throughput chuyển tiếp.

PCQ: hai máy/IP cùng LAN chính chạy tải riêng; tổng các kết nối của mỗi IP chia giới hạn IP đó. VLAN không nằm target LAN chính. Với WARP, bật giới hạn download riêng để gói giải mã được mark warp-download, rồi thực hiện bài đo dưới đây. Không dùng counter download-wanN để kết luận QoS của tunnel.

Port-forward: từ điện thoại tắt Wi-Fi, dùng 4G/5G, thử IP WAN public/DDNS và port đã chọn. Server nội bộ phải đang lắng nghe, gateway đúng, firewall host cho phép. Thử hairpin từ LAN riêng. Nếu CGNAT, không đánh dấu đạt chỉ vì DDNS đã cập nhật.

Sau mọi bài: mọi WAN/peer được enable lại, lịch/ngưỡng đúng, không còn loop/DHCP phụ, trạng thái WARP đã hồi phục hoặc được gỡ đúng quy trình. Sao lưu bản cuối ra máy và ghi biên bản:

Mục Kết quả cần ghi
Thiết bị Model, RouterOS, RouterBOOT, ngày/người test.
Mạng nền LAN, từng VLAN, DNS, WAN1–4 đã thử và chính sách routing.
Bot Kênh chọn, sender, DOWN/recovery/báo bù, lịch/reboot. Không ghi token.
Nhóm mở rộng Threshold, quality, LOOP, DHCP; bài chưa làm ghi rõ.
WARP Handshake, counter LAN/router, down/up, fallback, trường hợp ISP chặn.
Hiệu năng Máy/server/WAN dùng đo, speed, latency, CPU, counter queue.
Khôi phục Tên bản backup riêng tư, các tính năng đã bật và các hạn chế còn lại.

11. Nghiệm thu queue WARP và khôi phục

Điều kiện: handshake ổn, nền LAN/WAN đã đạt; dùng một máy LAN, một máy chủ tải, kết nối có dây và cùng khung giờ cho các lượt đo. Ghi model/RouterOS, ISP hiện dùng, mức queue, CPU, throughput và ping khi tải.

  1. Tải một đích trong WARP_LIST với kết nối mới. Đo baseline khi chưa có giới hạn; không coi kết quả một lần Speedtest là tốc độ ổn định của mọi dịch vụ.
  2. Bật QoS WARP, ví dụ 80 Mbps khi baseline duy trì trên mức này. Lặp cùng phép tải 60 giây. Counter mangle WARP QoS Download và queue WARP Download phải tăng; tốc độ trung bình không vượt đáng kể mức cấu hình sau thời gian ổn định. Burst ngắn và sai số lớp giao thức có thể xuất hiện.
  3. Cùng lúc xem CPU, ping tới máy chủ kiểm thử. So sánh với baseline; CPU sát 100% hoặc throughput thấp khi queue chưa chạm trần có thể là giới hạn thiết bị/tunnel, không phải bằng chứng QoS hiệu quả.
  4. Mở một đích ngoài WARP_LIST bằng kết nối mới: queue WARP không được tăng do riêng lượt tải này. Đóng các ứng dụng khác để tránh nhầm traffic nền. Nếu CDN chung IP, chọn máy chủ khác có IP tách biệt.
  5. Chuyển WAN theo bài failover rồi đo lại. Mức giới hạn WARP không tự đổi theo WAN đang chạy. Với PCQ bật, thử một và hai IP để phân biệt giới hạn mỗi IP với giới hạn tunnel tổng.
  6. Test mất tunnel: watchdog down/up, queue vẫn tồn tại; traffic fallback WAN dùng QoS nền, không mang mark warp-download. Khi hồi phục, tạo kết nối mới rồi kiểm tra counter queue WARP tăng lại.

Đọc counter không lộ khóa:

/ip firewall mangle print stats where comment="WARP QoS Download"
/queue tree print stats where name="WARP Download"
/system resource print

Để so sánh A/B trên router đã có queue, chỉ tạm tắt queue WARP; mark vẫn tồn tại nhưng không giới hạn bởi queue này. Ghi lại trạng thái trước test và bật lại sau đo:

/queue tree disable [find where name="WARP Download"]

/queue tree enable [find where name="WARP Download"]

Nếu cần gỡ riêng QoS WARP, giữ tunnel hoạt động:

{
/ip firewall mangle remove [find where comment="WARP QoS Download"]
/queue tree remove [find where name="WARP Download"]
/queue type remove [find where name="warp-fq-codel"]
}

Đạt: download WARP khớp queue, đích ngoài danh sách không bị queue này giữ lại, CPU chấp nhận được, failover/gỡ QoS không phá mạng nền. Nếu chưa đo thì ghi “chưa kiểm chứng”, không đánh dấu checklist từ việc sinh RSC thành công.