7편에서 백본 스위치(SG3452X)를 Standalone 모드로 설정했습니다. 백본은 안정성을 위해 독립적으로 두지만, AP와 PoE 스위치는 Omada 컨트롤러(OC200)로 중앙 관리합니다. 이번 편은 컨트롤러 초기 설정, 장비 입양(Adopt), AP·PoE 구성, 무선(SSID·MAC 화이트리스트·게스트망), 그리고 컨트롤러를 도메인·인증서에 연동하는 과정을 다룹니다. 시리즈의 마지막 편입니다.
두 갈래 관리 구조
이 인프라의 Omada 관리는 의도적으로 둘로 나뉩니다.
- 백본 SG3452X → Standalone. 모든 트래픽이 지나는 핵심이라, 중앙 관리 장애나 일괄 변경의 영향을 받지 않도록 독립 운영(7편).
- AP + PoE 스위치 + 컨트롤러 → Omada 컨트롤러(OC200) 통합. 무선은 AP가 여러 대라 중앙 관리(SSID 일괄 적용, PoE 모니터링, 토폴로지)가 큰 이점.
이번 편에서 다루는 장비는 이렇습니다.
| 장비 | 모델 | 역할 |
|---|---|---|
| 컨트롤러 | OC200 (하드웨어 컨트롤러) | 중앙 관리 |
| PoE 스위치 | SG2210XMP-M2 (8×2.5G PoE+ + 2×10G SFP+) | AP 전원·연결 |
| AP | EAP660 HD ×4 + EAP653 ×1 | 무선 (약 90대 클라이언트) |
OC200은 24/7 동작하는 전용 하드웨어 컨트롤러입니다. PC를 켜둘 필요 없이 최대 100대 장비를 관리합니다. (소프트웨어 컨트롤러나 클라우드 대안도 있지만, 이 프로젝트는 하드웨어 OC200을 씁니다.)
1. 컨트롤러 모드 확인과 초기 점검
OC200에 처음 접속하면 좌측에 Dashboard / Devices / Logs / Firmware / Settings 메뉴가 보입니다. 초기에 확인할 것:
- 시간대:
Asia/Seoul확인 (로그·인증서 시간 기준). - 펌웨어: Stable 채널 유지(운영 환경은 Early Access Program OFF).
- CPU/메모리: 유휴 시 CPU 20~40%가 정상.
실전 노트: OC200의 CPU가 한때 100%로 치솟은 적이 있었는데, 5~10분 관찰하니 30%로 내려갔습니다. 펌웨어 체크·통계 집계·Pending 장비 Adopt 재시도 같은 백그라운드 작업이 겹친 일시적 현상이었습니다. 지속적으로 100%면 재부팅(Maintenance → Reboot)을 고려하지만, 잠깐 높은 건 정상일 수 있습니다.
2. 장비 입양 (Adopt)
Omada 컨트롤러가 장비를 관리하려면 Adopt(입양)해야 합니다. 상태는 Pending(대기) → Adopting(채택 중) → Connected(관리 중) 순으로 진행됩니다.
같은 대역(L2 Discovery) — 일반적
컨트롤러와 장비가 같은 VLAN/대역에 있으면 컨트롤러가 자동으로 발견합니다.
Devices → Pending 상태의 장비 클릭 → Adopt → (기본 admin/admin 또는 설정한 비번)
이 프로젝트는 PoE 스위치(SG2210XMP)와 AP 5대를 같은 대역(직원망 192.168.1.x)에서 Adopt했습니다. PoE 스위치를 먼저 입양하면, 거기에 물린 AP들이 토폴로지에 자동으로 매핑됩니다.
다른 대역(L3 Adoption) — 백본을 넣으려면
장비가 컨트롤러와 다른 대역에 있으면 L2 자동 발견이 안 됩니다. 이때는 L3 Adoption(Inform URL)을 씁니다. 백본 SG3452X(관리망 10.0.91.2)를 컨트롤러(직원망 192.168.1.x)에 넣으려 할 때가 이 경우입니다. 조건은 두 가지입니다.
- 라우팅·방화벽: 두 대역 간 통신이 열려 있어야 함(OPNsense에서 허용).
- Inform 포트: Omada Inform 통신용 TCP
29810~29814(및 HTTPS 443)가 방화벽에서 열려 있어야 함.
장비 쪽에서 컨트롤러 주소(Inform URL)를 직접 지정하면, 라우팅만 되면 다른 대역에서도 Adopt됩니다. (다만 이 프로젝트는 백본을 Standalone으로 유지하는 결정을 했으므로, L3 Adoption은 “할 수 있지만 안 한” 선택지입니다.)
비밀번호 통일: 컨트롤러가 관리하는 장비들은 Device Account 비밀번호를 통일해두면 운영이 단순합니다. 단, 작업 중 채팅·문서에 비번이 노출됐다면 반드시 변경하세요(Settings → Site → Device Account).
3. AP·PoE 고정 IP
장비가 Adopt되면 IP를 고정합니다. 관리 대상이 IP로 식별되므로, 주소가 흔들리면 모니터링·DNS가 깨집니다.
두 가지 방법
- 방법 1 — DHCP 예약(권장): 라우터(OPNsense)에서 장비 MAC에 특정 IP를 예약. 장비를 초기화/교체해도 자동 복구되고, 관리가 한 곳(라우터)에 집중됩니다.
- 방법 2 — Omada에서 직접 Static: 각 장비에 고정 IP를 박음(
Devices → 장비 → Config → IP Settings → Static). 초기화하면 DHCP로 돌아갑니다.
대부분의 사무실은 방법 1(DHCP 예약)이 깔끔합니다. 이 프로젝트의 IP 정리 예시입니다.
192.168.1.1 OPNsense (게이트웨이)
192.168.1.2~.3 OC200 / PoE 스위치 (관리)
192.168.1.5~.9 AP 1~5
192.168.1.30~ 직원 PC (DHCP/예약)
AP에 직접 Static을 줄 때는 Apply 후 AP가 Disconnected → Provisioning → Connected로 재연결되는지 확인합니다(1~2분). 안 돌아오면 IP 충돌 가능성 — 물리 리셋(5초)으로 DHCP 복귀.
PoE 전력 점검
PoE 스위치는 전력 예산이 있습니다. SG2210XMP-M2는 PoE 예산이 넉넉해, EAP660 HD(약 17W)·EAP653(약 12W) 5대 합쳐 약 75~85W로 예산의 30% 수준이었습니다. Devices → 스위치 → Statistics에서 포트별·총 전력을 모니터링하고, AP가 행업하면 원격으로 해당 포트 PoE를 재시작할 수 있습니다.
4. 무선(SSID)과 접근 제어
SSID 설정
Settings → Wireless Networks → Create New Wireless Network
SSID 이름·보안(WPA2/WPA3)·암호를 정하고, 필요하면 VLAN을 매핑합니다. 무선 사용자를 특정 VLAN(예: USR)에 태깅해 보내면, 유선과 동일한 방화벽 정책으로 통제됩니다.
MAC 화이트리스트 (등록된 기기만 허용)
“승인한 기기만 Wi-Fi를 쓰게” 하려면 SSID에 MAC 필터를 Allow List로 겁니다.
Settings → Profiles → Groups 에서 MAC Group(허용 목록) 생성
Settings → Wireless Networks → [SSID] → Advanced → MAC Filter
→ Enable, Policy: Allow Listed, 위 MAC Group 지정
화이트리스트에 없는 기기는 SSID·암호를 알아도 Wi-Fi 연결 자체가 거부됩니다.
랜덤 MAC 함정: iPhone·Mac은 기본적으로 “프라이빗 Wi-Fi 주소(랜덤 MAC)”를 씁니다. 이게 켜져 있으면 화이트리스트·DHCP 예약이 매번 어긋납니다. 사용자에게 해당 SSID에 한해 프라이빗 주소를 끄도록 안내하고, 진짜 MAC을 등록해야 안정적으로 동작합니다.
화이트리스트를 더 강하게 하려면 OPNsense 쪽에서 DHCP Pool을 제거하고 예약된 MAC만 IP를 받게 하는 방법, 또는 Captive Portal로 승인 절차를 두는 방법도 있습니다. 셋(SSID MAC 필터 / DHCP 예약 전용 / 포털 승인)을 조합하면 다층 방어가 됩니다.
게스트망 분리
직원 개인 기기·방문객용은 별도 SSID + 별도 VLAN으로 분리하는 걸 권합니다. 업무망과 게스트망을 나누면, 게스트 기기가 사내 자원에 접근하지 못하게 방화벽으로 깔끔히 격리할 수 있습니다.
5. 컨트롤러를 도메인·인증서에 연동
OC200 관리 화면을 IP가 아니라 도메인으로, 정식 인증서로 접근하게 만듭니다. OPNsense의 Unbound(DNS) + Caddy(리버스 프록시) + ACME(인증서) 조합을 씁니다(5·6편 참고).
DNS (Unbound Host Override)
내부에서 도메인이 컨트롤러를 가리키게 합니다.
OPNsense → Services → Unbound DNS → Overrides
Host: omada Domain: sys.example.com Type: A IP: (Caddy=OPNsense IP)
Caddy 리버스 프록시 (백엔드는 HTTPS 필수)
omada.sys.example.com {
reverse_proxy https://192.168.1.2:443 {
transport http {
tls
tls_insecure_skip_verify
}
}
}
핵심 두 가지. 첫째, Omada 컨트롤러 백엔드는 HTTPS만 받습니다(WebSocket 포함) — HTTP로 프록시하면 안 됩니다. 둘째, OC200은 자체 서명 인증서를 쓰므로 tls_insecure_skip_verify로 백엔드 검증을 건너뜁니다. 외부↔Caddy 구간은 ACME 와일드카드 인증서로 보호되므로 보안 문제는 없습니다.
Access Config — Controller Hostname
Settings → Controller → Access Config
Controller Hostname/IP: omada.sys.example.com (IP → 도메인)
⚠️ 입양 경고의 의미: Hostname을 도메인으로 바꾸면 “이 hostname이 장비에서 접근 가능한지 확인하라”는 경고가 뜹니다. 바꾸는 순간부터 AP들이 컨트롤러를 이 도메인으로 찾기 때문입니다. 즉 AP가 받는 DNS(보통 OPNsense Unbound)가 이 도메인을 풀 수 있어야 합니다. DNS가 안 되면 AP가 컨트롤러를 못 찾아 Adopt가 깨질 수 있으니, DNS → Caddy 테스트를 먼저 하고 Hostname을 바꿉니다.
인증서 형식 주의 (OC200 자체 업로드 시)
OC200에 직접 인증서를 넣으려면 PKCS12(PFX) 또는 JKS 형식이 필요합니다. ACME가 주는 PEM(.crt+.key)은 변환해야 합니다.
openssl pkcs12 -export -in fullchain.pem -inkey privkey.pem
-out omada.pfx -name omada -passout pass:비밀번호
다만 외부에서 Caddy를 거쳐 접속한다면 OC200 자체 인증서 업로드는 사실 필수가 아닙니다 — Caddy가 앞단에서 와일드카드 인증서로 종단하므로, 내부 백엔드는 자체 서명이어도 됩니다.
그 밖의 권장 설정
- Cloud Access: 도메인으로 접속 가능하니 OFF 권장(외부 노출 최소화).
- Mail Server: 알림 수신용 설정.
- Accounts: 관리자 비밀번호 강화 + 2차 관리자 1명 추가(락아웃 대비).
- 백업: Settings → Maintenance → Backup으로 컨트롤러 설정 백업.
이번 편 체크포인트
- AP·PoE 스위치는 OC200 컨트롤러로 통합 관리(백본은 Standalone 유지 — 두 갈래 구조)
- 장비 Adopt 완료(같은 대역은 L2 자동, 다른 대역은 L3 Inform URL)
- AP·PoE 고정 IP(DHCP 예약 권장), PoE 전력 모니터링
- SSID + VLAN 매핑, MAC 화이트리스트·게스트망으로 무선 접근 제어
- 컨트롤러를 Unbound+Caddy+ACME로 도메인·인증서 연동(백엔드 HTTPS 필수, Cloud Access OFF)
이로써 OPNsense(L3)·백본 Standalone L2·Omada 통합 무선/PoE가 한 인프라로 맞물립니다.
시리즈를 마치며
여덟 편에 걸쳐 중소 규모 네트워크를 OPNsense + Omada로 처음부터 구축하는 과정을 정리했습니다.
- 01~06 OPNsense: 하드웨어·설치 → Interface/VLAN → DHCP·방화벽 → NAT·WAN 절체 → 절체 전 보안 → 절체 후 방어선
- 07~08 Omada: 백본 L2/VLAN(Standalone) → 컨트롤러·AP·PoE 통합
전체를 관통한 설계 원칙은 일관됩니다. L3는 OPNsense, L2는 Omada로 역할을 나누고, 위험 없는 작업부터·내 접속을 끊지 않는 순서로 진행하며, 백본은 독립(Standalone)·무선은 통합(Controller)으로 안정성과 편의를 동시에 잡는 것. 상용 UTM 한 대에 묶여 있던 기능을 오픈소스와 표준 장비로 풀어내면서, 전환기의 통신 단절을 최소화하는 게 처음부터 끝까지의 목표였습니다.
공개 글로 옮길 때: 이 시리즈 곳곳의 실제 공인 IP·회사 도메인·실명·장비 MAC·노출된 비밀번호는 모두 예시값으로 마스킹했습니다. 캡처를 첨부할 때도 동일하게 가려서 올리시길 권합니다.