Topology mạng Homelab

Tóm tắt

Tài liệu trung tâm mô tả toàn bộ topology vật lý và logic của mạng homelab: modem ISP ở chế độ bridge → router MikroTik RB3011 (10.0.0.1) → các thiết bị LAN gồm WiFi AP Grandstream GWN7660, Raspberry Pi (home server), máy chủ Ergo (Intel N2808), máy in Canon LBP6230DN. Có kế hoạch cấp IP (10.0.0.2-99 hạ tầng, 10.0.0.100-199 DHCP client), danh sách dịch vụ chạy trên từng máy chủ, và một change log chi tiết ghi lại các thay đổi từ 2025-12-31 đến 2026-07-14 — đây là nguồn thông tin mới nhất và đầy đủ nhất về trạng thái hiện tại của homelab.

Điểm chính

• Kiến trúc: Internet → Modem GPON Huawei HG8145V5-20 (Viettel) (bridge) → MikroTik RB3011 (gateway/DHCP/NAT) → bridge LAN phẳng nối GWN7660 (AP), Raspberry Pi, Ergo, Canon LBP6230DN. Ngày 2026-08-17 đã thử đổi WAN sang GPON SFP rồi hoàn tác — xem phần “Thử nghiệm đổi WAN sang GPON SFP” bên dưới.
• Kế hoạch IP: .1 gateway, .2-.99 hạ tầng (reservation), .100-.199 DHCP pool động, .200-.254 dự trữ. Theo change log, Pi và máy in đã di chuyển từ dải DHCP động sang IP tĩnh trong dải hạ tầng (Pi: .200→.22, máy in: .130→.23).
• Raspberry Pi (10.0.0.22) chạy: WireGuard VPN (wg-easy, cổng UDP 51820, mạng VPN 10.8.0.0/24) — đã mất từ lần cài lại hệ điều hành, luật port-forward tương ứng đã gỡ khỏi router ngày 2026-09-04, xem phần cập nhật cuối trang —, MiniDLNA, Vibe Companion (Claude Code Web UI) qua Cloudflare Tunnel — đã ngừng dùng, xem phần xác minh bên dưới —, Rclone Bisync đồng bộ ~/chats với Google Drive mỗi 5 phút, AdGuard Home (DNS chặn quảng cáo toàn mạng), và một site WordPress.
• Máy chủ Ergo (Intel N2808, Ubuntu Server, 10.0.0.24) chạy CUPS print server cho Canon LBP6230DN (có AirPrint qua Avahi/mDNS) và một Vibe Companion khác qua Cloudflare Tunnel riêng.
• Cả Pi và Ergo dùng Cloudflare Tunnel để expose dịch vụ ra ngoài mà không cần mở cổng trên router. Từ 2026-09-04, đây là cách duy nhất — router không còn cổng inbound nào mở từ WAN.
• Firewall MikroTik: policy mặc định DROP cho input từ WAN, ACCEPT cho LAN; NAT chỉ còn masquerade (port-forward WireGuard đã gỡ 2026-09-04); fasttrack chạy ở phần mềm — cờ hw-offload=yes từng đặt trong luật là vô nghĩa trên phần cứng này, xem phần nâng cấp RouterOS bên dưới.
• Theo change log gần nhất (2026-07-14): Pi đã cài lại hệ điều hành (Ubuntu 26.04), đổi user iam→_; các dịch vụ trước đó (wg-easy, MiniDLNA, Companion, rclone bisync) chưa được xác nhận còn tồn tại sau khi cài lại — tài liệu tự ghi chú các mục này “có thể đã lỗi thời”.
• Có vấn đề đã biết trên Ergo: thiếu thư viện libcupsimage.so.2 trên Ubuntu 24.04 (khắc phục bằng symlink), và chứng chỉ TLS CUPS phải có địa chỉ IP trong SAN thì iOS AirPrint mới gửi được lệnh in.

Xác minh trực tiếp qua SSH (2026-07-23)

Đăng nhập trực tiếp vào router (home:mik3011) và Pi (home:pi) để đối chiếu tài liệu với trạng thái thực tế. Kết quả:

• RouterOS/RouterBoard: xác nhận cả hai đều ở 7.20.6, khớp với current-firmware = upgrade-firmware (không còn treo bản nâng cấp dở dang).
• DHCP: Pi (10.0.0.22) và các thiết bị hạ tầng khác vẫn giữ đúng reservation như tài liệu mô tả.
• Pi đã cài lại hệ điều hành: xác nhận đang chạy Ubuntu 26.04 (kernel 7.0.0-1014-raspi), user hiện tại là _ — khớp change log 2026-07-14.
• wg-easy / WireGuard trên Pi: không còn — không có container hay tiến trình nào lắng nghe cổng 51820 trên Pi. NAT trên router vẫn còn luật port-forward UDP 51820 → 10.0.0.22, nhưng luật này hiện trỏ vào một dịch vụ không tồn tại (port forward “chết”).
• Thử nghiệm WireGuard native trên router: phát hiện một địa chỉ IP 10.13.13.1/24 gắn với interface nội bộ *11, đang bị đánh dấu invalid, cùng 2 peer definition mồ côi (tên “Opera” và “minuet”, subnet 10.13.13.0/24). Điều này cho thấy đã có một lần thử chuyển WireGuard chạy ngay trên router (như gợi ý “future option” trong huong-dan-nang-cap-routeros-6-len-7) nhưng interface đã bị xoá sau đó, để lại record rác — WireGuard hiện không hoạt động ở cả hai nơi (Pi lẫn router). Đã dọn 2026-08-17: xoá địa chỉ 10.13.13.1/24 và cả 2 peer mồ côi. Địa chỉ này đáng chú ý vì khi tạo interface vlan35-sfp trong phiên thử nghiệm GPON SFP, RouterOS tự gán lại bản ghi mồ côi vào interface mới (tham chiếu theo ID nội bộ), khiến nó chuyển từ invalid sang đang hoạt động trên một interface không liên quan — bài học: record mồ côi trỏ vào *<id> không vô hại, nó có thể tái sinh trên interface tạo sau. Public key của 2 peer đã lưu ở raw/wireguard-peers-orphan-20260817.txt (private key nằm phía client nên các thiết bị cũ vẫn dùng lại được nếu dựng lại VPN).
• MiniDLNA: gói minidlna không được cài trên hệ điều hành mới của Pi — dịch vụ này đã mất hẳn sau khi cài lại, không chỉ “chưa xác nhận”.
• Vibe Companion + cloudflared (bản host, theo vibe-companion-va-cloudflare-tunnel-tren-raspberry-pi): không còn tồn tại ở tầng hệ điều hành (the-companion, cloudflared đều not found). Riêng Cloudflare Tunnel cho WordPress vẫn hoạt động, nhưng chạy dưới dạng container Docker (wp_nguyenbinhson_com_cloudflared) chứ không phải binary cài trực tiếp như tài liệu companion mô tả. Cập nhật 2026-08-03: Companion trên Pi đã được chủ hệ thống xác nhận ngừng dùng hẳn, không có kế hoạch dựng lại (kiểm tra lại qua SSH: không có unit, không có tiến trình, không có bun/bunx, cổng 3456 trống, domain companion.nguyenbinhson.com không còn phân giải). Ngược lại, cloudflared đã được cài lại ở tầng hệ điều hành sau lần kiểm tra 2026-07-23 — nay phục vụ SSH và AdGuard DoH, xem ssh-vao-pi-qua-cloudflare-tunnel-va-access.
• Rclone Bisync: rclone không còn được cài — đồng bộ Google Drive đã ngừng từ khi cài lại hệ điều hành.
• AdGuard Home: container adguardhome đang chạy ổn định (uptime 9 ngày), bind DNS tại 10.0.0.22:53. Tuy nhiên router vẫn cấu hình DNS trực tiếp 1.1.1.1/8.8.8.8 — xác nhận LAN client chưa được trỏ qua AdGuard, đúng như ghi chú “setup wizard pending” trong change log.
• WordPress stack: vẫn chạy ổn định (app + MariaDB + Redis + cloudflared, uptime ~2 tuần).

Dịch vụ mới trên Pi (2026-08-03)

• Ổ cứng ngoài purple (Buffalo 1TB, exFAT) gắn cố định tại /mnt/purple qua /etc/fstab, tự ngủ sau 10 phút rảnh nhờ hd-idle — xem o-cung-ngoai-purple-tren-raspberry-pi.
• Samba (SMB) file server chia sẻ /mnt/purple thành share purple, chỉ trong LAN 10.0.0.0/24, bắt buộc SMB3 có mã hoá, quảng bá qua mDNS (avahi-daemon) nên hiện trong Finder với tên pi. Client dùng: Infuse trên iPhone/iPad và Finder/VLC trên MacBook. Cổng 445, không mở ra Internet.

Thử nghiệm đổi WAN sang GPON SFP (2026-08-17, đã hoàn tác)

Trạng thái cuối ngày: đã trả về hộp modem Huawei. Con SFP đã rút khỏi khe (sfp1 báo sfp-module-present: no), sợi quang cắm lại vào hộp Huawei, pppoe-out trên ether1 đang chạy — WAN hiện tại vẫn là đường qua hộp Huawei như trước. Lý do hoàn tác: đường qua SFP chập chờn theo chu kỳ 5–10 phút, không dùng thật được.

Phần dưới ghi lại cấu hình đã chạy được, để lần sau muốn thử lại thì không phải mò lại từ đầu.

Trong lúc thử nghiệm, hộp Huawei được rút hẳn khỏi đường truyền (rút nguồn, cáp khỏi ether1), sợi quang cắm trực tiếp vào GPON SFP Nokia G-010S-A trong khe sfp1, và router tự quay PPPoE.

Kiến trúc WAN khi đó:

Internet → OLT Viettel → sợi quang → GPON SFP Nokia (khe sfp1, SFU trong suốt)
         → vlan35-sfp (VLAN 35 có tag trên sfp1)
         → pppoe-sfp (PPPoE, user h004_ftth_sonnb9)
         → RB3011 → bridge LAN phẳng

Khác biệt so với đường qua hộp Huawei: hộp Huawei là HGU, tự map LAN↔VLAN 35 nội bộ nên RB3011 chạy PPPoE untagged trên ether1. Con SFP là SFU trong suốt nên RB3011 phải tự gắn tag VLAN 35.

Đã thêm trên router:

/interface/vlan/add name=vlan35-sfp interface=sfp1 vlan-id=35
/interface/pppoe-client/add name=pppoe-sfp interface=vlan35-sfp \
    user=h004_ftth_sonnb9 add-default-route=yes
/interface/list/member/add list=WAN interface=pppoe-sfp
/ip/firewall/nat/add chain=srcnat action=masquerade out-interface=pppoe-sfp

Cũng thêm để quản trị con SFP (IP quản trị của nó là 192.168.1.10): địa chỉ 192.168.1.2/24 trên sfp1 và masquerade out-interface=sfp1.

pppoe-out cũ trên ether1 được giữ nguyên làm đường lùi suốt quá trình thử — nhờ vậy việc trả về hộp Huawei chỉ là cắm lại nguồn và cáp, không phải sửa cấu hình nào. Hai đường không dùng song song được: cả hai mang cùng GPON serial HWTC856220AD, mà OLT chỉ nhận một thiết bị một lúc.

Cấu hình phía router (vlan35-sfp, pppoe-sfp, thành viên interface list WAN, masquerade out-interface=pppoe-sfp) đã được gỡ hẳn ngày 2026-09-04 để dọn đường trước khi nâng cấp RouterOS — xem phần cập nhật cuối trang. Muốn thử lại thì chạy lại đúng 4 lệnh ở khối trên.

Lưu ý quan trọng — đường này chưa ổn định. PON rơi khỏi trạng thái hoạt động sau 4,6–8,8 phút rồi tự đăng ký lại sau 1,3–6,2 phút, tức mạng chập chờn theo chu kỳ 5–10 phút. Đo đạc đã chứng minh mọi chỉ số phía thiết bị đều sạch (không lỗi bit, không suy giảm quang, không lỗi OMCI) — việc ngắt là quyết định của hệ thống Viettel, không phải thứ sửa được từ nhà. Chi tiết ở gpon-sfp-nokia-g010s-a. Chưa nên coi là WAN chính.

Bẫy bảo mật đã gặp: bộ luật firewall dựa vào interface list WAN, mà RouterOS mặc định chain input là accept. Trong khoảng vài phút từ lúc pppoe-sfp lên tới lúc thêm nó vào list WAN, SSH/Winbox/HTTP của router hở ra Internet. Khi thêm WAN mới trên cấu hình kiểu này, phải thêm vào interface list ngay — xem huong-dan-tang-cuong-bao-mat-mikrotik.

IP WAN đổi mỗi lần PPPoE quay lại (đã thấy 171.224.85.173 → 117.1.96.229 → 116.101.240.67), nên DDNS e7e60fdfd0e4.sn.mynetname.net ở phần dưới càng cần thiết nếu truy cập từ xa qua đường này.

Cập nhật cấu hình (2026-07-23)

Đã bật tính năng IP Cloud DDNS built-in của MikroTik trên router (/ip cloud set ddns-enabled=yes, trước đó ở chế độ auto nhưng chưa thực sự đăng ký). Hostname được cấp: e7e60fdfd0e4.sn.mynetname.net (dựa theo serial number router), tự động trỏ theo IP WAN động hiện tại (117.7.215.102 tại thời điểm bật, đã xác minh phân giải DNS đúng). Không cần tài khoản hay cấu hình bên thứ ba — MikroTik tự cập nhật khi IP WAN đổi.

Ý nghĩa: có thể dùng hostname này thay cho IP WAN động khi cần truy cập từ xa (ví dụ cấu hình lại WireGuard endpoint một khi dịch vụ được dựng lại trên Pi — xem phần “Xác minh trực tiếp qua SSH” ở trên).

Dọn dẹp cấu hình router (2026-09-04)

Dọn sạch cấu hình chết trên RB3011 trước khi nâng cấp RouterOS. Backup đầy đủ (binary .backup + /export show-sensitive) đã lưu ở raw/backups/ và trên flash router.

Gỡ port-forward WireGuard. Chủ hệ thống quyết định không dựng lại WireGuard, chọn hướng dùng Cloudflare Tunnel cho truy cập từ xa. Đã xoá luật dstnat UDP 51820 → 10.0.0.22. Kiểm tra thêm cho thấy trên router không còn interface WireGuard, peer, hay địa chỉ 10.13.13.x nào — phần record mồ côi đã dọn từ 2026-08-17. Hệ quả: router không còn cổng inbound nào mở từ WAN; chain input drop toàn bộ từ WAN, mọi truy cập từ xa đi qua cloudflare-tunnel.

Gỡ tàn dư thí nghiệm GPON SFP. Xoá 4 đối tượng theo thứ tự phụ thuộc (bỏ tham chiếu trước, bỏ interface sau) để không sinh record mồ côi trỏ vào *<id> — đúng cái bẫy đã gặp 2026-08-17:

/ip/firewall/nat/remove [find where comment~"GPON SFP"]
/interface/list/member/remove [find where interface="pppoe-sfp"]
/interface/pppoe-client/remove [find where name="pppoe-sfp"]
/interface/vlan/remove [find where name="vlan35-sfp"]

Xác minh sau khi dọn: vlan: 0, pppoe-clients: 1, listmembers: 2, nat: 1, invalid-nat: 0; /ip/address chỉ còn 10.0.0.1/24 + IP WAN động, không có record nào tự gán vào; pppoe-out vẫn running, ping 1.1.1.1 đạt 3/3. Internet không gián đoạn.

Trạng thái bảo mật ghi nhận cùng dịp: ssh/www/winbox đều chỉ nghe từ 10.0.0.0/24; ftp, telnet, api, api-ssl, www-ssl đã tắt; chỉ một user admin. Phần hardening theo huong-dan-tang-cuong-bao-mat-mikrotik còn nguyên vẹn.

Nâng cấp RouterOS 7.20.6 → 7.24.2 (2026-09-04)

Lý do: bản đang chạy (build 2025-12-04) chậm 4 phiên bản so với stable, khoảng 9 tháng không vá — rủi ro bảo mật lớn nhất còn tồn tại trên router, lớn hơn mọi câu hỏi về chọn giao thức VPN nào.

Quy trình: /system/package/update/download → reboot (nâng RouterOS) → /system/routerboard/upgrade → reboot lần hai (nâng bootloader). Đi thẳng một bước vì cùng nhánh v7.

Kết quả xác minh sau nâng cấp: RouterOS 7.24.2, RouterBOARD firmware current = upgrade = 7.24.2; pppoe-out quay lại được (IP WAN đổi 117.1.96.187 → 116.104.11.85, IP Cloud DDNS tự cập nhật theo, status: updated); đúng 1 default route; NAT còn đúng 1 luật masquerade; 13 luật firewall nguyên vẹn với WAN input drop; lease tĩnh .21/.22/.23 còn đủ; ping 1.1.1.1 đạt 3/3, 35,9 ms. Không mất cấu hình nào.

RouterOS tự đổi 5 chỗ khi migrate

So /export trước và sau nâng cấp:

• /ip/service: thuộc tính address= đổi tên thành available-from=, giá trị 10.0.0.0/24 giữ nguyên — chỉ là đổi tên.
• Mất /port set 0 name=serial0 và /ip smb shares ... directory=/pub — cosmetic, không dùng.
• time-zone-name đổi Asia/Ho_Chi_Minh → Asia/Bangkok do time-zone-autodetect=yes tự chọn lại. Cả hai đều UTC+7 không DST, gmt-offset vẫn +07:00, giờ vẫn đúng — không ảnh hưởng.
• Mất hw-offload=yes khỏi luật fasttrack-connection. Thoạt nhìn tưởng mất tăng tốc phần cứng, thực ra là RouterOS dọn cho đúng sự thật: docs MikroTik ghi FastTrack hardware offload chỉ có trên chipset Prestera, trong khi switch chip của RB3011 là QCA-8337 (đã kiểm tra cả switch1 và switch2). Cờ này chưa bao giờ thực sự hoạt động trên máy này — mô tả “fasttrack có hardware offload” ở các phiên bản trước của tài liệu này là sai. FastTrack phần mềm vẫn chạy tốt (counter đếm 23.871 gói / 4,9 MB trong vài phút sau reboot).

Service mới cần tắt: reverse-proxy

RouterOS 7.24 thêm service reverse-proxy (TCP 443, submenu /ip/reverse-proxy) và sau nâng cấp nó tự bật, không giới hạn IP nguồn (available-from="") — lệch hẳn với mọi service khác vốn khoá 10.0.0.0/24. Nó chiếm cổng 443 được vì www-ssl đã tắt từ đợt hardening.

Đây là reverse proxy HTTPS định tuyến theo SNI: đọc tên miền trong TLS ClientHello rồi đẩy về máy nội bộ tương ứng, cho phép nhiều dịch vụ web dùng chung một IP public và một cổng 443 — thay cho việc phải dựng HAProxy/nginx/Traefik trên máy riêng. Về chức năng nó trùng với vai trò cloudflare-tunnel đang đảm nhiệm, nhưng đòi mở lại cổng 443 inbound — ngược hướng đã chọn.

Rủi ro thực tế thấp (WAN input drop chặn từ Internet; bảng /ip/reverse-proxy rỗng nên không thực sự lắng nghe — test nc 10.0.0.1 443 từ LAN cũng không mở), nhưng đã tắt cho nhất quán: /ip/service/disable reverse-proxy.

Backup

raw/backups/post-upgrade-7.24.2-20260904.{backup,rsc} là điểm restore hợp lệ từ nay. Ba bản pre-upgrade-* cùng ngày thuộc 7.20.6, giữ lại để tham chiếu nhưng không dùng restore lên 7.24.2.

Khái niệm

• mikrotik-routeros
• wireguard-vpn
• dhcp-server
• cloudflare-tunnel
• mikrotik-ip-cloud-ddns

Nguồn liên quan

• o-cung-ngoai-purple-tren-raspberry-pi — bổ sung bối cảnh máy Pi ngày 2026-08-03: ổ ngoài 1TB gắn tại /mnt/purple, danh sách dịch vụ đang chạy.
• gpon-sfp-nokia-g010s-a — thiết bị WAN hiện tại (từ 2026-08-17): điều kiện cần để hoạt động, cách quản trị, và dữ liệu về việc mất ổn định.

Người liên quan

• nguyen-binh-son

Câu hỏi mở

• Sau khi Pi cài lại hệ điều hành, các dịch vụ wg-easy, MiniDLNA, Companion, rclone bisync có được dựng lại hay không? Đã xác minh (2026-07-23): không dịch vụ nào trong 4 dịch vụ này còn tồn tại trên Pi.
• IP thực tế của Raspberry Pi trong tài liệu này (10.0.0.22) khác với IP ghi trong cau-hinh-mikrotik-rb3011 (10.0.0.200) — kết quả của lần “IP scheme reorganization” ngày 2025-12-31; tài liệu này (topology) là nguồn IP mới nhất, đã xác minh qua SSH.
• Quyết định còn treo — WireGuard: luật NAT port-forward UDP 51820→10.0.0.22 vẫn còn trên router nhưng không còn tác dụng. Đã quyết (2026-09-04): gỡ luật. Nội dung gốc để tham chiếu: Kiểm tra lại trực tiếp trên Pi ngày 2026-08-17: không tiến trình nào lắng nghe 51820, không interface WireGuard, không container wg-easy (chỉ có adguardhome và stack wp_*). Cần chọn: gỡ luật này, hay dựng lại WireGuard trên Pi nếu vẫn muốn truy cập từ xa. Đây là quyết định hạ tầng, không phải việc dọn rác — nên luật được giữ nguyên chờ chủ hệ thống quyết. (Các record mồ côi *11 thì đã dọn, xem phần xác minh ở trên.)