네트워킹과 경계

서비스를 실행하는 Mac은 네트워크 안에 있으며, 실제 문제의 대부분은 그 네트워크에서 시작됩니다. WAN 링크가 끊겼다 붙었다 하는 라우터, 엉뚱한 서브넷에 있는 잊혀진 기기, 몇 달 전에 열어 두고 닫지 않은 포트 같은 것들입니다. FrontierStack은 네트워크와 그 경계—LAN과 인터넷 사이의 경계—를 일급 객체로 다룹니다. 라우터를 직접 읽고, LAN을 스캔하여 인벤토리를 만들고, 데이터 흐름 맵을 그리며, 서비스를 외부에 공개하는 몇 가지 체계적인 방법을 제공합니다.

이 장에서는 서버를 둘러싼 네트워크를 다룹니다. SSH로 서버 자체를 연결하는 방법은 8장을, 호스트 방화벽, fail2ban 및 보안 감사는 10장을, Cloudflare DNS와 TLS는 7장을 참조하십시오.

9.1읽고 제어할 수 있는 라우터 및 방화벽

FrontierStack은 네트워크 장비 고유의 관리 API가 있으면 그것을 통해, 없으면 SSH를 통해 통신합니다. 가장 긴밀하게 통합된 두 가지는 OPNsense(전체 REST API)와 Cloudflare(7장에서 다룸)이며, 그 밖의 다양한 라우터와 방화벽도 실시간 상태를 보고합니다. 라우터 및 네트워크 패널에서 주소, 제조사, API 키를 입력하여 기기를 추가하면, AI 관리자의 router_info 도구가 버전과 모델, 가동 시간, CPU와 메모리, WAN 링크와 게이트웨이(작동 또는 중단), 인터페이스 및 클라이언트 수를 읽을 수 있으며, FrontierStack이 매핑하지 않는 필드는 원시 API JSON으로도 확인할 수 있습니다. 이 도구는 읽기 전용입니다. 기기 자체의 API를 조회할 뿐, SSH는 절대 사용하지 않습니다.

OPNsense와 pfSense에서는 API 키를 입력하면 지속적인 방화벽 모니터(고정된 기기 패널의 토글)를 사용할 수 있습니다. 알림 점검이 실행될 때마다 방화벽 자체에 게이트웨이 상태, 인터페이스 캐리어, 서비스 작동 여부를 조회합니다. 따라서 멀티 WAN 라우터가 조용히 페일오버하는 동안 WAN 회선이 끊긴 경우(서버의 웹 탐색은 정상이지만 사이트로 들어오는 트래픽은 끊긴 상태)에도, 원인을 알 수 없는 빨간 사이트 점들이 잔뜩 뜨는 대신 해당 게이트웨이와 캐리어를 잃은 포트를 명시한 알림이 발생합니다. 라우터에는 아무것도 설치하지 않습니다. OPNsense의 REST API는 기본 내장되어 있으며, pfSense는 REST API v2 패키지만 있으면 됩니다. 같은 패널에서 OPNsense 라우터를 tailnet에 참여시킬 수도 있습니다. Mac에서 Tailscale에 로그인하고(Google 계정 사용 가능), 사전 인증 키를 발급하여 기기 패널의 Tailscale 섹션에 붙여넣으십시오. 그러면 FrontierStack이 필요 시 os-tailscale 플러그인을 설치하고, 키와 로그인 서버(Headscale도 지원)를 저장한 뒤 API를 통해 서비스를 재시작합니다. 라우터에서 브라우저로 로그인할 필요가 없습니다. 이후 tailnet 주소는 대체 경로로 기억됩니다. LAN 주소가 응답하지 않게 되면(외부에 있을 때, VPN 경로가 끊겼을 때, LAN 구간이 죽었을 때) 상태 확인, 모니터, 인증서 갱신이 자동으로 Tailscale을 통해 다시 시도하고 그 사실을 표시하며, 모니터는 라우팅 장애가 라우터 다운으로 오인되지 않도록 별도의 “LAN 주소” 알림을 발생시킵니다.

공격 및 장애 신호. 게이트웨이를 감시하는 같은 점검이 라우터 자체의 문제도 감시하며, 이상이 있는 라우터는 사이드바에서 경고 삼각형과 함께 주황색으로 바뀝니다. 마우스를 올리면 이유가 표시됩니다. Intrusion Detection 플러그인이 활성화된 OPNsense에서는 FrontierStack이 같은 API로 최근 Suricata 알림을 읽어 건수와 가장 많이 발생한 시그니처를 보여 줍니다(방화벽 UI를 열지 않아도 공격 시도를 파악할 수 있습니다. pfSense의 REST API는 IDS를 일관되게 노출하지 않으므로 현재는 OPNsense 전용입니다). OPNsense, pfSense, OpenWrt 등 모니터링되는 모든 라우터에서 각 점검은 예기치 않은 재부팅(가동 시간이 급격히 줄어듦: 충돌, 전원 문제 또는 공격), 라우터 관리 화면/SSH에 대한 무차별 대입 급증(로그인 실패 반복, 라우터 자체 로그에서 가장 빈번한 출발지 IP 표시), 리소스 압박(메모리나 부하가 위험할 정도로 높음: DoS, 폭주하거나 침해된 프로세스), 사용 가능한 펌웨어 업데이트(오래된 펌웨어는 알려진 취약점을 의미함)도 감지합니다. 각 신호는 알림을 발생시킵니다. 특정 플랫폼이 보고할 수 없는 신호는 그냥 건너뛸 뿐, 결코 거짓 “이상 없음”으로 처리하지 않습니다. 가장 많은 정보를 보고하는 것은 OPNsense와 OpenWrt이며, pfSense의 API는 더 제한적입니다.

인증서 만료. 같은 점검이 방화벽의 신뢰 저장소—서비스가 사용하는 모든 CA와 인증서—를 읽어, 만료 한 달 전과 만료된 시점에 알림을 발생시킵니다. 아무도 대비하지 않는 장애입니다. OPNsense의 기본값인 397일로 발급된 OpenVPN 서버 인증서는 1년 뒤 모든 원격 사용자를 조용히 차단하며, Web GUI 자체의 HTTPS 인증서가 만료되면 관리 페이지가 브라우저 경고로 바뀝니다. 기기 패널은 이 인증서들을 만료가 가까운 순서로 색깔 점과 함께 나열하며, Renew… 버튼으로 라우터 API를 통해 인증서를 그 자리에서 재발급합니다. 개인 키, 주체, CA는 그대로이고, 유효 기간은 직접 선택하며(최대 10년), 인증서를 다시 로드하도록 OpenVPN 서버와 Web GUI를 재시작하는 옵션도 있습니다. 키와 주체가 바뀌지 않으므로 기존 VPN 클라이언트 프로필은 계속 작동하며, 다시 내보낼 필요가 없습니다. pfSense에서는 REST API의 갱신 동작이 같은 일을 하고 종속 서비스도 직접 재시작합니다. 또한 pfSense의 API는 인증 기관의 만료일을 보고하지 않으므로 FrontierStack이 CA 인증서 자체에서 그 날짜를 읽어, pfSense CA도 다른 CA와 마찬가지로 경고합니다. CA는 어느 API로도 갱신할 수 없습니다. 만료가 다가오는 CA를 일찍 알리는 이유는 바로 CA를 교체하려면 인증서를 다시 서명하고 클라이언트 프로필을 재배포해야 하기 때문입니다. OpenVPN 서비스 패널은 이 라우터 인증서들을 Mac에 있는 모든 .ovpn 프로필(OpenVPN Connect, Tunnelblick, 마지막으로 사용한 파일)에 포함된 CA 및 클라이언트 인증서 옆에 표시하므로, 클라이언트와 서버의 만료일을 나란히 볼 수 있습니다. 또한 Plan & Cost 카드에는 OpenVPN 자체는 무료이며 Access Server와 CloudConnexa의 요금이 얼마인지도 나와 있습니다.

라우터 제어 및 진단. 이제 AI 관리자는 읽기 이상의 작업을 할 수 있습니다. reboot_router는 서버를 재부팅하는 것과 같은 방식으로 어플라이언스를 재시작하며(OPNsense/pfSense는 API, OpenWrt는 SSH), “Allow changes” 설정으로 제한됩니다. 또한 라우터 자체 콘솔에서 하는 편이 정말로 더 나은 작업이라면, 어시스턴트가 주소를 추측하지 않고 기기 패널에서 확인하여 open_web_ui로 Web UI를 열어 주겠다고 제안합니다. FrontierStack 자체는 의도적으로 이러한 어플라이언스의 방화벽 규칙을 편집하지 않습니다. OPNsense/pfSense/OpenWrt는 자체 구성 시스템으로 규칙을 관리하므로, 패널과 어시스턴트는 대신 기본 방화벽 페이지로 안내합니다(라우터를 우클릭 ▸ Open firewall rules…로 해당 페이지에 바로 연결). 패널의 두 가지 편의 기능이 이를 보완합니다. Diagnostics 버튼은 API 없이 연결 가능성을 확인하므로(ping, 일반적인 관리 포트 80/443/8443/53, 역방향 DNS, 게이트웨이) API 키가 없어도 라우터를 진단할 수 있습니다. 또한 라우터나 방화벽에서는 Discover Services가 포트 스캔 대신 Web UI를 열도록 제안합니다(자신의 경계 기기를 스캔하는 것은 원하는 일이 아닌 경우가 대부분입니다). OPNsense나 pfSense 장비로의 SSH가 거부된다면, SSH가 비활성화되어 있거나, 더 흔하게는 특정 인터페이스(보통 WAN이 아닌 LAN)에서만 허용되어 있는 것입니다. VPN 등을 통해 LAN 쪽으로 접속하면 대개 되지만, 외부에서는 일반적으로 차단됩니다. 웹 UI에서 SSH와 수신 인터페이스를 활성화하십시오(OPNsense의 경우 System ▸ Settings ▸ Administration ▸ Secure Shell). SSH 버튼 자체는 관리용 셸이 전혀 없는 가정용 게이트웨이(NTT, 일부 TP-Link/FRITZ!Box)에서만 숨겨지며, 이 경우 Web UI가 유일한 접근 수단입니다.

9.2방화벽 주요 지표, 그래프 및 전원

모니터링이 켜진 고정된 OPNsense, pfSense 또는 OpenWrt 방화벽은 API를 통해 자체 주요 지표를 보고하며, 이제 해당 패널에서 이를 그래프로 표시합니다. CPU와 메모리는 0–100 차트 하나에, 그리고 부하 평균과 온도가 표시됩니다. 샘플은 이미 실행 중이던 모니터링 폴링에서 수집되므로 그래프 때문에 API 호출이 추가로 발생하지 않으며, 알림 점검이 진행됨에 따라 채워져 세션의 최근 약 6시간을 보여 줍니다.

플랫폼마다 제공하는 정보가 다르며, 패널은 실제 값만 표시합니다. pfSense는 순간 CPU 사용률을 보고하고, OPNsense는 대신 부하 평균을 보고합니다. 온도는 하드웨어가 FreeBSD에서 읽을 수 있는 센서를 제공하는지에 따라 달라집니다. 가상화 환경이나 ARM 설치에는 센서가 없는 경우가 많으므로, 값이 없다는 것은 고장이 아니라 “센서 없음”을 의미합니다.

모든 고정된 기기에는 서버와 마찬가지로 스마트 플러그를 연결할 수 있습니다. 켜기, 끄기, 전원 재투입, 그리고 플러그가 전력을 측정하는 경우 실시간 와트 수치를 사용할 수 있습니다. 이는 특히 방화벽에 중요합니다. 방화벽은 멈췄을 때 SSH로 접근할 수 없는 유일한 장비이기 때문입니다. 접근에 사용할 네트워크가 바로 그 방화벽이 제공하는 네트워크이기 때문입니다. OPNsense와 pfSense 모두 자체 전력 소비량을 보고하지 않으므로(FreeBSD는 와트가 아닌 온도 센서만 노출함), 전력 측정 플러그가 유일한 실제 전력 수치입니다. 전원 재투입은 확인을 요청하며 방화벽을 통과하는 모든 연결이 끊긴다고 경고합니다. 먼저 API 재부팅을 시도하십시오.

9.3기기 검색: LAN 인벤토리

기기 검색을 열고 Find Monitors를 누르십시오(또는 먼저 서브넷을 선택하십시오). FrontierStack은 선택한 /24를 사용 가능한 모든 방법으로 동시에 스캔하므로, 라우터, 액세스 포인트, 스위치, NAS 장비(Synology, QNAP, ZimaCube/ZimaOS…), 프린터, 카메라 및 기타 서버가 모두 나타납니다.

• Ping / ARP — ICMP 스캔이며, ARP/MAC으로 각 호스트의 제조사를 알아냅니다. ICMP를 차단하는 호스트를 찾으려면 TCP Probe를 켜십시오.
• Bonjour(mDNS) 및 SSDP / UPnP — 광고되는 서비스와 그 표시 이름.
• SNMP 및 LLDP / CDP — net-snmp와 lldpd가 설치되어 있으면 모델, 포트, 인접 장비 정보를 추가합니다(패널의 버튼으로 설치할 수 있습니다).
• Windows 서비스 포트 — ICMP를 차단하는 컴퓨터도 특징적인 포트(RDP, WinRM, SMB 등)를 조사하여 찾아내므로, Windows PC가 더 이상 스캔에서 숨지 않습니다.

스캔은 각 호스트에 접속할 수 있는 방법도 기록합니다. AnyDesk 배지는 AnyDesk가 로컬에서 실행 중이거나 기본 포트 7070에서 응답할 때 표시되며, Tailscale 배지(피어가 온라인이면 녹색)는 이 Mac의 tailscale status를 바탕으로 메시 피어를 검색된 기기와 대조하여 만들어집니다(엔드포인트, 호스트 이름, OS만 보관하며 로그인 이름은 절대 보관하지 않습니다). 직접 연결된 LAN에서는 macOS가 이미 Bonjour로 알고 있는 Mac과 기기가 더 느린 IP 스캔보다 먼저 나타나므로 목록이 빠르게 채워집니다. 기기의 세부 정보 보기에는 Open app 바로 가기가 있는 AnyDesk 및 Tailscale 행이 함께 표시됩니다.

스캔하지 않고 tailnet 기기를 고정하려면 Tailscale 서비스 패널을 여십시오. Tailnet Devices는 이 Mac의 Tailscale이 인식하는 tailnet의 모든 기기를 나열합니다(API 토큰이 필요 없으며, 이 Mac에서 Tailscale이 연결되어 있지 않으면 Tailnet 패널의 API 목록을 대신 사용합니다). 또한 직접 Tailscale 연결, tailscale ping, Tailscale API 또는 Bonjour를 통해 각 기기의 LAN(Wi-Fi/이더넷) 주소도 찾아냅니다. 이미 고정했거나 서버에 이미 있는 기기는 표시가 붙어 있으며 클릭하면 열립니다. Mac과 서버에는 Add to Servers(기기 검색이 이들을 등록하는 곳과 같은 위치)가, 그 밖의 기기에는 Pin이 표시됩니다. 이 Mac과 같은 네트워크에 있는 기기는 LAN 주소로 추가되며, 외부에 있을 때는 tailnet 주소로 계속 감시됩니다. 다른 곳에 있는 기기는 tailnet 주소로 추가됩니다. Mac, Windows PC, 서버 또는 NAS는 고정하거나 유형을 이들 중 하나로 변경하면 자동으로 서버에도 추가되며, MAC 주소, 제조사, 아이콘, 색상, 전원 및 UPS 연결, 저장된 암호, 위치, 사이드바 그룹이 함께 옮겨집니다. Identity 섹션의 Open in Servers를 누르면 해당 항목으로 이동합니다.

다른 tailnet 기기의 서브넷 경로를 통해 접속하는 LAN의 라우터는 ping에 응답하지만, 터널을 거치면 어느 라우터가 응답했는지 증명할 하드웨어 주소가 없습니다. 두 사이트 모두 192.168.1.1을 가질 수 있기 때문입니다. 그래서 사용자가 보증하기 전까지는 오프라인으로 유지됩니다. 라우터 패널에는 해당 서브넷을 라우팅하는 기기를 명시한 Tailscale Subnet Route 섹션이 표시됩니다. This router is on …'s network를 클릭하면 그 이후로는 해당 경로를 통한 응답이 온라인으로 간주됩니다. 하나의 경로는 주소당 고정된 라우터 하나만 가질 수 있습니다.

AI 관리자의 discover_devices 도구는 같은 스캔을 실행하고 유형을 확실하게 식별할 수 있는 기기를 자동으로 고정합니다. 모호한 기기는 추측하지 않고 목록으로 돌려주므로, 어시스턴트가 그것이 무엇인지 사용자에게 물어본 뒤 pin_device로 고정할 수 있습니다. 고정된(모니터링되는) 기기는 사이드바의 해당 유형 섹션에 나타납니다. 더블클릭하면 패널이 열리며, 행에서 Open Web UI, Discover Services, Reclassify 또는 Remove를 사용할 수도 있습니다. 주소를 이미 알고 있다면 Add a device by IP 필드에서 바로 조사하고 고정할 수 있으며, 전체 스캔이 필요 없습니다.

스캔을 기다리지 않고 고정하기. 이미 높은 신뢰도로 식별된 행에는 스캔이 진행 중일 때도 Pin이 표시되며, 그렇지 않은 행은 Review & Pin…으로 유형을 선택할 수 있습니다. 스캔 도중 고정한 기기는 고정 상태를 유지하며, 스캔이 끝나면(또는 Stop을 누르면) 나머지 스캔에서 알아낸 정보가 고정된 기록에 반영됩니다. 기기 하나를 자세히 살펴보려면 Stop을 누른 뒤(지금까지 찾은 행은 그대로 남습니다) 해당 기기의 Review & Pin… 또는 ⋯ 메뉴에서 Identify & Pin을 선택하십시오. FrontierStack이 그 주소만 핑거프린팅하여 결과가 확실하면 고정하고, 그렇지 않으면 핑거프린트 결과를 표시한 채 사용자가 검토하도록 남겨 둡니다.

POS 하드웨어. Square Terminal 또는 Register는 포트를 열지 않고 Bonjour로도 알리지 않으므로 Square 자체의 MAC 주소 블록으로 식별하여 POS(판매 시점 관리)로 표시합니다. Square 패널의 하드웨어 섹션에는 Square API가 보고하는 기기(상태, 배터리, Wi-Fi, IP)와 함께 표시됩니다. Square 카드 리더는 Bluetooth로 연결되므로 네트워크에 나타나지 않습니다. Star Micronics 및 Epson TM 영수증 프린터는 제공업체와 모델 이름으로 식별합니다.

9.4모든 제조사의 카메라

카메라 패널은 영상을 표시할 수 있는지와 관계없이 FrontierStack이 알고 있는 모든 카메라를 위한 하나의 상태 보드입니다. 기기 검색으로 찾은 카메라(고정된 카메라와, 찾았지만 아직 고정하지 않은 카메라), AV Feeds 스트림, SwitchBot 카메라, Smart Life 카메라, UniFi Protect 카메라를 모아서 보여 줍니다. 카메라가 수십 대일 때는 상단의 개수와 Offline 필터가 빠른 해답입니다. 오프라인 카메라가 먼저 정렬되며, 주소가 고정된 카메라와 일치하는 스트림은 두 번 표시되지 않고 해당 카메라의 타일에 표시됩니다. 고정된 카메라와 MAC 주소가 같은 Protect 카메라도 해당 카메라의 타일에 표시됩니다. 각 타일의 종 아이콘으로 오프라인 알림을 켜고 끄며, Alert on All은 확인 가능한 모든 카메라에 한 번에 적용됩니다. 알림은 알림 패널을 거치므로, 연락처 프리셋으로 해당 사이트의 기술자를 호출할 수 있습니다.

카메라는 RTSP(포트 554), 웹 포트(80) 또는 ONVIF(2020)에서 응답하면 작동 중으로 간주됩니다. Ring, Nest, Blink, Arlo 같은 클라우드 전용 카메라는 자체 앱으로만 접근할 수 있으므로 상태가 표시되지 않습니다.

어디서나 Tapo 카메라 확인(비공식). 서비스 ▸ 카메라 ▸ Tapo Cameras에서 TP-Link ID로 로그인하면 Mac이 집 밖에 있을 때도 각 Tapo 카메라의 온라인/오프라인 상태를 확인할 수 있으며, 오프라인 알림은 알림 기능을 통해 전송됩니다. TP-Link가 공식 API를 제공하지 않으므로 FrontierStack은 Tapo Android 앱과 같은 방식으로 로그인합니다. 따라서 TP-Link가 앱을 변경하면 작동하지 않을 수 있으며, 이 기능의 사용이 TP-Link 약관에 위배될 수도 있습니다. 상태만 읽습니다. 암호는 절대 저장하지 않으며, 카메라는 두 번 연속 확인에 실패한 뒤에야 오프라인으로 간주되고, TP-Link 클라우드에 연결할 수 없으면 오프라인이 아니라 Status unavailable로 표시됩니다. 고정된 Tapo 카메라는 클라우드가 온라인이라고 보고하는 동안 LAN 밖에서도 녹색 점을 유지합니다. 다른 Tapo 기기도 감시할 수 있으며, 별도로 로그인하면 Kasa 기기도 감시할 수 있습니다.

SD 카드. Tapo, Hikvision/Annke, Dahua/Amcrest/Lorex, Reolink, Axis 카메라의 경우 각 타일에 카메라 자체가 보고하는 메모리 카드 상태도 표시됩니다. SD ✓ 42% used, No SD card, Unformatted, SD card error, 또는 알 수 없을 때는 SD —(마우스를 올리면 이유 표시)입니다. FrontierStack은 클라우드가 아닌 카메라 자체의 로컬 API에만 문의하며, Mac이 카메라와 같은 네트워크에 있을 때만 확인합니다. 네트워크 밖에서는 마지막 결과가 그 시각과 함께 유지됩니다. 확인은 30분마다, 한 번에 카메라 한 대씩, 카메라당 최대 10분에 한 번 실행됩니다. Tapo 이외의 카메라는 AV Feeds 스트림의 로그인 정보나 카메라의 기기 패널에 입력한 로그인 정보를 사용합니다. Tapo 카메라에는 admin과 TP-Link 계정 암호가 필요하며, Tapo Cameras ▸ Local camera access에서 한 번 입력하면 됩니다. 이 암호는 키체인에 보관되며 TP-Link 클라우드로 절대 전송되지 않습니다. 카메라가 로그인을 거부하면, 카메라는 반복된 실패 후 계정을 잠그기 때문에 FrontierStack은 로그인 정보를 고치거나 Retry를 누를 때까지 해당 카메라에 대한 요청을 중단합니다. 연결하거나 로그인할 수 없는 카메라를 카드가 없다고 보고하는 일은 없습니다. SD 알림은 옵트인 방식입니다. 대부분의 카메라는 루프 녹화를 하므로 항상 가득 차 있기 때문에 거의 가득 참 알림은 기본적으로 꺼져 있습니다. eufy, WTW, Eseecloud 카메라에는 로컬 저장소 API가 없습니다.

Tapo 카메라 재시작. Tapo 카메라의 기기 패널에는 Restart Camera…가 있습니다. Tapo 앱의 재부팅 기능으로, SD 확인과 같은 로컬 로그인을 통해 같은 규칙에 따라 전송됩니다. 즉 카메라와 같은 네트워크에서만, 고정된 인증서를 사용하여, 로그인 거부나 잠금 이후에는 보내지 않습니다. 카메라는 약 1분 동안 녹화와 스트리밍을 중단합니다.

제조사별 요구 사항:

9.17.1WTW 카메라 및 레코더

구형 IP 카메라. WTW의 2018년 IP 카메라 설명서에는 메인 스트림으로 rtsp://ip:554/live/0/main, 서브 스트림으로 /live/0/sub가 나와 있습니다. 포트 554가 기본값이며 변경할 수 있습니다. RTSP는 카메라의 웹 네트워크 설정에서 켭니다. 현재의 PoE/IP 모델과 NV4 시리즈 레코더는 사양에 RTSP와 ONVIF가 명시되어 있습니다. 위 경로로 연결되지 않으면 NVR 앱에서 ONVIF로 카메라를 추가하여 URL을 찾으십시오.

EAGLE Wi-Fi 제품군. 이 제품군은 RTSP도 ONVIF도 지원하지 않습니다. WTW 지원 사이트에서 카메라 한 대에 대해 그렇게 밝히고 있으며, 레코더 사양에도 TCP/IP, DHCP, P2P만 나와 있습니다. 이 제품들은 레코더가 웹 포트에서 응답하는지 확인하는 것이 최선입니다. 기기 검색에서 WTW Camera / NVR로 고정하고 오프라인 알림을 켜십시오.

기본 암호. NV4 레코더는 00000000을 사용하며, 공장 초기화 후에는 wtwjapan이 됩니다. 구형 카메라는 admin에 빈 암호, 또는 admin/admin을 사용합니다. 기기를 네트워크에 연결하기 전에 변경하십시오.

9.17.2스마트 홈 클라우드

Smart Life(Tuya) 기기는 Tuya의 공식 Cloud API로 읽습니다. 계정의 데이터 센터(일본 계정은 Western America 사용)에서 iot.tuya.com에 Cloud 프로젝트를 만들고, Devices ▸ Link Tuya App Account로 Smart Life 계정을 연결한 다음, 프로젝트의 Access ID와 Secret을 Smart Life 패널에 붙여넣으십시오. 그러면 모든 기기의 온라인 상태와 플러그 전력을 확인하고, 플러그와 조명을 켜고 끌 수 있으며(멀티탭은 콘센트별로 개별 제어), 어떤 기기든 오프라인이 되면 알림을 받도록 설정할 수 있습니다. TESSAN, BN-LINK, Edison Smart, OHMAX, MEAPUXIN 플러그도 Smart Life 기기입니다. 서버의 전원을 재투입하려면 전원 제어에 Smart Life / Tuya 콘센트로 추가하십시오. 무료 체험판은 월 약 26,000회의 호출을 허용하며 몇 달마다 연장해야 하므로, FrontierStack은 10분마다 확인합니다.

Minut 센서는 임대 숙소의 소음, 재실 여부, 온도, 습도를 보고합니다. Minut 패널은 센서가 오프라인이 될 때, 배터리가 부족할 때, 숙소에서 소음 문제가 진행 중일 때 알림을 보냅니다. Minut는 승인한 계정에만 API를 공개하며, 도움말 문서에서는 이를 Enterprise 플랜과 연결하고 있습니다.

SmartThings, Govee, LIFX, Sensibo, Nuki는 각각 계정의 기기를 상태 점과 함께 나열하는 자체 패널이 있습니다. 녹색은 온라인, 빨간색은 오프라인, 회색은 클라우드가 응답하지 않은 경우입니다. 기기 옆의 종 아이콘이나 Alert on all을 켜면 기기가 오프라인이 될 때 알림을 받습니다. Govee, LIFX, Sensibo, Nuki는 제공업체의 앱이나 웹사이트에서 받은 API 키 또는 토큰만 있으면 됩니다. SmartThings는 로그인이 계속 유지되도록 SmartThings CLI로 자신만의 OAuth 앱을 한 번 만드십시오. 개인 액세스 토큰도 사용할 수 있지만 24시간 후에 만료됩니다. 키가 거부되거나 로그인이 만료되면 계정 알림이 한 번 발생합니다. 클라우드에 연결할 수 없으면 해당 기기의 상태는 알 수 없음으로 남습니다. 두 경우 모두 기기가 오프라인이 된 것으로 보고되지 않습니다. Nuki 잠금장치는 임대 숙소에서 감시할 가치가 있습니다. 연결이 끊긴 잠금장치는 게스트를 위해 원격으로 열 수 없기 때문입니다.

9.5데이터 맵

데이터 맵 패널은 위치별 데이터 흐름도를 그립니다. 데이터가 어디에 있고 한 사이트의 기기와 서비스 사이를 어떻게 이동하는지를 보여 줍니다. FrontierStack은 해당 위치의 인벤토리—검색된 기기, 그 역할, 그리고 (선택적으로) 스캔한 포트—를 직렬화하여 비밀 값을 제거한 뒤, 로컬 claude CLI를 통해 구독 중인 Claude에 전달합니다(앱 내 하네스가 사용하는 종량제 API가 아님). 응답은 Mermaid 플로차트와 짧은 설명으로 돌아오며, 패널에서 오프라인으로 렌더링됩니다. 각 위치의 마지막 다이어그램이 보관되며, Obsidian 보관함에 런북으로 저장할 수 있습니다. 위치 자체에 대해서는 8장에서 설명합니다.

9.6포트 열기: UPnP 및 NAT-PMP/PCP

전통적인 방식으로 인터넷에서 서비스에 접근하려면 라우터의 포트가 Mac으로 포워딩되어야 합니다. FrontierStack은 라우터에 직접 로그인하게 하는 대신, 라우터가 광고하는 표준 프로토콜을 사용하여 라우터에 매핑을 요청할 수 있습니다.

• UPnP IGD(miniupnpc 사용) — 일반 가정용 라우터에서 흔히 쓰는 방식.
• NAT-PMP / PCP(libnatpmp 사용) — Apple의 방식과 그 현대적 후속 방식.
• OPNsense — API를 통해 직접 경계 규칙과 포트 포워드를 설정.

이 도구들은 처음 사용할 때 필요에 따라 설치됩니다. 임시 세션용으로 만든 매핑(Debug Share 참조)은 세션이 끝나면 자동으로 제거됩니다.

9.7동적 DNS: 바뀌는 IP 따라가기

가정과 소규모 사무실 회선은 고정 IP인 경우가 드물기 때문에, 오늘의 주소를 가리키게 한 호스트 이름은 내일이면 맞지 않게 됩니다. Dynamic DNS 패널은 호스트 이름이 현재 공인 IP를 계속 따라가도록 유지합니다. Name, Hostname(예: myhost.duckdns.org), 제공업체의 계정 정보로 항목을 추가하고, Update Now를 눌러 즉시 반영하거나 Update automatically를 켜십시오. 업데이터를 FrontierStack이 실행 중일 때만 동작시킬지, 시스템 서비스로 상시 동작시킬지 선택할 수 있으므로 앱을 닫아도 레코드를 최신 상태로 유지할 수 있습니다. Cloudflare 사용자는 더 긴밀한 방법을 쓸 수 있습니다. 공인 IP를 따라가는 Cloudflare DDNS A 레코드로, 7장과 같은 Cloudflare 연동으로 동작합니다. 그 밖의 제공업체는 업데이트 URL을 사용하는 범용 주기 업데이터로 지원됩니다.

9.8터널과 메시: 포트를 열지 않고 안으로 들어오기

외부에서 서비스에 접근하는 더 나은 방법은 인바운드 포트를 아예 쓰지 않는 것입니다. 터널은 바깥쪽으로 연결을 만들고, 외부 엔드포인트가 그 연결을 타고 다시 들어오게 하여 아무것도 포워딩하지 않고 NAT를 통과합니다:

• Cloudflare Tunnel — Quick Tunnel은 계정 없이 공개 *.trycloudflare.com URL을 제공하며, 고정 호스트 이름이 필요하면 이름 있는 터널을 사용합니다.
• Tailscale — Serve는 서비스를 tailnet 안에서만 비공개로 유지하고, Funnel은 Tailscale 노드를 통해 인터넷에 공개합니다.

기기 간의 지속적인 연결에는 메시 또는 VPN 네트워크가 어디로 이동하든 모든 노드에 고정된 사설 주소를 부여합니다. FrontierStack은 대표적인 것들을 관리합니다 — 지원하는 라우터(OPNsense)에서는 API로, 서버에서는 SSH로 관리합니다:

9.17.3Tailnet: Tailscale 네트워크 전체 보기

서버별 Tailscale 제어는 각 서버의 패널 안에 있으며 SSH로 동작합니다. 이 제어는 “이 기기에서 데몬이 실행 중인가”에 답합니다. Tailnet 패널은 Tailscale 자체 API만 답할 수 있는, 네트워크 전체에 걸친 질문에 답합니다. API 액세스 토큰을 붙여넣으면(기기 읽기 권한이면 충분합니다 — 이 패널은 절대 쓰지 않습니다) 모든 기기를 주소, OS, 클라이언트 버전, 소유자, 태그, 마지막 접속 시각과 함께 나열합니다.

이 패널의 진가는 Needs attention 목록에 있습니다. 곧 만료되는 노드 키를 보여 줍니다 — 이는 예정된 장애와 같습니다. 키가 만료되면 누군가 다시 인증할 때까지 기기가 조용히 tailnet에서 빠지기 때문입니다. 또한 승인 대기 중인 기기, 아무도 승인하지 않은 경로를 알리는 기기(노드가 분명히 켜져 있는데도 서브넷에 연결할 수 없는 흔한 원인), 몇 주 전부터 응답이 끊긴 기기를 보여 줍니다. 키 만료와 승인 대기는 알림도 발생시킵니다.

9.17.4Apple TV를 입구로: 잠긴 ISP 라우터에 접근하기

NTT의 XG-100NE 같은 FLET'S 홈 게이트웨이 등 ISP가 제공하는 라우터는 Tailscale이나 VPN을 실행할 수 없고, 설정 페이지도 LAN에서만 응답합니다. IPoE 회선(MAP-E 또는 DS-Lite)에서는 사용할 수 있는 인바운드 IPv4 포트도 없으므로 포트 포워딩과 전통적인 VPN 서버는 쓸 수 없으며, 고정 경로는 네트워크 내부의 트래픽만 조정합니다. 해결책은 라우터 뒤에서 항상 켜져 있는 기기가 Tailscale을 서브넷 라우터로 실행하는 것입니다. 이 기기는 바깥쪽 연결만 만들고 인터넷에 아무것도 노출하지 않으며, 이미 TV에 연결된 Apple TV는 손쉬운 선택입니다.

1. Apple TV에서 App Store로 Tailscale을 설치하고 Install VPN Configuration을 선택한 뒤 QR 코드를 스캔하여 로그인하십시오.
2. 앱의 subnet router 옵션을 켜고 LAN 범위(예: 192.168.1.0/24)를 입력하십시오.
3. Tailscale 관리 콘솔의 Machines 목록에서 Apple TV의 ⋯ ▸ Edit route settings…를 열고 범위를 체크하여 저장하십시오. 같은 메뉴에서 Disable key expiry도 선택하십시오.
4. tailnet의 어디에서든 라우터의 LAN 주소(예: http://192.168.1.1)를 여십시오.

Apple TV를 홈 허브로 지정하면 잠자기 중에도 연결할 수 있습니다. 포트가 있는 모델이라면 이더넷을 사용하고, tvOS 업데이트가 무인 상태에서 재시동하므로 집을 나서기 전에 전원을 껐다 켜는 테스트를 해 두십시오. 접속하는 쪽의 192.168.1.x 네트워크와 겹치지 않도록 집 LAN에는 흔하지 않은 범위를 지정하십시오(NTT 게이트웨이에서는 Web設定 ▸ LAN設定). tvOS에는 SSH가 없으므로 FrontierStack이 Apple TV 자체를 설정할 수는 없지만, Tailnet 패널에서 온라인 여부를 확인하고 아직 승인 대기 중인 경로를 표시해 줍니다.

9.17.5자체 ZeroTier 컨트롤러 운영하기

ZeroTier 클라이언트는 멤버 쪽일 뿐이며, 네트워크는 보통 my.zerotier.com에서 관리합니다. 하지만 모든 zerotier-one 설치는 자기 네트워크의 컨트롤러가 될 수도 있습니다 — 완전한 셀프 호스팅으로, 멤버 목록을 제3자가 보관하지 않습니다 — 그런데 이 방식에는 로컬 관리 UI가 전혀 없습니다. ZeroTier Controller 패널이 그 빠진 인터페이스입니다.

컨트롤러의 ID와 소유한 네트워크를 보여 주고, 클릭 한 번으로 승인/승인 해제할 수 있는 멤버 승인 대기열을 처리합니다. 승인되었지만 2주 동안 보이지 않은 멤버는 표시됩니다. 사용하지 않는 허가는 네트워크에 상시 뚫린 구멍이기 때문입니다. 네트워크의 이름, 공개 여부, 경로, IP 할당 풀을 편집할 수 있고, ZeroTier 고유의 규칙 언어로 플로 규칙을 작성할 수 있습니다 — 입력하는 동안 로컬에서 컴파일되며, 흔한 경우를 위한 템플릿과 모든 사람을 차단하게 되는 규칙 세트를 저장하기 전의 경고가 제공됩니다.

모든 작업은 SSH를 통해 컨트롤러 자체의 루프백 API를 대상으로 실행됩니다. 컨트롤러는 127.0.0.1:9993에서 수신하고 root만 읽을 수 있는 토큰으로 인증하므로, FrontierStack은 공개적으로 접근 가능한 컨트롤러 API를 전혀 필요로 하지 않으며 오히려 적극적으로 막습니다. 그럼에도 노출되어 있다면 내장 감사가 이를 표시하며, 느슨한 파일 권한과 백업 누락도 함께 표시합니다. 이 밖에 Prometheus 내보내기, 웜 스탠바이 백업/복원, ZeroTier Central에서 네트워크를 이전하는 도우미도 있습니다.

9.9UniFi: Cloud Gateway, Dream Machine, Superlink

Ubiquiti 콘솔에는 전용 패널이 있습니다. UniFi 게이트웨이는 범용 라우터 점검으로는 볼 수 없는 일을 더 많이 하기 때문입니다. Dream Machine(UDM, UDM Pro, UDM SE), Cloud Gateway(UCG-Ultra, UCG-Max, UXG), Superlink 게이트웨이, Cloud Key 또는 셀프 호스팅 컨트롤러 등 콘솔 제품군을 모두 다룹니다. UniFi 패널은 Ubiquiti의 두 API를 모두 사용하며, 두 API는 서로 다른 질문에 답합니다. Site Manager 키(unifi.ui.com에서 만드는 키 하나)는 계정의 모든 콘솔을 모델, 펌웨어, 온라인 상태와 함께 나열합니다. 원격 사이트의 전원이나 인터넷 연결이 끊겼는지 알 수 있는 유일한 방법입니다. 네트워크에서 떨어진 콘솔은 로컬로 아무것도 알려 줄 수 없기 때문입니다. 콘솔에서 Settings ▸ Admins & Users로 직접 만드는 로컬 콘솔 키를 사용하면 게이트웨이가 지금 하고 있는 일을 볼 수 있습니다.

로컬에서는 WAN 링크를 ISP, 지연 시간, 처리량과 함께 보여 주며, 실제로 트래픽을 전달하는 링크가 어느 것인지 표시합니다. 이 세부 사항이 중요합니다. 주 회선이 끊기면 UniFi는 조용히 백업 회선으로 페일오버하는데, 백업은 대개 더 느리고 종량제인 경우가 많으며, 보통은 다음 달 청구서를 보고서야 알게 됩니다. 또한 채택된 기기와 펌웨어, 게이트웨이가 평가하는 순서대로의 방화벽 규칙, 클라이언트 목록, 모든 포트 포워딩을 나열합니다. 활성화된 포워딩은 하나하나가 방화벽에 의도적으로 낸 구멍이므로, 패널은 모든 출발지 주소에서 연결을 받는 포워딩을 표시합니다 — 공개 웹 서버라면 맞는 설정이지만, 그 밖의 경우라면 다시 확인해 볼 만합니다.

알림은 콘솔 오프라인, WAN 링크 다운, 백업 링크로 운용 중, 기기의 네트워크 이탈, 인터넷에 노출된 포트 포워딩을 다룹니다. 이 패널은 의도적으로 읽기 전용입니다. 규칙과 네트워크 변경은 검증 기능이 있는 UniFi 콘솔에서 하십시오. PoE 스위치 포트는 다음 절에서 다루며, 단순한 콘솔 연결 가능 여부는 다른 제조사와 함께 Router & Network에도 계속 표시됩니다.

Site Manager 키는 UniFi Protect 카메라와 도어벨도 나열하며, 최대 5분마다 읽습니다. 카메라의 Alert나 Alert on all Protect cameras를 체크하면 오프라인 알림을 받습니다. 업데이트 중이거나 콘솔 자체가 오프라인인 카메라는 다운이 아니라 알 수 없음으로 표시됩니다.

9.10PoE(Power over Ethernet): 전원 버튼이 없는 기기의 전원 버튼

액세스 포인트, 카메라, 도어 컨트롤러, 탁상 전화기에는 전원 스위치가 없습니다. 유일한 전원은 연결된 스위치 포트이므로, 멈춘 기기를 복구하는 방법 — 전원을 껐다 켜기 — 은 보통 제조사 웹 UI를 거치거나 랙까지 걸어가야 합니다.

Power over Ethernet 패널은 포트를 버튼으로 만듭니다. 관리형 스위치를 IP로 추가하면 포트별로 PoE 상태(전력 공급 중, 탐색 중, 장애), 수전 기기 클래스, 우선순위, 그리고 스위치가 보고하는 경우 전력(W)을 볼 수 있으며 — 전원 끄기/켜기와 제대로 된 전원 재투입도 할 수 있습니다. 스위치의 전력 예산도 보여 줍니다: 총 와트, 사용 중인 와트, 그리고 스위치 자체의 사용량 임계값을 넘으면 경고를 표시합니다. 임계값을 넘으면 스위치가 우선순위가 낮은 포트의 전원부터 끊기 시작하므로 포트 우선순위도 여기서 편집할 수 있습니다.

PoE는 표준화되어 있으므로 폭넓게 동작합니다. RFC 3621의 POWER-ETHERNET-MIB는 사실상 모든 관리형 PoE 스위치 — Cisco, Aruba/HPE, Netgear, TP-Link/Omada, Ubiquiti, MikroTik, D-Link, Zyxel — 에 구현되어 있습니다. 읽기에는 Device Discovery의 SNMPv2c 또는 SNMPv3 프로필을 사용합니다. SNMPv2c에서 포트를 전환하려면 별도의 읽기-쓰기 커뮤니티가 필요하며, 스위치별로 추가하고 키체인에 보관합니다. SNMPv3에서는 해당 사용자에게 스위치의 쓰기 권한이 있을 때만 인증 프로필을 사용합니다. 전원 차단은 신중한 접근 권한과 확인을 거쳐야 하므로, FrontierStack은 임의의 OID 쓰기를 제공하지 않습니다. Monitor를 켜면 장애 상태의 포트나 전력 예산을 초과한 스위치가 알림을 발생시킵니다 — 둘 다 그렇지 않으면 누군가 카메라가 꺼진 것을 알아차릴 때까지 드러나지 않습니다.

9.11Show Network: 클럽, 무대, 공연 감독하기

공연은 무언가가 조용해지기 전까지는 아무도 들여다보지 않는 네트워크 위에서 돌아갑니다: CDJ가 링크에서 떨어지고, 조명 노드가 응답을 멈추고, 타임코드가 멈추고, NDI 피드가 미디어 서버에서 사라집니다. Show Network 패널(사이드바 ▸ AV & Stage)은 이 Mac을 그 네트워크의 감독자로 만듭니다. 공연을 운영하지는 않습니다. 공연을 운영하는 모든 것을 지켜보고, 그중 하나가 사라지는 순간 알려 줍니다.

9.17.6현황 요약

패널 맨 위에서 FrontierStack은 Mac이 연결된 네트워크 또는 VLAN마다 기기들이 직접 알려 오는 정보를 집계하여 평이한 문장 하나로 적습니다 — 예: “en5 · 2.0.0.0/8에 Art-Net 노드 14개, 사용 중인 유니버스 73개, sACN 소스 2개, NDI 비디오 소스 1개가 있습니다.” 공연장에 들어섰을 때 “전부 다 있는가?”에 가장 빨리 답해 주며, 케이블을 옮긴 뒤 가장 먼저 읽어야 할 내용입니다.

9.17.7Show Dashboard

현황 요약 아래의 Show Dashboard는 공연의 각 부분에 타일을 하나씩 할당합니다:

아래의 목록에는 각 타일에 해당하는 모든 기기가 표시되며, 행마다 Watch 버튼이 있습니다. SMPTE LTC는 오디오 신호이므로 직접 읽지 않습니다. MTC 또는 Art-Net 타임코드로 변환하면(대부분의 LTC 인터페이스와 ShowKontrol이 지원) 타임코드 타일에 나타납니다.

9.17.8Arm Show

개장 전에 Arm Show를 누르십시오. FrontierStack은 그 시점에 온라인인 모든 것 — 덱, 믹서, 조명 노드, sACN 소스, NDI 소스, LED 컨트롤러, Link 세션 — 을 감시하며, 그중 하나라도 사라지면 평소의 채널(11장)로 Show Network 그룹에 분류된 알림을 보냅니다. 공연이 끝난 뒤 Disarm을 누르면 감시 목록이 비워집니다. 개별 기기를 직접 감시하거나 감시 해제할 수도 있습니다.

9.17.9수동적 탐색, 그리고 비켜서기

거의 모든 것은 묻지 않고 듣기만 하여 발견합니다:

FrontierStack이 보내는 유일한 것은 Art-Net ArtPoll입니다: 탐색용 브로드캐스트 하나를 30초마다 반복하여 새 노드가 저절로 나타나게 합니다. Poll Art-Net Now를 직접 누르는 편이 좋다면 설정에서 Poll for Art-Net nodes automatically를 끄십시오.

공연 소프트웨어는 UDP 포트를 독점해야 합니다. rekordbox, Engine DJ, ShowKontrol, Beat Link Trigger, PRO DJ LINK Bridge, QLC+, Resolume, MadMapper, QLab 등이 같은 Mac에서 실행되는 동안에는 해당 리스너가 닫히고 패널에 그 사실이 표시됩니다. 소프트웨어와 네트워크를 모두 보려면 공연 네트워크에 있는 두 번째 Mac에서 감독하십시오.

9.17.10Show Servers

Show Servers에서 Add Server로 미디어 서버, LED 컨트롤러 또는 조명 데몬의 주소를 추가합니다. 각각 30초마다 HTTP로 확인하며, 응답이 멈추면 알림을 보냅니다. 일부는 실제 상태를 보고합니다:

• Resolume — 웹 서버를 통해(Preferences ▸ Webserver).
• WLED — LED 수, 프레임 속도, 소비 전류, Wi-Fi 신호, 실시간 Art-Net 또는 sACN 입력 여부와 함께 On/Off 및 밝기 제어.
• Falcon Player (FPP) — 플레이어 상태와 현재 시퀀스.
• OLA와 QLC+ — 데몬 또는 웹 액세스의 응답 여부와, OLA의 버전 및 유니버스 수.

NovaStar/COEX, Brompton Tessera, Colorlight, MADRIX 5, Lightjams는 웹 UI 또는 원격 포트의 응답 여부를 확인합니다. 수신 카드, 캐비닛 온도, 토폴로지는 각 제조사의 도구에서 확인하십시오.

9.17.11프리셋

9.17.12경고등, 고정, 전원

무대 감독이 밤새 화면만 볼 수는 없으므로, Show Network는 조명을 깜박여 알릴 수 있습니다. 경고등에 WLED 스트립이나 경광등, 로컬 브리지의 Philips Hue(브리지의 링크 버튼을 누른 뒤 페어링), 또는 HTTP 요청(알람 URL과 해제 URL — PATLITE 네트워크 신호탑, 경광등을 켜는 Shelly 릴레이, Home Assistant 웹훅)을 추가합니다. 감시 대상이 다운되면 빨간색으로 깜박이고, 복구되거나 확인을 누르면 원래 상태로 돌아갑니다.

고정하면 플레이어, 믹서, Art-Net 노드, WLED, Falcon Player, LED 프로세서가 Device Discovery에 추가되어, 기기 패널에서 전원 콘센트나 PDU, SwitchBot 플러그, UPS를 연결할 수 있습니다(요금제의 기기 수 한도에 포함). 고정된 감시 대상에는 전원 재투입…과 선택형 자동 재투입(최대 2회, 30분 간격)이 표시됩니다. LED 월 프로세서(NovaStar/COEX, Brompton Tessera, Colorlight)와 MADRIX는 Full Fleet 기능입니다.

Clubs & Bars 프리셋에는 Show Network, AV Feeds, Power over Ethernet이 포함됩니다. 페스티벌, 투어, 기업 행사에는 공연 네트워크의 기반(Places, VPN, 메시 네트워킹)을 추가한 Stage & Shows에서 시작하십시오. 다른 셋업에는 Show Supervisor 애드온을 추가할 수 있습니다. Pro DJ Link 플레이어와 믹서, LED 월 프로세서, WLED 및 픽셀 컨트롤러는 Device Discovery에서 고정하여 연결 가능 여부를 확인할 수도 있습니다.

9.12발전기: 행사 및 대기 전원

콘서트, 페스티벌, 야외 행사는 렌탈 발전기로 돌아가며, 발전기가 멈추면 무대도 조용해집니다. 발전기 패널(AV & Stage의 Show Network 옆)이 이를 지켜봅니다. 렌탈 장비는 제조사가 섞여 있으므로 연결 방법은 세 가지입니다.

• 이 네트워크의 컨트롤러. 대부분의 세트는 Deep Sea Electronics, ComAp, DEIF, CRE, Datakom 컨트롤러로 제어되며, 이들은 Modbus TCP로 통신합니다. 컨트롤러를 제작 네트워크에 연결하고(DSE는 이더넷 포트 또는 DSE855 게이트웨이) IP를 추가하면 FrontierStack이 모델을 식별하고 몇 초마다 읽습니다. 클라우드 구독이나 모바일 신호가 필요 없습니다. 지원 맵: DSE(GenComm, 제품군별 경보 이름 표시), ComAp InteliLite 4, DEIF AGC 150, CRE GENSYS Compact, Datakom D-300/500/545/700.
• ComAp WebSupervisor: ComAp 클라우드에 보고하는 세트용입니다. API 키와 애플리케이션 클라이언트 ID 및 시크릿으로 연결한 다음 감시할 유닛을 선택하십시오. 값은 1분마다 갱신됩니다.
• AEMP 2.0 텔레매틱스(ISO 15143-3): 렌탈 업계에서 널리 쓰이는 Trackunit, Atlas Copco FleetLink 및 대부분의 장비 제조사 포털. 계정을 연결한 다음 플릿에서 감시할 세트를 선택하십시오. 스냅샷은 5분마다 갱신되며, Trackunit 확장 데이터에는 발전기 자체의 전압, 주파수, 부하가 포함됩니다. 텔레매틱스는 연료와 「아직 운전 중인지」 확인에는 좋지만 공연 중 트립을 잡기에는 너무 느립니다.

세트마다 운전 상태와 모드, kW와 부하(컨트롤러가 부하를 보고하지 않으면 정격 kW를 설정), 연료(운전 데이터가 20분 쌓이면 남은 시간 추정치 포함), 상별 전압과 전류, 주파수, 냉각수 온도, 오일 압력, 배터리 전압, 운전 시간, 컨트롤러 자체 경보 이름을 표시합니다.

개장할 때 운전 중인 세트 감시 시작을 누르십시오. 그 시점에 운전 중인 모든 세트는 계속 운전해야 하는 것으로 간주되며, 멈추거나 고장 나거나 응답하지 않으면 알림(그룹 「발전기」)이 전송됩니다. 연료 부족, 설정 시간 내 연료 소진 예상, 고부하, 결상, 허용 범위를 벗어난 주파수·전압도 알림이 됩니다. 주파수는 기본적으로 50 Hz와 60 Hz 중 가까운 쪽을 기준으로 합니다. 전기적 문제는 15초 동안 지속될 때만 계산하므로 무대 장비를 한꺼번에 켜도 오경보가 나지 않습니다. 경고등을 켠 세트는 심각한 문제가 생기면 Show Network 경고등을 깜박입니다.

Stage & Shows 프리셋과 Show Supervisor 애드온에는 발전기 패널이 포함됩니다. AI 관리자는 ups_status(kind: generator)로 모든 세트를 읽을 수 있습니다.

9.13인터넷 상태와 속도 테스트

Internet Health 패널은 회선 자체를 보는 화면입니다. Targets 목록 — 기본값은 Cloudflare의 1.1.1.1, Google 및 Quad9 DNS, 두 AWS 리전, Tailscale의 조정 서버 — 에 지속적으로 ping을 보내 지연 시간과 패킷 손실을 표시하고 30초마다 다시 테스트합니다. ICMP를 차단하는 호스트는 :443에 대한 TCP 연결 지연 시간으로 대체합니다. Internet 섹션 머리글의 톱니바퀴 버튼을 누르면 대상 편집 대화상자가 열립니다 — 목록을 한 번 설정해 두면 방해가 되지 않습니다. 같은 섹션에는 IPv6 판정도 있습니다. 점검할 때마다 글로벌 IPv6 주소가 할당되어 있는지, IPv6 트래픽이 실제로 동작하는지(Cloudflare/Google v6 애니캐스트로 ping), 네트워크가 알리는 IPv6 DNS 서버가 응답하는지 확인합니다. 가장 강하게 경고하는 상태는 알려졌지만 동작하지 않는 IPv6입니다 — 라우터가 주소와 IPv6 DNS 서버를 배포하고, 연결은 IPv6를 먼저 시도하며, IPv4로 대체될 때까지 모든 것이 멈춥니다. 패널은 이를 쉬운 말로 알리고, 응답하지 않는 DNS 서버를 지목하며, 라우터를 원인으로 가리킵니다. AI 관리자도 internet_speed(check=ipv6)로 같은 진단을 실행하고, 진단 도구를 통해 ping6/dig/scutil로 더 깊이 조사할 수 있습니다. 사이드바의 Internet Health 행에는 가벼운 백그라운드 점검(실행 시, 이후 5분마다)으로 갱신되는 상태 점이 있습니다: 정상이면 녹색, IPv6 장애나 심한 패킷 손실이면 주황색, 모든 대상에 연결할 수 없으면 빨간색입니다. Live Traffic은 활성화된 모든 인터페이스의 실시간 처리량을 그래프로 보여 주고, Addresses & Networks는 각 인터페이스, 서브넷(직접 접근할 수 있는 네트워크), 게이트웨이를 나열합니다. 내장 traceroute는 트래픽이 거치는 ISP와 트랜싯 제공업체를 보여 줍니다. Speed Test 섹션에서 Test Now를 누르거나 — AI에게 internet_speed로 요청하면 — 다운로드, 업로드, 지연 시간, 응답성을 측정합니다. Ookla speedtest CLI가 설치되어 있으면 이를 사용하고, 그렇지 않으면 Apple의 networkQuality를 사용합니다. 측정 중에는 speedtest.net 스타일의 다이얼 두 개가 다운로드와 업로드를 실시간으로 보여 주며 — 바늘, 단계, 현재 Mbps — Ookla의 스트리밍 출력으로 갱신됩니다(내장 networkQuality는 끝날 때만 보고하므로 다이얼은 대기합니다). 패널은 측정 중과 결과에서 연결한 테스트 서버(제공업체와 도시)를 표시합니다. 테스트가 실패하면 조용히 끝나지 않고 이유를 알려 줍니다. 다만 Wi-Fi에 연결된 Mac은 ISP만큼이나 Wi-Fi를 측정하게 되므로 — 같은 섹션에서 테스트를 라우터나 유선 서버에서 실행할 수 있습니다. From Router / Server에서 기기를 선택하면 FrontierStack이 SSH(키 인증, 라우터는 root로)를 통해 해당 기기에서 측정을 실행합니다. 설치된 Ookla/speedtest-cli를 우선 사용하고, 없으면 curl 단일 스트림 추정으로 대체합니다. 라우터가 Mac보다 훨씬 빠르게 측정된다면 병목은 회선이 아니라 무선 구간입니다 — AI도 source를 지정한 internet_speed로 같은 비교를 할 수 있습니다.

9.14Network Path: 스위치, 허브, 홉별 지연 시간

Network Path 패널은 IP 도구로는 답할 수 없는 물리적인 질문에 답합니다: 이 연결이 실제로 어떤 장비를 거치며, 어느 장비가 느리게 만드는가? LAN Path는 관리형 스위치의 브리지 테이블과 LLDP 이웃 정보를 SNMP로 읽어 이 Mac과 LAN 기기 사이의 경로를 그립니다 — 각 링크에는 포트와 속도가 표시되고, 가장 느린 링크가 표시되며, 여러 기기가 스위치 포트 하나를 공유하는 곳에는 점선으로 된 추정 상자가 그려집니다(직접 조회할 수 없는, 숨어 있는 비관리형 스위치나 허브의 전형적인 경우). Locate a Device는 기기 하나를 추적합니다: IP, MAC, 제조사(MAC 접두사로 판별), 유형 — 그리고 연결된 정확한 스위치 포트까지. Visual Traceroute는 각 홉의 왕복 시간을 차트로 그리고 지연 시간을 가장 많이 늘리는 홉을 강조 표시하므로, “내 Wi-Fi 문제인가, ISP의 첫 구간인가, 그보다 먼 곳인가?”를 그림으로 볼 수 있습니다. 스위치 읽기에는 Device Discovery에서 설정한 SNMPv2c 또는 SNMPv3 프로필을 사용합니다. 비관리형 장비는 본질적으로 보이지 않으며, 추정 기능은 바로 그런 경우를 위한 것입니다. 패널은 스스로 내용을 채웁니다: 열면 이 Mac과 라우터 사이의 기기를 자동으로 매핑합니다(Map Mac → Router로 다시 실행). Device Link Speeds는 범위를 더 넓혀 — 알려진 모든 기기의 스위치 포트에서 협상된 이더넷 포트 속도를 조사하며(링크의 양 끝은 같은 속도로 협상합니다), 가장 느린 링크와 반이중 링크를 먼저 보여 줍니다: 기가비트 네트워크에서 100 Mbps로 묶여 있는 NAS는 대개 불량 케이블, 오래된 비관리형 스위치, 또는 협상이 잘못된 NIC 때문이며, 바로 여기서 드러납니다. Locate a Device는 기기가 에이전트를 실행하는 경우 기기 자체에도 SNMP로 포트의 협상 속도를 묻습니다.

9.15서브넷과 VLAN

Subnets 패널은 FrontierStack이 알고 있는 모든 네트워크 — 이 Mac의 인터페이스와 VPN 경로, 라우터의 LAN, 서버와 기기가 속한 네트워크 — 와 각 네트워크에 있는 것을 나열합니다. 맨 위의 전환 스위치로 같은 네트워크를 세 가지 방식으로 볼 수 있습니다: List, By VLAN(VLAN별 그룹), 또는 그림으로 그린 VLAN Layout입니다.

각 서브넷은 사용 가능한 가장 강력한 근거에 따라 VLAN에 배치됩니다. 사용자가 직접 지정한 것이 최우선입니다: 아무것도 보고하지 않는 네트워크는 서브넷을 오른쪽 클릭하고 Assign to VLAN…을 선택하십시오(지정 내용은 다른 설정과 함께 저장되며 설정 백업에 포함됩니다). 다음은 API로 VLAN을 나열하는 라우터 — OPNsense, REST API 패키지를 설치한 pfSense, MikroTik RouterOS, UniFi — 와 각 VLAN 인터페이스의 주소, 그리고 igb0.10처럼 이름에 태그가 들어 있는 라우터 인터페이스입니다. 그다음은 이 Mac 자체의 VLAN 인터페이스입니다. 마지막은 관리형 스위치입니다: 서브넷의 기기 대부분이 스위치의 포워딩 테이블에서 한 VLAN으로 학습되어 있으면 서브넷이 그 VLAN에 배치됩니다. 배치된 서브넷은 모두 어떤 근거로 배치되었는지 표시하며, 남은 것은 No VLAN tag known 아래에 나열됩니다.

VLAN Layout은 그 결과를 그림으로 그립니다: 맨 위에 VLAN을 전달하는 라우터와 스위치, 그 아래에 802.1Q 트렁크, 그리고 VLAN마다 색으로 구분된 열에 서브넷과 게이트웨이, 사용하는 스위치 포트(태그 없는 액세스 포트는 채워진 표시, 태그된 포트는 윤곽선 표시), 그 VLAN에 있는 기기와 서버가 표시되며 — 각각 클릭하면 해당 패널이 열립니다. Read Switches는 포트 정보를 채웁니다: Device Discovery가 찾은 관리형 스위치에 Network Path와 같은 읽기 전용 프로필을 사용하여 SNMP로 VLAN 이름, 포트 멤버십, 네이티브 VLAN, VLAN별 포워딩 테이블을 묻고, 여러 VLAN을 태그된 상태로 전달하는 포트를 트렁크로 표시합니다. 스위치에서 읽은 정보는 세션 동안 유지되므로 케이블을 다시 연결한 뒤에는 다시 누르십시오. AI 관리자에게 “NAS는 어느 VLAN에 있나요?”라고 물으면 router_info를 통해 같은 화면 정보를 읽습니다.

9.16Debug Share: localhost 서버를 잠시 외부에 공개하기

동료나 휴대폰에 localhost에서 실행 중인 개발 서버를 보여 주어야 할 때, Debug Share 패널은 해당 서버를 한 세션 동안 공개한 뒤 스스로 닫힙니다. 포트를 입력하고(또는 Scan localhost를 눌러 실행 중인 서버를 찾고), Expose via에서 공개 방식을 고른 다음 Auto-close 시간을 설정하고 Open debug session을 누르십시오. 모든 공유는 FrontierStack을 종료할 때도 자동으로 닫힙니다.

LAN forwarder에는 두 가지 추가 기능이 있습니다. 호스트 방화벽이 켜져 있으면 패널에 Open port in firewall이 표시되어, 세션 동안에만 pf 규칙에서 해당 포트를 허용할 수 있습니다. 또한 Outside access 선택기로 UPnP, NAT-PMP 또는 OPNsense API를 통해 WAN 포트를 매핑하고 DDNS host와 짝지을 수 있으므로, LAN 공유를 공용 인터넷에서도 접근할 수 있게 됩니다 — 매핑은 공유가 닫힐 때 제거됩니다. AI 관리자도 세션을 열고, 목록을 보고, 닫을 수 있으며(debug_share_open / _list / _close), “Allow changes”가 켜져 있으면 MCP를 통해서도 가능합니다.

Debug Share 세션은 짧게 쓰도록 설계되었습니다. 자신의 개발 서버를 타이머 없이 tailnet에서 계속 접근할 수 있게 하려면 Localhost 패널(4장)에서 해당 서버의 Also serve on Tailscale을 켜십시오. 이 Mac의 Tailscale 주소에서 같은 포트로 응답하고, LAN에는 노출되지 않으며, 서버가 중지되면 닫힙니다. AI 관리자는 debug_share의 serve 액션으로 폴더를 이 방식으로 시작하고 열어야 할 주소를 알려 줄 수 있습니다.

9.17Named tunnel: 영구적인 공개 호스트 이름

Quick Tunnel은 의도적으로 일회용입니다. 이 Mac의 서비스 — 셀프 호스팅 앱, 내부 대시보드, 웹훅 수신기 — 를 실제 주소로 영구적으로 접근할 수 있게 하려면 대신 named tunnel을 사용하십시오. named tunnel은 서비스에 자신의 Cloudflare 영역 중 하나에 속한 고정 호스트 이름(예: app.example.com)을 부여하고, 재부팅 후에도 유지되며, 모든 터널과 마찬가지로 인바운드 포트를 열지 않습니다. Mac이 Cloudflare 엣지로 바깥 방향 연결을 맺으므로 포워딩할 것도, 포트 스캔에 발견될 것도 없습니다.

Cloudflare 패널의 Named Tunnels 섹션에서 만드십시오. New Tunnel…을 누른 다음, 자신의 영역 아래 호스트 이름과 그 앞단에 둘 로컬 포트를 지정합니다. FrontierStack은 이미 보유한 토큰으로 Cloudflare API를 통해 전체 설정을 진행합니다 — 터널을 만들고, 인그레스 규칙(hostname → http://localhost:PORT)을 작성하고, 호스트 이름을 <id>.cfargotunnel.com으로 가리키는 프록시된 CNAME을 추가한 다음, cloudflared service install로 상주 데몬을 설치합니다. 마지막 단계에는 한 번의 관리자 인증이 필요합니다(/Library 아래에 LaunchDaemon을 작성하기 때문). cloudflared 자체는 처음 사용할 때 Homebrew에서 가져옵니다. 터널과 DNS만 만들고 cloudflared는 다른 호스트에서 실행하려면 Run on this Mac now의 선택을 해제하십시오. Delete는 데몬, DNS 레코드, 계정 측 터널까지 전부 되돌립니다. AI 관리자도 같은 세 가지 동작(tunnel_create / tunnel_list / tunnel_delete)을 사용할 수 있으며, 터널 생성은 서비스를 인터넷에 공개하는 작업이므로 빨간색 확인을 거쳐야 합니다.

각 터널 행에는 실시간 상태 줄과 선택적으로 켜는 다운 알림용 종 아이콘도 표시되며, Protect…는 호스트 이름 앞에 Cloudflare Access 로그인을 둡니다 — 7장을 참조하십시오.