29 KiB

Raw Blame History

현재 장비·현재 PC로 하는 TERA 시연

이 문서부터 따라 하세요. 장비 192.168.0.223, 지금 사용하는 PC 192.168.0.100, 이미 실행 중인 Docker 인증 서버, 이전에 사용한 Gmail → Daum 조합에 맞춘 절차입니다. 새로운 PC나 스위치가 있다고 가정하지 않습니다.

확인일: 2026-09-10. 아래 ‘현재 확인’은 읽기 점검 결과이며, 버튼을 눌러 수행할 시연 결과는 별도로 기록합니다.

현재 확인한 환경

대상	확인 내용
관리 PC	이더넷 `192.168.0.100/24`, Wi-Fi `192.168.30.33`
장비 관리망	인터페이스 1(eth0) `192.168.0.223/24`
장비 인터넷망	인터페이스 2(eth1) DHCP, 현재 주소 `192.168.200.4/24`, 실제 기본 경로 `192.168.200.1`
장비 준비 상태	12/12 준비 완료
RADIUS	기존 `tera-aaa-lab-radius-1` 실행 중, PC `192.168.0.100:1645/UDP`
TACACS	기존 `tera-aaa-lab-tacacs-1` 실행 중, PC `192.168.0.100:49/TCP`
인증 시험 ID	기존 실습 사용자 `labadmin`
메일	과거 시험: Gmail SMTP → 본인 Daum 메일. 현재 저장 파일은 비활성·기본값이므로 UI에서 아래 값 재설정 필요
SNMP / Trap / Syslog	저장 파일에서 비활성. 아래 PC 확인 도구와 UI 값으로 시험
주소 필터	저장 파일에서 전체 사용 꺼짐, 블랙리스트, 규칙 없음
SSL	현재 저장 파일 활성값과 인증서 디렉터리는 `factory-default`. 예전에 만든 IP 인증서가 그대로 있다고 가정하지 않음
포트	저장 파일의 CH01은 9600/8N1, 흐름 제어 없음, 동작 1·2 사용 안 함. 실제 외부 케이블 연결은 확인되지 않음

저장된 네트워크 상태 표시는 실제 링크와 다를 수 있어 주소·기본 경로는 OS 동작값도 대조했습니다. UI를 열었을 때 값이 위와 다르면 UI의 현재 값부터 기록하고 진행합니다.

시작할 때 열어 둘 화면

관리자 브라우저: http://192.168.0.223/.
별도 비공개 브라우저: 로그인 거부·외부 사용자 시험용.
본인 Daum 받은편지함, 기존 발송용 Gmail.
Docker Desktop → Containers → tera-aaa-lab.
먼저 관리자 운영 → 백업/복원 → 내보내기에서 백업 파일 암호와 확인을 입력하고 백업 다운로드. 파일과 암호는 별도 보관합니다.

메일 주소와 Gmail 앱 비밀번호는 이 자료에 공개하지 않습니다. 본인 계정 값을 입력하며, 앱 비밀번호는 Gmail 로그인 비밀번호와 다릅니다. 외부 인증의 기존 실습 암호·공유 키는 PC의 기존 실습 계정 안내에 있는 값을 사용합니다.

1. 네트워크 — 현재 관리 연결과 Gmail 발송용 인터넷 확인

인터페이스 1: 네트워크 설정 → 인터페이스 1에서 DHCP 끔, IPv4 192.168.0.223, 마스크 255.255.255.0인지 봅니다. 지금 이 주소로 접속하고 있으므로 다른 시험 주소로 바꾸지 않습니다.

인터페이스 2: DHCP 켬인지 봅니다. 현재 할당 주소는 192.168.200.4입니다. DHCP에서 받은 값이므로 고정 IP 입력칸에 이 숫자를 복사하지 않습니다. 인터넷이 이미 연결돼 있으면 DHCP를 반복해서 켰다 끌 필요가 없습니다.

테스트 순서:

진단 도구 → 네트워크 테스트 → 주소 192.168.200.1, 핑 횟수 4 → 테스트. 현재 인터넷 공유기로 응답이 오는지 봅니다.
주소 192.168.0.100으로 반복합니다. PC 방화벽이 Ping을 막을 수 있으므로 이것만 실패하면 다음 메일/인증 시험과 함께 판정합니다.
주소 smtp.gmail.com으로 반복합니다. 출력에서 이름이 IP로 해석되는지 확인합니다. Gmail 서버가 Ping에 응답하지 않는 것과 DNS 해석 실패를 구분합니다.
아래 2번의 Gmail 실제 발송까지 성공하면 DNS·인터넷·SMTP 연결을 사용한 실제 동작을 확인한 것입니다.
호스트 설정 → 호스트 이름의 현재값을 기록 → tera-demo-0910 → 적용 → 다른 메뉴를 거쳐 다시 열어 값 확인 → 원래 이름 적용. 이 동작은 시스템 로그 시험에도 사용합니다.

성공 화면: 공유기 테스트 결과, 이름 해석 결과, 실제 Daum 수신 메일, 호스트 이름 재조회. 원복: 호스트 이름만 복구. 현재 eth0 관리망과 eth1 DHCP 인터넷망은 유지합니다.

현재 환경에서 제외: OOB는 두 인터페이스 모두 Static IPv4·게이트웨이가 필요하지만 현재 eth1은 DHCP입니다. Bonding/Bridge도 현재 ‘관리망+인터넷망’ 배선에서 무작정 켜는 시험으로 잡지 않습니다. DDNS는 등록 도메인·계정이 비어 있고 IPv6 통신 상대도 확인되지 않았으므로 현재는 UI 항목 확인까지만 가능합니다. 별도 준비가 필요한 항목은 마지막 표에 적었습니다.

2. 메일 — 본인 Gmail에서 본인 Daum으로

기타 설정 → 알림 설정 → 메일에 아래처럼 입력합니다.

항목	이번에 넣을 값
메일 알림 사용	켬
SMTP 서버 / 포트	`smtp.gmail.com` / `587`
STARTTLS 사용 / SMTP 인증 사용	둘 다 켬
SMTP 사용자	지난번 발송에 쓴 본인 Gmail 전체 주소
SMTP 비밀번호	그 Gmail의 기존 앱 비밀번호. 현재 저장돼 있지 않으면 다시 입력
발신자	위 Gmail 주소와 동일
수신자	지난번 수신한 본인 Daum 전체 주소
참조(CC)	비움
제목	`[TERA 0910] Gmail에서 Daum 테스트`
본문	`TERA 시연 알림: {{message}}`

적용 → 테스트 발송을 한 번 누릅니다.
Daum 받은편지함을 새로고침하고 방금 제목의 메일을 엽니다. 없으면 스팸함을 봅니다.
발신 Gmail, 수신 Daum, 방금 시각, 본문의 테스트 메시지를 보여줍니다.
성공: UI 발송 성공과 실제 Daum 새 메일을 함께 확인. Gmail 수신 시험도 하고 싶다면 수신자만 본인 Gmail로 바꾸고 제목을 바꿔 적용 → 테스트 발송. 끝나면 Daum으로 되돌립니다.

실패하면: 현재 날짜·시간 → 인터페이스 2 인터넷 → Gmail 주소/앱 비밀번호 → 587·STARTTLS·인증 켬 → Daum 스팸함 순서로 확인합니다. x509: certificate signed by unknown authority는 장비의 발송용 CA 신뢰 문제이며 수신 주소 변경으로 해결되지 않습니다.

3. 인증 서버 — 지금 실행 중인 Docker 그대로 사용

Docker Desktop → Containers → tera-aaa-lab에서 radius와 tacacs가 Running인지 봅니다. 현재 둘 다 실행 중이므로 새로 만들지 않습니다.
radius 컨테이너를 열어 Logs 탭을 띄웁니다.
장비 UI → 관리자 운영 → 인증 서버 → RADIUS에서 아래 값을 적용합니다.

항목	RADIUS 시험	TACACS 시험
사용	RADIUS 켬	TACACS 켬
서버 주소	`192.168.0.100`	`192.168.0.100`
인증 포트	1645 — 컨테이너 내부 1812를 넣지 않음	49
공유 Secret	기존 실습 안내의 RADIUS 공유 키	기존 실습 안내의 TACACS 공유 키
응답 타임아웃	5초	5초
외부 사용자 기본 역할	포트 운영자	포트 운영자

장비 로컬 사용자에 labadmin을 새로 추가하지 않습니다. 별도 비공개 창에서 labadmin + 기존 실습 암호 + 현재 CAPTCHA로 로그인합니다.
로그인 성공 화면과 같은 시각의 radius Logs의 승인 결과를 확인합니다.
로그아웃 → 암호만 한 번 틀리게 입력, CAPTCHA는 정확하게 입력 → 로그인 거부와 서버 거부 로그를 확인합니다.
관리자 창에서 TACACS 탭에 표의 값을 적용하고, Docker의 tacacs → Logs를 열어 4~6번을 반복합니다.
장애 시험은 현재 선택한 인증 컨테이너만 Stop → labadmin 신규 로그인 실패 → 실제 로컬 관리자 로그인 가능 확인 → 컨테이너 Start → labadmin 다시 성공 순서입니다.

성공: 웹 성공/거부와 해당 Docker 서버 결과가 일치. 실패: 로그가 없으면 PC 방화벽·서버 주소·1645/49, 서버 거부 로그가 있으면 계정·공유 키를 확인합니다. 원복: 원래 인증 사용 상태로 돌아가고 컨테이너도 시험 전 실행 상태로 둡니다.

4. SSL — 예전에 입력한 인증서를 다시 확인하고 HTTPS에서 보기

현재 장비에는 기본 인증서만 확인됐으므로 먼저 목록을 봅니다.

관리자 운영 → SSL 인증서 → 인증서. 현재 활성 ID를 기록합니다.
device-192-168-0-223이 없으면 새로 만들기 → CN 192.168.0.223, 국가 KR, 조직 TERA-TEST, 나머지 선택값 비움 → 생성. ID는 자동값을 유지합니다.
인증서 탭 → 활성 인증서에서 방금 만든 항목 선택 → 적용.
새 창에서 **https://192.168.0.223/**을 엽니다. 자체 서명 경고가 나오면 주소가 본인 장비인지 확인하고 시험용 접속을 진행합니다.
주소창의 사이트 정보 → 인증서 보기에서 CN 192.168.0.223 / 조직 TERA-TEST / 유효 기간 / SAN의 IP를 확인합니다.
HTTPS로 로그인하고 메뉴 하나를 엽니다. 이 HTTPS 관리자 창은 다음 주소 필터 시험에 사용합니다.

성공: 만든 인증서가 실제 HTTPS에서 보이고 로그인 가능. 자체 서명 신뢰 경고와 주소 불일치/만료 오류를 구분합니다. 원복: 주소 필터 시험 후 원래 인증서를 선택해 적용할 수 있습니다.

CSR도 지금 확인 가능: CSR 내보내기 → 만든 인증서 선택 → CN 확인 → CSR 다운로드. 파일에서 BEGIN CERTIFICATE REQUEST 확인. CA 서명 인증서/키가 준비되지 않았으므로 가져오기·공인 신뢰 완료까지 시험했다고 표시하지 않습니다.

5. 주소 필터 — PC 한 대로 HTTP 차단 / HTTPS 복구

핵심: 현재 PC 192.168.0.100/32의 HTTP만 차단합니다. 전체 프로토콜이나 /24로 바꾸지 않습니다. 먼저 위 4번에서 HTTPS 로그인과 메뉴 이동이 되는지 확인합니다. HTTPS가 안 되면 이 시험은 시작하지 않습니다.

HTTPS 관리자 창에서 관리자 운영 → 주소 필터를 엽니다. 현재 전체 사용 여부·모드·규칙을 기록합니다.
IPv4 탭 → 모드 블랙리스트 → 규칙 주소 192.168.0.100/32, 프로토콜 HTTP, 규칙 사용 켬. 목적지 포트는 고정값 0 유지. 규칙 저장 후 전체 사용을 켜고 적용합니다.
별도 비공개 창에서 **http://192.168.0.223/**으로 새 로그인합니다. 주소 필터 거부가 나오는지 확인합니다.
HTTPS 관리자 창에서 메뉴를 다시 열어 계속 관리되는지 확인합니다.
HTTPS 창에서 방금 HTTP 규칙을 끄고 적용합니다. HTTP 창에서 다시 새 로그인해 성공을 확인합니다.

성공: 같은 PC에서 HTTP 거부 / HTTPS 유지 / 규칙 해제 후 HTTP 복구. 프로토콜이 전체로 들어가 두 창 모두 차단되면 반복 로그인하지 말고 콘솔 복구가 필요합니다.

화이트리스트는 현재 PC 허용 확인까지만: 전체 사용을 끈 상태에서 화이트리스트로 변경 → 192.168.0.100/32, 전체 프로토콜 허용 규칙 먼저 저장 → 활성화 → 새 HTTP/HTTPS 로그인 성공 확인 → 시험 전 상태로 원복. 다른 PC가 준비되지 않았으므로 ‘다른 PC 거부’까지 검증한 것으로 적지 않습니다.

MAC: 현재 PC의 명령 프롬프트에서 ipconfig /all → ‘이더넷’의 물리적 주소를 확인합니다. MAC 탭에서 그 값을 등록·저장·재조회하는 시험은 가능합니다. 관리 PC의 MAC을 전체 차단하는 시험은 지금 시연 순서에서 제외합니다.

6. SNMP — 지금 PC에 준비한 도구로 실제 값 읽기

다른 SNMP 프로그램을 설치하지 않아도 됩니다. 탐색기에서 이 프로젝트의 demo-guide → tools → check.cmd를 더블클릭하면 번호 선택창이 열립니다. 기존 프로젝트의 Go 런타임과 포함된 라이브러리를 사용합니다. 최초 실행 때 컴파일 대기 시간이 있을 수 있습니다.

관리자 운영 → SNMP에서 아래 값을 입력 → 적용.

항목	값
SNMP 사용	켬
장비 위치(sysLocation)	`TERA-PC-TEST-A`
SNMP v1 / v2c / v3	끔 / 켬 / 끔
Read Community	`TERA_DEMO_RO` — 이번 격리 시험용
Write Community	이 읽기 시험에는 새로 설정하지 않음

check.cmd 실행 → 1 입력 → Enter. 1.3.6.1.2.1.1.6.0 = TERA-PC-TEST-A 응답을 확인합니다. 같이 표시되는 uptime은 장비 가동 시간입니다.
UI 위치를 TERA-PC-TEST-B로 바꾸고 적용 → 도구 다시 실행 → 1. 실제 응답이 B로 바뀌는지 봅니다.
UI의 SNMP 사용을 끄고 적용 → 도구 1 실행. 응답하지 않고 timeout이 나오는지 확인합니다.
다시 켜고 적용 → 도구 1에서 응답 복구를 확인합니다.

성공: UI에서 바꾼 위치가 PC 조회 응답에 그대로 나옴. 실패: 버전 v2c·Community 철자·장비 주소·SNMP 사용 상태 확인. 도구는 이번 시험의 고정값을 사용하므로 다른 Community를 UI에 넣으면 응답하지 않습니다.

v3도 같은 PC에서 시험

SNMP 화면에서 v3 켬, v3 사용자 사용 켬, 사용자 TERA_DEMO_V3, 접근 권한 읽기, 인증 SHA-1, 암호화 AES, 인증 키 TeraDemoAuth0910, 암호화 키 TeraDemoPriv0910 → 적용합니다. 모두 이번 시연용 공개 시험값이며 운영 암호로 사용하지 않습니다.
check.cmd → 4를 실행해 같은 위치 값이 나오는지 확인합니다.
v2c를 끄고 적용 → 도구 1은 응답 실패, 4는 정상 응답인지 비교합니다.

원복: 원래 SNMP 사용 상태·사용자·키·위치로 복구. 읽기 성공을 쓰기 성공으로 표시하지 않습니다. sysLocation은 에이전트 설정으로 관리되므로 임의 SET 성공을 기대하는 시험에 쓰지 않습니다.

7. SNMP Trap / Syslog — 같은 PC를 수신기로 사용

수신이 막힐 경우 PC 방화벽 준비

관리자 PowerShell에서 아래 규칙을 한 번만 추가합니다. 장비 192.168.0.223에서 오는 시험 UDP 두 포트에만 적용됩니다. 이미 같은 이름의 규칙이 있으면 중복 추가하지 않습니다.

New-NetFirewallRule -DisplayName 'TERA Demo Receivers' -Direction Inbound -Action Allow -Protocol UDP -LocalAddress 192.168.0.100 -LocalPort 2162,1514 -RemoteAddress 192.168.0.223

Trap

check.cmd → 2. ‘Waiting on 192.168.0.100:2162’ 창을 열어 둡니다.
기타 설정 → 알림 설정 → SNMP Trap: 전송 사용 켬, 대상 주소 192.168.0.100, 대상 포트 2162, 버전 v2c, Community / 인증 키 TERA_DEMO_TRAP → 적용 → 테스트 전송.
PC 창에서 장비 주소, 방금 시각, OID와 내용이 찍히는지 확인합니다. UI의 전송 성공 안내만으로 끝내지 않습니다.

Syslog

다른 check.cmd 창 → 3. ‘Waiting on 192.168.0.100:1514’ 창을 열어 둡니다.
기타 설정 → 시스템 로그 → 로그 서버: 원격 로그 전송 사용 켬, 서버 192.168.0.100:1514, 프로토콜 UDP → 적용.
로그 이벤트 탭 → 설정 변경 이벤트 - 로컬 저장 / 원격 전송 켬 → 적용.
네트워크 설정 → 호스트 이름을 tera-syslog-0910으로 변경·적용합니다.
PC 창의 새 설정 변경 메시지와 로그 → 시스템 로그의 같은 시각 기록을 비교합니다.
원격 전송만 끈 뒤 이름을 원래대로 복구합니다. 이 새 변경은 로컬에서 보이고 원격에는 전달되지 않는지 확인합니다.

성공: 실제 PC 수신 내용과 장비 로그 일치. 원복: 호스트 이름과 알림/로그 서버 설정 복구, 수신창 Ctrl+C 종료. 추가한 방화벽 규칙을 더 쓰지 않으면 관리자 PowerShell에서 Remove-NetFirewallRule -DisplayName 'TERA Demo Receivers'로 제거합니다.

Trap v3 / Syslog TCP 추가 비교

Trap v3: v2c 수신창을 Ctrl+C로 닫고 도구 5 실행. 장비 Trap 화면 버전 v3, 사용자 TERA_DEMO_V3, 인증 SHA-1, 암호화 AES, Engine ID TERA-DEMO-0910, Community / 인증 키 TeraDemoAuth0910, 암호화 키 TeraDemoPriv0910, 주소/포트는 .100:2162 그대로 → 적용 → 테스트 전송. PC 창에서 새 OID/내용 확인. 시험 후 원래 값 복구.
Syslog TCP: 관리자 PowerShell에서 아래 TCP 시험 규칙을 추가하고 도구 6 실행. 장비 로그 서버는 .100:1514 그대로, 프로토콜만 TCP로 적용. 설정 변경 이벤트의 원격 전달을 켜고 호스트 이름 변경/복구 → PC 수신 확인. 시험 후 원래 프로토콜·전달 설정 복구 및 시험 규칙 제거.

New-NetFirewallRule -DisplayName 'TERA Demo Syslog TCP' -Direction Inbound -Action Allow -Protocol TCP -LocalAddress 192.168.0.100 -LocalPort 1514 -RemoteAddress 192.168.0.223
# 시험 종료 후
Remove-NetFirewallRule -DisplayName 'TERA Demo Syslog TCP'

8. 포트 설정 — 연결 장비를 모를 때부터 시작

여기서 ‘CH01’은 장비의 1번 포트라는 뜻입니다. PC의 COM 번호와 다른 이름입니다.

현재 확인된 CH20 실제 시험

2026-09-10 CH20의 RX 기록에서 연결된 장비가 출력한 Invalid interface를 확인했습니다. 이 연결을 사용하면 별도 시험 케이블을 가정할 필요가 없습니다.

시리얼 이벤트 → 대상 CH20, 수신 키워드 감지 켬, 감지 키워드 Invalid interface, 메일로 전달 켬 → 적용.
CH20 터미널에서 연결된 장비의 인터페이스 이름 입력 화면을 확인합니다. 그 화면에 d를 넣으면 Invalid interface가 반환됐던 현재 시험을 한 번 반복합니다. 유효한 인터페이스 이름을 입력해 상대 장비의 네트워크 설정을 진행하는 시험은 아닙니다.
로그 → 포트 로그 → CH20에서 새 시각의 RX Invalid interface를 확인합니다.
키워드 검사는 약 2초 주기이며 SMTP 처리 시간은 별도입니다. Daum에서 새 메일 본문의 CH20과 키워드를 확인합니다. 메일 테스트 발송 버튼은 누르지 않습니다.

수정 전에는 실제 seriald 수신 로그가 키워드 알림 검사 경로를 거치지 않았습니다. 수정본은 새 RX를 검사하고 분할 수신도 이어서 비교합니다. API 재시작 전 과거 기록은 자동 재발송하지 않으므로 반드시 새 오류 응답을 발생시킵니다.

COM4 PuTTY에 root@iconsole-server가 보이면 TERA 자체 관리 콘솔입니다. 여기서 DEMO_ALARM_0909를 입력하면 셸이 명령으로 해석하고, echo DEMO_ALARM_0909는 관리 콘솔에만 글자를 출력합니다. 둘 다 CH01~CH48의 RX 입력이 아니므로 포트 키워드 이벤트가 발생하지 않습니다. 메일 자체의 동작은 먼저 메일 화면의 테스트 발송으로 확인합니다.

케이블을 몰라도 지금 할 수 있는 설정 시험

포트 설정을 열고 1번 포트를 선택합니다. 적용 대상도 1번만 선택합니다.
매개변수에서 별칭을 DEMO-PORT-1, Baudrate 9600, 데이터 8, Parity None, Stopbit 1, Flow control None으로 적용합니다. 현재 확인된 CH01 통신값과 같은 조건입니다.
2번 포트 화면으로 갔다가 1번으로 돌아와 별칭과 값을 확인합니다. 2번의 별칭이 같이 바뀌지 않았는지 확인합니다.
고급 설정 → Alarm 키워드에 DEMO_ALARM_0910 → 적용.
기타 설정 → 알림 설정 → 시리얼 이벤트 → 대상 포트 CH01에서 같은 키워드가 보이는지 확인합니다.
이 화면에서 키워드를 DEMO_ALARM_0910_NEW로 바꿔 적용 → 포트 고급 설정으로 돌아와 같은 값인지 확인합니다. 현재 UI에서는 고정값이 아니라 양쪽에서 편집할 수 있어야 합니다.
데이터 로그에서 Read/Send 켬과 로그 형식 ascii를 적용하고 재조회합니다.

여기까지의 성공: 설정 저장·대상 포트 구분·키워드 두 화면 연동. 데이터가 실제 오갔다는 시험은 아직 아닙니다.

실제 송수신을 확인하는 화면

포트 상태를 열어 UP으로 표시되는 번호가 있는지 봅니다.
포트 디버그에서 그 번호를 선택하고 접속합니다. 연결된 것이 운영 서버 콘솔이면 임의 시험 문자를 명령으로 보내지 않습니다.
반대편 장치가 무엇인지 모르거나 UP 포트가 없으면 여기서 송신 시험은 멈춥니다. 설정 화면이 정상이라는 이유로 송수신 성공으로 적지 않습니다.
송신한 문자를 되돌려 주는 시험 케이블/시험 장치가 연결됐다고 확인된 경우에만 고급 기능 → ASCII → 전송 값 DEMO_ALARM_0910_NEW, 끝 문자 CRLF → 일괄 전송합니다.
포트 로그에서 RX로 돌아온 문자열을 확인합니다. TX만 있으면 수신 키워드 시험은 아직 성립하지 않습니다.

실제 키워드가 Daum 메일로 오는지

위 RX가 확인된 같은 번호를 시리얼 이벤트에서 선택합니다. 수신 키워드 감지 켬, 현재 키워드 설정, 메일로 전달 켬 → 적용.
메일 목적지는 2번 절차의 Gmail → Daum 상태로 둡니다.
반대편에서 현재 키워드가 들어오게 합니다. 되돌림 시험 장치라면 위 일괄 전송을 다시 합니다.
테스트 발송 버튼은 누르지 않고, Daum 받은편지함의 새 이벤트 메일과 RX 로그 시각·포트 번호를 비교합니다.
Trap 전달도 켜면 7번의 PC 수신창에서 같은 실제 이벤트를 확인할 수 있습니다.

연결 확인 범위: CH20에서는 위 인터페이스 입력 화면과 실제 RX를 확인했습니다. CH01이나 다른 번호에도 같은 장비가 연결돼 있다고 가정하지 않습니다. 실제 상태 DOWN·DCD/DSR 시험은 해당 케이블과 신호 조건을 확인한 뒤 진행합니다.

9. 사용자 계정·권한·비밀번호

관리자 운영 → 사용자 계정 → 사용자 추가: ID demo_operator, 역할 포트 운영자, 시험용 암호, 포트 권한 CH01만 지정해 저장합니다.
사용자 표의 수정 / 비밀번호 / 삭제가 겹치지 않고 눌리는지 봅니다.
비공개 창에서 demo_operator로 로그인합니다. 초기 암호 변경이 뜨면 변경합니다.
포트 운영자에게 로그 메뉴가 보이지 않는지 확인합니다. 주소창에 http://192.168.0.223/logs/ports를 직접 넣어도 로그가 표시되지 않아야 합니다.
CH01은 허용 범위, CH02는 권한 밖인지 확인합니다. 케이블 미확인 상태에서는 실제 데이터 접속 성공까지 판정하지 않습니다.
관리자로 돌아와 해당 사용자의 비밀번호를 변경하고 새 암호 로그인 확인 → 시험 계정 삭제 → 새 로그인 불가 확인.
본인 암호 변경 화면도 확인하려면 실제 관리자 계정 대신 시험 계정에서 현재/새 암호/확인을 입력해 변경합니다.

원복: 시험 계정 정리. 실제 로컬 관리자·기존 실습 labadmin 설정은 임의로 지우지 않습니다.

10. 시스템 로그·포트 로그·상태 이벤트 삭제

지금 바로 만들 수 있는 시스템 로그

기타 설정 → 시스템 로그 → 로그 이벤트에서 시스템/설정 변경/운영 모드의 로컬 저장을 켜고 적용합니다.
위에서 한 사용자 추가·설정 변경·로그인 시험 시각을 적습니다.
로그 → 시스템 로그 → 검색 초기화 → 조회. 방금 시각의 변경 기록을 찾습니다.
다운로드 형식 CSV와 충분한 최대 건수를 선택 → 로그 다운로드 → 파일을 열어 같은 기록을 찾습니다.
필요한 기록을 보관한 뒤 로그 클리어 (삭제) → SYSTEM 입력. 새로 조회해 삭제 전 기록이 없어졌는지 확인합니다.
호스트 이름을 한 번 바꿨다가 복구해 새 로그가 다시 기록되는지 확인합니다.

포트/상태 로그의 실제 삭제 범위

UI	조작	확인
로그 → 포트 로그	CH01 선택 → 로그 클리어 → `CH01`	기존 CH01 기록 삭제, 다른 채널 기록 유지
같은 화면	전체 포트 선택 → 로그 클리어 → `ALL`	전체 포트의 삭제 전 통신 기록 제거
로그 → 포트 상태 이벤트	로그 클리어 → `LINKS`	과거 상태 이벤트 제거, 현재 포트 상태 자체는 유지

먼저 현재 기록이 있는지 확인합니다. 비어 있는 목록에서 삭제 버튼 성공만 확인했다면 ‘빈 상태 삭제 동작 확인’입니다. 실제 기록 제거와 다른 범위 보존 시험은 삭제 전 기록이 있어야 합니다. 전체 통신 로그가 없다면 포트 연결 확인 후 RX/TX 기록을 만든 다음 반복합니다. 삭제는 검색된 몇 줄이 아닌 선택 범위 전체에 적용됩니다.

11. 백업/복원 — 포트 별칭으로 눈앞에서 확인

CH01 별칭을 BACKUP_BEFORE로 적용합니다.
관리자 운영 → 백업/복원 → 내보내기: 백업 파일 암호와 확인 입력 → 백업 다운로드.
CH01 별칭을 BACKUP_AFTER로 바꿔 적용하고 다시 열어 확인합니다.
백업/복원 → 복원: 방금 파일 선택, 동일 암호, 네트워크 설정 포함 끔 → 복원 및 적용.
CH01 별칭이 BACKUP_BEFORE로 돌아왔는지 확인합니다. 관리 주소 192.168.0.223로 계속 접속되는지도 봅니다.
잘못된 백업 암호로는 복원이 거부되고 현재 설정이 유지되는지 한 번 확인합니다.
별칭을 시험 전 값으로 복구합니다. 백업 후 바꾼 다른 설정도 복원될 수 있으므로 메일·인증 상태를 다시 봅니다.

성공: 파일을 받았다는 것에 더해 실제 화면값이 이전 상태로 돌아옴. 현재 네트워크 구성을 바꾸는 ‘네트워크 포함 복원’은 이 시연에서 켜지 않습니다.

12. 날짜·시간 / 재시작 / 나머지 기능

기타 설정 → 날짜와 시간: Asia/Seoul 확인. 시간이 틀리면 현재 PC 시간으로 동기화 → 적용 → 새 설정 변경 로그 시각과 PC 시각 비교. NTP 스위치 저장과 실제 동기화 성공은 구분합니다.
저장 후 재시작: 모든 시연과 백업이 끝난 뒤 실행. 192.168.0.223에서 준비 완료 → 로그인 → 별칭·키워드·메일 설정 유지와 실제 메일 발송 재확인. 기존 외부 인증 서버는 현재 PC에서 계속 실행돼 있어야 합니다.
대시보드·언어: 대시보드 장비 정보 확인, 언어를 바꿔 같은 메뉴·버튼 배치 확인 후 한국어로 복귀.

기능	현재 가능한 범위 / 추가로 필요한 것
DDNS	IPv6 항목 제거·사용 안 함·저장 상태 확인. 실제 갱신에는 본인 등록 도메인과 공급자 계정 필요 — 현재 비어 있음
IPv6	UI 설정 확인. 현재 실제 IPv6 상대/경로 미확인, 통신 성공 판정 제외
Bonding·Bridge·OOB	현재 eth0 관리망/eth1 DHCP 인터넷망을 유지. 해당 시험용 배선·주소/게이트웨이 계획이 있어야 전환 시험 가능
포트 동작 1·2 / Reverse SSH·Telnet	UI 저장·사용 안 함 전환은 확인 가능. 실제 접속과 송수신은 포트 상대 확인 후 시행
DCD·DSR·포트 DOWN	물리 신호/상대 연결 확인 필요. 문자열 송신이나 설정 저장으로 통과 처리하지 않음
시스템 이벤트 자동 알림	메일·Trap·Syslog 수신부터 통과한 뒤 이벤트별 전달 켬. 실제 재시작 알림은 마지막 재시작에서 확인
SNMP 쓰기	읽기/v3/Trap/TCP는 위 PC 도구로 시험. SET은 지원되는 쓰기 OID 확인이 필요하며 GET 성공으로 대체하지 않음
SSL 가져오기	본인 인증서와 대응 개인키 파일이 필요. 현재는 자체 서명 생성·실제 HTTPS·CSR 다운로드까지 수행
펌웨어	현재 표시 버전 `0.2.0-dev.20260909.8`. final-build는 개별 바이너리이며 .pkg가 아님. 이후 수정이 포함된 호환 서명 .pkg가 확보돼야 적용 시험 가능
공장 초기화	현재 시험 설정을 지우므로 일반 시연 순서에서 실행하지 않음. 기본 접속 정보·백업·복구 준비 후 별도 실시

결과는 기록표에 ‘현재 수행한 범위’대로 적습니다. 추가 준비가 필요한 기능의 상세 참고 절차는 네트워크, 포트, 보안, 알림·로그, 유지보수에 남겨 두었습니다. 그 문서의 가상 시험망을 현재 환경으로 착각해 적용하지 않습니다.

29 KiB Raw Blame History