tera-clone
/
teraWeb
5
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Browse Source

Expand demo guide into UI configuration and verification procedures

main
gudae 2 months ago
parent
619d0f483b
commit
c3e85658f3
7 changed files with 667 additions and 199 deletions
Whitespace
Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL
Split View
Diff Options
Show Stats Download Patch File Download Diff File
  1. 101
      demo-guide/01-network.md
  2. 82
      demo-guide/02-ports.md
  3. 156
      demo-guide/03-security.md
  4. 146
      demo-guide/04-alerts-logs.md
  5. 68
      demo-guide/05-maintenance.md
  6. 56
      demo-guide/06-results.md
  7. 257
      demo-guide/README.md

101
demo-guide/01-network.md
View File

@ -0,0 +1,101 @@
# 1. 네트워크 설정과 실제 연결 시험
[목차](README.md) · [결과 기록](06-results.md)
현재 관리 경로가 어느 인터페이스인지 먼저 확인합니다. UI의 인터페이스 1은 `eth0`, 인터페이스 2는 `eth1`입니다. 물리 커넥터는 실제 링크로 식별합니다. 보조망 예시는 인터페이스 1로 관리하고 인터페이스 2를 시험에 쓸 수 있을 때의 절차입니다.
## N01. 고정 IPv4
**UI: 네트워크 설정 → 인터페이스 2.** 시험 PC를 보조 인터페이스에 연결하고 PC 유선 IP를 `192.168.50.100`, 마스크 `255.255.255.0`으로 설정합니다. 다른 인터페이스와 겹치지 않는 격리 시험망이어야 합니다.
| UI 항목 | 입력 예시 |
|---|---|
| DHCP 사용 | 끔 |
| IPv4 주소 | `192.168.50.223` |
| 서브넷 마스크 | `255.255.255.0` |
| 게이트웨이 | 라우터 없는 직결 시험이면 비움 |
| DNS 서버 1·2 | 직결 IP 통신 시험에서는 불필요. 원래 값을 기록 |
1. **적용**을 누르고 결과를 기다립니다. 현재 접속 IP 자체를 변경했다면 새 주소로 브라우저를 다시 엽니다.
2. 시험 PC에서 `ping 192.168.50.223`을 실행하고 `http://192.168.50.223/`에 로그인합니다.
3. 설정 화면을 다시 열어 주소·마스크가 유지되는지 확인합니다. 관리 PC A의 기존 주소 접속도 확인합니다.
**통과:** 새 IP 웹 로그인 + 재조회 값 일치. Ping 차단 환경에서는 Ping 실패만으로 웹 연결 실패로 판정하지 않습니다. **실패 확인:** PC 마스크·케이블·해당 링크·IP 중복·주소 필터 순서. 적용 실패/롤백 안내가 있으면 새 값이 반영됐다고 가정하지 않습니다. **원복:** 기존 관리 경로에서 원래 인터페이스 설정 적용, PC 어댑터 설정 복귀.
## N02. DHCP
**준비:** DHCP 서버가 있는 별도 시험망과 서버의 임대 목록 접근 권한. 직결 PC만 연결해서는 DHCP 주소가 나오지 않습니다.
1. **네트워크 설정 → 시험 인터페이스 → DHCP 사용 켬 → 적용**.
2. DHCP 서버 임대 목록에서 장비 해당 인터페이스 MAC에 할당된 IP를 확인합니다. 고정 IP 입력칸의 이전 숫자를 임대 결과로 판단하지 않습니다.
3. 같은 망 PC에서 할당 IP로 웹 로그인합니다. UI를 다시 열어 DHCP 사용 상태를 확인합니다.
**통과:** 임대 목록 MAC·IP 일치 + 실제 접속 성공. **실패:** DHCP 서버·VLAN·케이블·주소 풀 확인. **원복:** 기존 관리 경로에서 원래 고정 IP 또는 DHCP 설정 복구.
## N03. 게이트웨이·DNS / 네트워크 테스트
**UI: 네트워크 설정 → 사용 인터페이스.** 게이트웨이는 실제 라우터, DNS는 해당 망에서 도달 가능한 서버 주소를 입력하고 적용합니다.
1. **진단 도구 → 네트워크 테스트**에서 **IP 주소 / 도메인 이름**에 같은 망의 응답 가능한 PC/라우터 IP, **핑 횟수**에 `4`를 입력하고 **테스트**합니다.
2. 다른 네트워크의 응답 가능한 시험 서버 IP로 반복합니다. 첫 시험은 같은 망, 둘째는 게이트웨이 경유 통신 확인입니다.
3. 해당 서버의 실제 DNS 이름으로 반복합니다. 결과에서 이름이 예상 IP로 해석되는지, 응답·손실이 어떤지 확인합니다.
**통과:** 도달 가능하도록 준비한 대상에서 응답, 이름이 예상 IP로 해석됨. **실패 분리:** IP 성공/이름 해석 실패는 DNS, 같은 망 성공/다른 망 실패는 경로·방화벽 확인. 대상이 ICMP를 차단하면 다른 시험 대상을 사용합니다. **원복:** 원래 게이트웨이·DNS 적용.
## N04. IPv6
DDNS의 IPv6 제거와 인터페이스 IPv6는 별개입니다.
1. **네트워크 설정 → 시험 인터페이스 → IPv6 설정 보기**를 엽니다.
2. 할당받은 IPv6 주소·Prefix Length·게이트웨이·DNS를 준비합니다. 격리 직결망 예시는 장비 `fd00:50::223`, PC `fd00:50::100`, Prefix `64`, 게이트웨이 없음입니다.
3. **Static**과 준비한 값을 적용하고 PC에도 같은 프리픽스 주소를 설정합니다.
4. PC에서 `ping -6 fd00:50::223`, 브라우저에서 `http://[fd00:50::223]/` 접속을 시험합니다.
5. **Auto**는 RA를 제공하는 라우터가 있을 때 별도 시험합니다. 네트워크 관리 도구에서 실제 부여 주소를 확인한 뒤 그 주소로 접속합니다.
**통과:** 실제 주소로 접속 + 모드 재조회 일치. **실패:** PC IPv6·프리픽스·RA·방화벽 확인. **원복:** 원래 모드·주소. Disable 시험은 보조 경로에서 수행하고 IPv4 관리 접속 유지도 확인합니다.
## N05. 호스트 이름
1. **네트워크 설정 → 호스트 설정 → 호스트 이름**에 `tera-demo-01` 입력 → **적용**.
2. 다른 화면을 거쳐 다시 열어 이름을 확인하고 재시작 후에도 비교합니다.
**통과:** 저장·재조회 일치. 이름 저장이 DNS 자동 등록을 의미하지는 않습니다. 이름으로 접속하려면 DNS 레코드가 별도로 있어야 합니다. **원복:** 원래 이름 적용.
## N06. Single / Bonding / Bridge / OOB
**UI: 네트워크 설정 → 고급 설정.** 변경 전 값과 배선을 기록하고 복구 콘솔을 연결합니다. 각 모드는 서로 다른 시험이며 동시에 수행하지 않습니다.
**OOB 사전 설정:** 인터페이스 1·2에 각각 **DHCP 끔(Static IPv4), 해당 망의 주소·마스크·실제 게이트웨이**를 먼저 적용해야 합니다. 둘 중 하나라도 Static IPv4 또는 게이트웨이가 없으면 OOB 저장이 거부됩니다. N01의 게이트웨이 없는 직결 시험 구성을 그대로 OOB 시험에 쓰지 않습니다. 예비망에서 확인 대상까지 도달하는지도 먼저 시험합니다.
| 시험 | UI 설정 | 실제 시험 | 통과 증거 |
|---|---|---|---|
| Single | 운영 모드 Single, 고급 네트워크 모드 Single | 기존 관리 주소로 로그인·Ping | 독립 인터페이스 통신 유지 |
| Bonding 링크 중복 | Single → Bonding → 링크 중복(active-backup), 링크 감지 시간은 현장 기준값 | 두 링크를 같은 시험망에 구성. 관리 IP 연속 Ping 중 활성 링크만 분리, 예비 경로로 웹 재접속 | 분리 시각·중단 시간·예비 링크 복구 기록 |
| Bonding 로드 밸런싱 | Single → Bonding → 로드 밸런싱(balance-rr) | 대응 스위치 구성 후 여러 흐름 전송, 양 포트 카운터 확인 | 양 링크 트래픽. Ping 한 번으로 분산 성능 통과 판정하지 않음 |
| Bridge | Single → Bridge, STP는 시험망 설계에 맞춤 | 두 인터페이스에 서로 분리된 시험 구간 연결, 양쪽 PC 간 통신 | 두 구간 간 프레임 전달. 같은 LAN에 두 선을 꽂아 루프를 만들지 않음 |
| OOB | 운영 모드 OOB, 상태 확인 대상은 실제 응답할 IP, 확인 주기 `10`초, 전환 실패 횟수 `3` 예시 | 주 경로 Interface 1, 예비 Interface 2 준비. 주 경로에서만 대상 장애 발생 후 예비 경로 접속 | 실제 예비 접속 + OOB 경로 전환 로그/알림 |
**진행:** 한 모드 설정 → 적용 → 정상 통신 확인 → 표의 장애/트래픽 발생 → PC 출력과 로그 시간 캡처 → 케이블 복구 → 원래 모드 적용. OOB에서는 고급 모드가 Single로 제한됩니다. 10초×3은 실패 감지에 시간이 필요하다는 뜻이며 정확히 30초에 웹이 복구된다고 단정하지 않습니다.
**실패:** 스위치·VLAN·예비 경로 라우팅을 확인합니다. 두 경로와 확인 대상이 준비되지 않으면 ‘미실시’로 기록합니다.
## N07. DDNS
**준비:** 본인이 관리하는 공급자 계정·등록 도메인·갱신 권한. 인터넷 연결과 DNS가 먼저 정상이어야 합니다.
| UI: 네트워크 설정 → DDNS | 입력 |
|---|---|
| DDNS 사용 / DDNS IPv4 사용 | 켬 / 켬 |
| DNS 공급자 | 실제 계정의 공급자 |
| 사용자 이름(ID) | 공급자에서 요구하는 ID |
| 비밀번호(Token/Secret) | 해당 도메인 갱신 권한의 값 |
| IPv4 도메인 | 등록된 시험 도메인 |
| IP 확인 주소 | 해당 환경에서 사용할 공인 IPv4 확인 URL |
| Custom Provider / Path | custom 방식일 때만 준비한 공급자 정보 |
1. **적용** 후 재조회해 사용 여부·도메인을 확인합니다.
2. 공급자 관리 화면에서 A 레코드의 값·갱신 시각을 확인합니다.
3. PC에서 `nslookup 실제시험도메인`을 실행해 의도한 공인 IPv4와 일치하는지 확인합니다. TTL에 따른 캐시 지연을 고려합니다.
4. 갱신을 직접 증명하려면 전용 시험 도메인의 기존 값을 기록하고 공급자에서 다른 시험 값으로 바꾼 뒤 장비의 다음 갱신으로 복구되는지 확인합니다. 실제 서비스 도메인으로 이 시험을 하지 않습니다.
**통과:** 실제 레코드 갱신 + DNS 응답 일치. DDNS 성공만으로 외부 웹 접근을 보장하지 않습니다. NAT·포트 전달은 별도입니다. **실패:** 자격 증명 권한·도메인·장비 DNS·인터넷 확인. **원복:** 원래 DDNS와 시험 레코드 복구. DDNS UI에는 IPv6 시험 항목이 없습니다.

82
demo-guide/02-ports.md
View File

@ -0,0 +1,82 @@
# 2. 포트 설정·송수신·디버그·상태
[목차](README.md) · [알림 시험](04-alerts-logs.md)
## P01. 시리얼 매개변수와 양방향 통신
**준비:** CH01에 상대 시리얼 장비를 연결합니다. USB-RS232 어댑터를 사용하면 PC 터미널을 해당 COM 포트로 엽니다. 실제 커넥터 배선에 맞는 케이블을 사용합니다. RS232와 TTL은 구분합니다. 시험 문자열이 운영 장비의 명령으로 실행되지 않는 시험용 상대를 사용합니다.
**UI: 포트 설정 → CH01 → 매개변수.** 아래는 상대도 동일하게 맞출 수 있을 때의 예시입니다.
| 항목 | 입력 |
|---|---|
| 별칭 이름 | `DEMO-CH01` |
| 시리얼 타입 | RS232 |
| Baudrate / Databit | 9600 / 8 |
| Parity / Stopbit | None / 1 |
| Flow control | None |
| RTS / DTR | 상대 장비 요구에 맞춤. 기존값 기록 |
| 적용 대상 포트 | CH01만 선택 |
1. **적용** 후 다른 채널로 이동했다 돌아와 값을 확인합니다. CH02가 의도치 않게 바뀌지 않았는지 비교합니다.
2. **포트 설정 → CH01 → 데이터 로그**에서 **Read 기록**, **Send 기록**을 켜고 적용합니다.
3. 상대에서 시험 데이터를 먼저 보내 RX가 감지되도록 하고 **포트 디버그 → 채널 CH01 → 접속**합니다. 채널 목록은 UP 상태를 기준으로 제공됩니다. 목록에 없으면 P05의 상태와 RX/CR 응답 감지를 확인합니다. 아무 응답도 하지 않는 PC 터미널을 연결해 놓기만 하면 목록에 나타나지 않을 수 있습니다.
4. 상대 PC 터미널에서 `DEMO_RX_01`과 줄바꿈을 장비 쪽으로 보냅니다. 웹 터미널에 문자열이 보이는지 확인합니다.
5. 웹 터미널에서 `DEMO_TX_01`을 입력하고 Enter를 누릅니다. 상대 PC 터미널에서 받은 문자열을 확인합니다. 웹의 로컬 표시만으로 송신 성공을 판정하지 않습니다.
6. **로그 → 포트 로그**에서 CH01을 선택해 조회하고 두 문자열과 방향·시각을 확인합니다.
**통과:** 상대→웹, 웹→상대 양방향 문자열 일치, CH01 로그 기록. **실패:** COM 번호·배선·양쪽 9600/8N1·흐름 제어·세션 점유 확인. 글자 깨짐은 Baudrate/Parity부터 비교합니다. **원복:** 접속 해제 후 원래 통신 조건·로그 설정·별칭 복구.
## P02. 동작 설정 1: Reverse SSH / Reverse Telnet
**UI: 포트 설정 → CH01 → 동작 설정 1.** 매개변수는 P01과 상대 장비에 맞춥니다.
| 항목 | SSH 시험 예시 | Telnet 시험 예시 |
|---|---|---|
| 동작 모드 | Reverse SSH | Reverse Telnet |
| Listen Port | `10001` — 사용 중이면 다른 미사용 포트 | `10001` — SSH 시험 종료 후 전환 |
| 인증 방식 | Local | Local |
| 최대 세션 수 | `1`로 먼저 시험 | `1`로 먼저 시험 |
| 줄바꿈 | 상대 장비 요구값 | 상대 장비 요구값 |
1. CH01만 대상으로 **적용**합니다. 다른 웹 터미널/SSH 세션은 종료합니다.
2. PC PowerShell에서 `ssh -p 10001 시험웹사용자@192.168.0.223`으로 접속합니다. 해당 계정은 CH01 사용 권한이 있어야 합니다.
3. 로그인 후 상대 시리얼 장비와 양방향 시험 문자열을 교환합니다. 장비 OS SSH 포트 22 접속과 구분합니다.
4. 세션을 종료하고 같은 설정에서 Reverse Telnet으로 바꿔 적용합니다. PuTTY 등에서 Host=`192.168.0.223`, Port=`10001`, Connection type=`Telnet`으로 접속합니다. 로그인 후 동일하게 송수신합니다. Telnet 시험은 격리 시험망에서 합니다.
5. **로그 → 포트 로그**와 **로그 → 시스템 로그**에서 시험 시각의 세션 연결·해제를 확인합니다. 관련 기록 설정이 켜져 있어야 합니다.
**통과:** 선택 프로토콜의 포트로 인증 후 실제 시리얼 데이터 교환. TCP 연결만 성공한 것은 데이터 시험 완료가 아닙니다. **실패:** 모드/포트 불일치·중복 Listen Port·포트 권한·주소 필터·기존 세션 확인. **원복:** 원래 동작 모드·포트·인증·최대 세션 적용.
**추가 시험:** 최대 세션 1에서 첫 세션 유지 중 둘째를 열어 제한을 확인합니다. 이후 최대 세션을 2로 바꾸고 허용 여부를 비교합니다. 인증 방식을 RADIUS/TACACS로 시험할 때는 [외부 인증 절차](03-security.md)의 서버를 먼저 구성하고, 웹 로그인 외에 이 포트 접속에서도 서버 인증 로그를 확인합니다.
## P03. 동작 설정 2 / 사용 안 함 / 여러 포트 적용
1. **동작 설정 2**에서 동작 모드를 Reverse SSH, Listen Port를 미사용 `11001`, 인증 방식을 Local로 설정하고 CH01에 적용합니다.
2. `ssh -p 11001 시험웹사용자@192.168.0.223`에서 송수신합니다. 동작 설정 1의 10001과 혼동하지 않습니다. 세션을 순서대로 종료하며 각각 시험합니다.
3. 동작 설정 2를 **사용 안 함 → 적용** 후 해당 포트에 **새 연결**이 되지 않는지 확인합니다. 동작 설정 1은 계속 사용 가능한지도 확인합니다.
4. 일괄 적용은 운영 중이 아닌 CH01·CH02만 선택해서 동일한 매개변수 한 가지를 적용합니다. 두 채널을 각각 다시 열어 값이 같고 선택하지 않은 CH03은 그대로인지 확인합니다. 동일 Listen Port를 여러 채널에 임의로 복제하지 않습니다.
**통과:** 두 번째 설정의 실제 수신 포트 동작, 비활성화 후 신규 접속 불가, 적용 대상만 변경. **원복:** 두 채널의 원래 값 복구. Keep alive·ACK timeout·idle timeout 등 고정 표시 항목은 현재 UI에서 값을 바꾸는 시연 대상으로 잡지 않습니다.
## P04. 데이터 로그 / 포트 디버그 고급 기능
**데이터 로그 설정:** CH01 → 데이터 로그에서 Read/Send, 타임스탬프·방향·사용자·IP·포트 표시, ASCII/HEX를 원하는 시험값으로 설정하고 적용합니다.
1. Read/Send 모두 켠 상태에서 P01의 양방향 문자열이 기록되는지 확인합니다.
2. Read만 끈 뒤 상대에서 새로운 `DEMO_RX_OFF`를 보내고 웹에서 `DEMO_TX_ON`을 보냅니다. 수신은 터미널에 전달돼도 새 Read 데이터 기록은 제외되고, 켠 방향은 기록되는지 확인합니다. 기존 로그가 사라져야 하는 시험은 아닙니다.
3. Read를 다시 켜고 표시 옵션을 바꾼 뒤 **새로 보낸 데이터**의 표현을 비교합니다. ASCII `ABC`의 바이트는 HEX `41 42 43`입니다.
4. **포트 디버그 → 고급 기능**에서 전송 형식 ASCII, 전송 값 `DEMO_BATCH`, 끝 문자 CRLF → **일괄 전송**. 상대 터미널에서 문자열과 줄바꿈을 확인합니다.
5. 전송 형식을 HEX, 값 `41 42 43`, 끝 문자 없음 → **일괄 전송**. 상대에서 `ABC` 또는 동일 바이트를 확인합니다.
6. **로그 저장**으로 디버그 세션 기록을 내려받아 열어봅니다. **화면 지우기**와 고급 기능의 **로그 지우기**를 각각 눌러 화면/세션 기록 변화를 확인합니다. 장비 저장 로그 삭제는 별도의 **로그 → 포트 로그**에서 시험합니다.
**통과:** 실제 바이트·선택 방향·다운로드 내용 일치. **실패:** 상대 터미널의 로컬 에코와 실제 수신을 구분하고, 시간 검색 조건·선택 포트를 확인합니다. **원복:** 원래 Read/Send·표시 옵션으로 복구, 디버그 접속 해제.
## P05. 포트 상태 / 별칭
1. **포트 상태**에서 CH01의 상태와 시각을 기록합니다. 상대 장비가 정상 응답하도록 연결합니다.
2. 상태 갱신을 기다리고 CH01의 실제 양방향 송수신을 확인합니다. 이 장비의 응답 기반 상태 감지는 상대의 응답 여부에 영향을 받으므로 케이블 연결만으로 UP을 보장하지 않습니다.
3. 시험용 상대를 분리/종료하고 상태 변화를 기다립니다. **로그 → 포트 상태 이벤트**에서 해당 CH01의 변경 시각·이전/이후 상태를 확인합니다.
4. 상대를 복구하고 다시 송수신·상태 복귀를 확인합니다. 변화가 없으면 상대 응답 방식과 감지 조건을 점검하고, 케이블만 뽑았다는 이유로 통과 처리하지 않습니다.
5. **진단 도구 → 포트 별칭**에서 CH01의 별칭을 `DEMO-CH01`로 저장합니다. 포트 설정을 다시 열어 같은 이름인지 확인하고 CH02와 혼동되지 않는지 확인합니다.
**통과:** 실제 통신·상태 변화·이벤트 채널/시간 일치, 별칭 재조회 일치. **원복:** 원래 연결과 별칭 복구. 키워드 입력은 **CH01 → 고급 설정 → Alarm 키워드**이며 [시리얼 이벤트 시험](04-alerts-logs.md)에서 두 화면 연동까지 확인합니다.

156
demo-guide/03-security.md
View File

@ -0,0 +1,156 @@
# 3. 사용자·인증 서버·주소 필터·SNMP·SSL
[목차](README.md)
## S01. 사용자 계정과 포트 권한
1. **관리자 운영 → 사용자 계정 → 사용자 추가**. 시험 ID `demo_operator`, 역할 **포트 운영자**, 시험 비밀번호, 사용 상태와 CH01 권한을 설정해 저장합니다. CH02 권한은 주지 않습니다. 그룹을 사용한다면 그 그룹의 권한도 확인합니다.
2. 사용자 표의 **수정 / 비밀번호 / 삭제**가 겹치지 않고 클릭되는지 확인합니다. 창 폭을 줄여도 작업 버튼을 사용할 수 있는지 확인합니다.
3. 관리자 창을 유지하고 별도 비공개 창에서 새 계정으로 로그인합니다. 초기 비밀번호 변경 화면이 나오면 변경을 완료합니다.
4. CH01 접속·송수신은 허용되고 CH02는 거부되는지 확인합니다. 포트 운영자에게 로그 메뉴가 표시되지 않는지 확인합니다. 주소창으로 `/logs/ports`, `/logs/system`, `/logs/links`에 접근해도 로그 원문이 표시되지 않아야 합니다.
5. 관리자로 돌아와 계정을 수정하고 재로그인해 변경된 권한을 확인합니다. **비밀번호**에서 시험 암호를 바꾼 뒤 새 암호로 로그인합니다. 이전 암호 실패 시험은 한 번만 합니다.
6. 시험 계정을 삭제하고 새 로그인이 불가능한지 확인합니다. 실제 사용 관리자 계정을 삭제하지 않습니다.
**통과:** UI 배치 정상 + 역할·채널 권한 적용 + 암호 변경·삭제 실제 반영. **실패:** 이전 로그인 세션을 닫고 새 세션에서 확인, 그룹/개별 포트 권한 비교. **원복:** 시험 계정·그룹 정리, 기존 계정은 변경 전 권한 복구.
**본인 암호 시험:** 좌측 **비밀번호 변경**에서 현재 비밀번호·새 비밀번호·확인을 입력해 저장하고 재로그인합니다. 확인값 불일치는 저장되지 않아야 합니다. 암호는 UI 정책을 충족하게 정하고 기록물에 쓰지 않습니다.
## S02. RADIUS / TACACS
**준비:** 외부 서버에 장비를 클라이언트로 등록하고 장비의 실제 출발 IP·공유 Secret을 맞춥니다. 외부 전용 시험 사용자는 장비 로컬 사용자에 같은 ID로 만들지 않습니다. 로컬 인증 성공을 외부 인증 성공으로 오인하지 않기 위해서입니다.
| UI: 관리자 운영 → 인증 서버 | RADIUS 탭 | TACACS 탭 |
|---|---|---|
| 사용 | RADIUS 사용 켬 | TACACS 사용 켬 |
| 서버 주소 | 실제 인증 서버 IP | 실제 인증 서버 IP |
| 인증 포트 | 서버와 동일. 기존 시험 환경은 `1645`; 서버가 1812면 1812 | 서버와 동일. 일반 시험값 `49` |
| 공유 Secret | 서버의 장비 클라이언트 항목과 동일 | 서버 설정과 동일 |
| 응답 타임아웃 | `5`초 예시 | `5`초 예시 |
| 외부 사용자 기본 역할 | 포트 운영자 등 시험할 역할 | 포트 운영자 등 시험할 역할 |
1. **하나의 인증 방식부터** 켜고 **적용**합니다. 사용하지 않는 방식의 기존 상태는 기록합니다.
2. 서버 관리 화면 또는 서버 로그를 열고 시험 시작 시각을 기록합니다. 기존 Docker 시험 환경을 쓰는 경우 해당 RADIUS/TACACS 컨테이너의 Logs 탭을 열면 됩니다. 서버가 현재 실행 중인지는 별도로 확인합니다.
3. 비공개 브라우저에서 **외부 전용 사용자**와 올바른 CAPTCHA로 로그인합니다.
4. 장비 로그인 성공과 동시에 서버에서 해당 사용자·장비 출발 IP의 인증 성공 로그를 확인합니다. RADIUS는 Access-Accept, 거부 시험은 Access-Reject 등 서버가 출력하는 결과를 기록합니다.
5. 새 세션에서 비밀번호만 한 번 틀려 로그인 거부와 서버의 거부 로그를 확인합니다. CAPTCHA 오류는 외부 인증 거부 시험으로 세지 않습니다.
6. 시험 서버를 잠시 정지하거나 시험용 접근만 차단합니다. 외부 전용 계정이 성공하지 않는지, 준비해 둔 **로컬 관리자**로 관리 복구가 가능한지 확인합니다. 서버를 복구해 외부 로그인이 다시 되는지 확인합니다.
7. 포트 인증도 필요하면 **포트 설정 → 동작 설정 1 → 인증 방식 RADIUS/TACACS**로 지정하고 Reverse SSH/Telnet 신규 세션에서 같은 시험을 반복합니다. 웹 로그인만으로 포트 인증까지 통과 처리하지 않습니다.
**통과:** 정상/거부/서버 복구가 서버 로그와 일치. **실패:** 서버 무로그는 경로·방화벽·포트·등록 출발 IP, 거부 로그는 사용자·Secret·서버 정책부터 확인합니다. **원복:** 원래 인증 방식·포트 인증 설정 복구 및 시험 서버 정상화. 현재 UI에는 ‘장애 시 인증’ 선택 항목이 없습니다. 화면에 없는 스위치를 조작하는 절차는 없습니다.
## S03. 주소 필터 — PC를 구분해서 시험
`client address is denied by management address filter`는 사용자 암호가 틀렸다는 뜻이 아니라 **접속 출발 주소가 필터에 거부됐다는 뜻**입니다.
예: 관리 PC A가 `192.168.0.100`일 때 블랙리스트에 `192.168.0.0/24`를 넣으면 A도 포함됩니다. `192.168.0.101/32`는 해당 PC 한 대입니다. 필터 주소에 장비 `192.168.0.223`을 넣어 PC 차단을 시험하지 않습니다.
### IPv4 블랙리스트
1. A와 B 각각 `ipconfig`로 유선 IP를 확인하고, 두 PC 모두 현재 정상 로그인되는지 먼저 확인합니다.
2. A에서 **관리자 운영 → 주소 필터 → IPv4**를 엽니다. 전체 사용 여부·모드·기존 규칙을 기록합니다. 시험은 다른 규칙의 영향을 구분할 수 있는 상태에서 합니다.
3. 블랙리스트 모드를 선택합니다. 규칙에 B의 **실제 IPv4/32**, 프로토콜 **전체**, 규칙 사용 켬을 설정합니다. 목적지 포트는 UI 고정값 `0`을 유지합니다.
4. 규칙을 저장하고 주소 필터 전체 사용을 켜서 적용합니다. A를 포함한 `/24` 규칙이 활성화돼 있지 않은지 확인합니다.
5. B의 새 브라우저 세션에서 로그인합니다. 거부 문구 또는 해당 프로토콜 차단을 확인합니다. 동시에 A에서 페이지를 새로 열어 관리가 되는지 확인합니다.
6. 해당 시험 규칙을 끄거나 제거하고 적용한 뒤 B에서 다시 로그인합니다.
**통과:** B만 거부, A 유지, 규칙 해제 후 B 복구. HTTP만 지정해 시험한다면 B의 HTTP와 HTTPS를 각각 새 연결로 비교합니다. HTTPS까지 막혔다면 다른 전체 규칙이 있는지 확인합니다.
### IPv4 화이트리스트
1. 블랙리스트 시험을 원복하고 모드를 화이트리스트로 준비합니다.
2. **A의 실제 IPv4/32 허용 규칙을 먼저 저장**합니다. 전체 프로토콜·사용 상태를 확인한 뒤 전체 필터를 활성화합니다.
3. A의 새 세션은 성공하고 목록에 없는 B는 거부되는지 확인합니다.
4. B의 /32도 허용 목록에 추가해 적용하고 B의 새 로그인 성공을 확인합니다.
5. 시험 전 모드·규칙·전체 사용 여부로 복구합니다.
### MAC 필터
1. 동일 L2 망의 시험 PC B에서 `ipconfig /all`로 **장비에 연결된 유선 어댑터의 물리적 주소**를 확인합니다.
2. 주소 필터의 **MAC** 탭에서 그 값을 UI 형식에 맞춰 등록합니다. 블랙리스트부터 시작해 B 거부/A 허용/규칙 해제 후 B 복구를 확인합니다.
3. 화이트리스트는 A MAC 허용을 먼저 등록한 뒤 동일하게 시험합니다.
**제한:** 라우터를 경유하면 장비가 보는 MAC이 원격 PC MAC과 다를 수 있습니다. 이 경우 PC의 MAC을 넣고 원격 차단을 보장할 수 없습니다. 같은 L2 시험망을 사용합니다.
### 이미 차단된 경우
1. 암호를 반복 입력하지 않습니다. 다른 **허용된 PC**가 있으면 그 PC로 로그인해 문제 규칙을 끄고 적용합니다.
2. 허용 PC가 없으면 시리얼 관리 콘솔에서 복구합니다. 이 프로젝트 배포의 설정 파일은 `/var/lib/tera-api/auth.json`입니다. 파일에는 인증 정보가 있으므로 내용을 화면에 공개하지 않습니다.
3. 콘솔 작업자는 해당 파일을 별도 백업하고 API 서비스를 정지한 뒤 **`address_filters.enabled`만 `false`로 변경**, JSON 유효성 확인 후 기존 API 서비스를 재시작합니다. 실제 서비스 관리 방식은 장비 구성에서 확인해야 하며 확인하지 않은 서비스명을 실행하지 않습니다.
4. A에서 웹에 재접속해 문제 CIDR/MAC 규칙을 수정합니다. A 허용과 B 시험 계획을 다시 확인한 다음 필요한 필터 정책을 복구합니다. 복구를 위해 공장 초기화부터 할 필요는 없습니다.
**기록:** A/B의 실제 출발 IP·MAC, 규칙 화면, 각각의 허용/거부 화면. 현재 설정을 읽지 않고 과거 차단 규칙이 아직 남아 있다고 단정하지 않습니다.
## S04. SNMP Agent 조회
SNMP 조회는 PC가 장비의 UDP 161로 요청하는 시험입니다. 장비가 PC UDP 162로 보내는 Trap은 [알림 절차](04-alerts-logs.md)에서 별도로 시험합니다.
### v2c
| UI: 관리자 운영 → SNMP | 입력 예시 |
|---|---|
| SNMP 사용 | 켬 |
| 장비 위치(sysLocation) | `DEMO-RACK-A` |
| 관리자 연락처(sysContact) | 시험 담당자 연락처 |
| SNMP v1 / v2c / v3 | 끔 / 켬 / 끔 |
| Read Community | 별도로 정한 시험 Community |
1. **적용** 후 Net-SNMP가 설치된 PC에서 아래 명령을 실행합니다. 꺾쇠 자리는 실제 값으로 교체합니다. 도구가 없으면 SNMP 조회 프로그램에 Target IP, UDP 161, v2c, Community, 같은 OID를 입력하고 GET합니다.
```text
snmpget -v2c -c "<Read Community>" 192.168.0.223 1.3.6.1.2.1.1.6.0
snmpget -v2c -c "<Read Community>" 192.168.0.223 1.3.6.1.2.1.1.3.0
```
2. 첫 응답이 `DEMO-RACK-A`인지 확인합니다. 둘째 uptime을 잠시 후 다시 조회해 증가하는지 확인합니다.
3. UI에서 위치를 `DEMO-RACK-B`로 바꿔 적용하고 첫 명령을 반복해 변경된 실제 응답을 확인합니다.
4. 틀린 Community로 조회하면 정상 데이터가 반환되지 않는지 확인합니다. SNMP 사용을 끄고 적용해 조회 불가, 다시 켜서 조회 복구도 확인합니다.
**통과:** UI 설정 변경과 실제 GET 응답 일치. **실패:** UDP 161 경로·버전·Community·필터 확인. TCP 연결 검사만으로 SNMP를 판정하지 않습니다.
### v3
1. SNMP v3와 **v3 사용자 사용**을 켭니다. 사용자 `demo_snmp`, 접근 권한 **읽기**, 인증 **SHA-1**, 암호화 **AES**, 각각의 키를 설정하고 적용합니다. 여기서는 도구 간 비교가 쉬운 시험 조합을 사용하며 운영 정책은 별도로 선택합니다.
2. PC 조회 도구에서 v3, 사용자, authPriv, SHA-1/AES와 동일 키를 지정합니다. Net-SNMP 예시는 다음과 같습니다.
```text
snmpget -v3 -l authPriv -u demo_snmp -a SHA -A "<인증 키>" -x AES -X "<암호화 키>" 192.168.0.223 1.3.6.1.2.1.1.6.0
```
3. 위치 응답을 확인하고, 잘못된 키로는 같은 데이터가 반환되지 않는지 비교합니다. v2c를 끄고 v2c 요청 불가/v3 요청 성공도 확인합니다.
**쓰기 권한:** ‘읽기/쓰기’ 선택만으로 모든 OID가 SET 가능한 것은 아닙니다. 이 배포는 sysLocation을 에이전트 설정 파일로 생성하므로 해당 OID SET 성공을 필수 합격 기준으로 잡지 않습니다. 쓰기 시험은 에이전트가 지원하는 쓰기 가능한 OID·원래 값이 확인된 경우 별도 실시합니다. 확인되지 않았다면 ‘쓰기 미실시’로 기록합니다.
**원복:** 원래 버전·사용자·키·위치·연락처·사용 상태 복구. 명령 기록과 캡처에서 키/Community를 가립니다.
## S05. SSL 생성과 실제 HTTPS 인증서 확인
사용자가 만든 화면은 다음 입력 예시입니다. **생성 화면만으로 활성 인증서 교체까지 확인된 것은 아닙니다.**
![사용자가 제공한 인증서 입력 예시](assets/ssl-certificate-example.png)
| UI: 관리자 운영 → SSL 인증서 → 새로 만들기 | 값 |
|---|---|
| 인증서 ID | 자동 표시 `device-192-168-0-223` 예시 |
| 공통 이름(CN) | `192.168.0.223` |
| 국가(C) | `KR` |
| 조직(O) | `TERA-TEST` |
| 나머지 선택 항목 | 필요 없으면 비움 |
1. 이미 생성했다면 중복 생성하지 말고 **인증서** 탭에서 해당 항목을 찾습니다. 없으면 위 값으로 **생성**합니다.
2. 현재 활성 인증서를 기록합니다. **활성 인증서**에서 만든 항목 선택 → **적용**.
3. 목록에서 선택한 인증서의 상태·유효 기간·키 보유 여부를 확인합니다.
4. 새 브라우저 창으로 **`https://192.168.0.223/`**에 접속합니다. HTTP 페이지로 성공 판정하지 않습니다.
5. 브라우저 주소창의 사이트 정보에서 인증서 보기를 열어 Subject의 CN, 조직, 발급자, 유효 기간, SAN의 접속 IP를 확인합니다. 생성한 값과 실제 제공 인증서가 같아야 합니다.
6. HTTPS로 로그인하고 메뉴 하나를 열어 정상 동작을 확인합니다. 이전 인증서가 보이면 기존 연결을 닫고 새 세션에서 다시 확인합니다.
**통과:** 실제 HTTPS가 제공한 인증서 내용과 생성값 일치 + HTTPS 로그인. 자체 서명이라 신뢰 경고가 생기는 것과 만료·주소 불일치는 구분합니다. 경고가 없는 시연을 원하면 해당 PC가 신뢰하는 CA가 발급하고 접속 주소가 SAN에 포함된 인증서를 사용해야 합니다.
**실패:** 장비 시간·접속 주소·활성 선택·개인키·443 연결 확인. **원복:** 원래 인증서를 활성화해 HTTPS에서 다시 비교합니다. 원복 확인 전에 기존 인증서를 삭제하지 않습니다.
## S06. SSL 가져오기 / CSR
**가져오기:** 서명된 PEM 인증서와 대응 개인키를 준비합니다. **SSL 인증서 → 가져오기**에서 인증서 파일, 개인 키 파일, 암호화된 키라면 키 비밀번호를 선택 → **가져오기**. 키를 생략하려면 장비에 대응 키가 이미 있어야 합니다. 목록에 추가된 것과 실제 활성화를 구분하고 S05의 활성화·HTTPS 비교를 반복합니다. 다른 키 조합으로 시험한다면 적용이 거부되거나 활성화할 수 없는 상태인지 확인하고 기존 활성 인증서가 유지되는지 확인합니다.
**CSR:** **CSR 내보내기**에서 키가 있는 인증서를 선택하고 CN·조직·이메일을 확인한 뒤 내보냅니다. 내려받은 파일에 `BEGIN CERTIFICATE REQUEST`가 있는지 확인합니다. CA에 제출해 서명 인증서를 받은 뒤 가져오기·활성화·HTTPS 비교까지 해야 발급 적용 시험이 끝납니다. CSR 다운로드 자체는 CA 발급 완료가 아닙니다.
**원복:** 원래 활성 인증서로 복귀하고 시험용 인증서만 정리합니다. 개인키를 시연 자료나 저장소에 첨부하지 않습니다.

146
demo-guide/04-alerts-logs.md
View File

@ -0,0 +1,146 @@
# 4. 알림 설정·실제 수신·시스템 로그·삭제
[목차](README.md)
**알림은 두 곳을 설정합니다:** 메일/Trap/Syslog의 **수신 목적지 설정**과, 시스템/시리얼 이벤트의 **발생 조건 및 전달 스위치**입니다. 목적지 테스트가 성공해도 이벤트 전달이 꺼져 있으면 실제 이벤트 알림은 오지 않습니다.
## A01. 메일
| UI: 기타 설정 → 알림 설정 → 메일 | 입력 |
|---|---|
| 메일 알림 사용 | 켬 |
| SMTP 서버 / SMTP 포트 | 실제 서버와 포트. STARTTLS 서버가 587을 사용하는 경우 587 |
| STARTTLS 사용 | 서버 요구에 맞춤. STARTTLS와 암시적 TLS 포트를 혼동하지 않음 |
| SMTP 인증 사용 | 서버가 요구하면 켬 |
| SMTP 사용자 / 비밀번호 | 서버에서 허용한 발송 계정과 자격 증명 |
| 발신자 | 해당 계정이 발송 권한을 가진 주소 |
| 수신자 / 참조(CC) | 실제 확인 가능한 시험 수신함 |
| 제목 / 본문 | `TERA DEMO MAIL` / 시험 시각을 포함한 문구 |
1. **적용** 후 **테스트 발송**을 누릅니다.
2. 수신함을 열어 새 메일의 발신자·수신자·제목·본문·시각을 확인합니다. 스팸함도 확인합니다.
3. 테스트 발송 결과와 실제 수신 메일을 함께 캡처합니다.
**통과:** 실제 시험 수신함에 도착. **실패:** 발송 오류는 DNS·SMTP 포트·TLS 방식·계정·발신자 권한, 성공 안내 후 미수신은 서버 전달 로그·스팸·수신 주소 확인. **원복:** 원래 SMTP·수신자·사용 여부 복구. 실제 이벤트 발송은 A04를 수행합니다.
## A02. SNMP Trap
**준비:** PC/서버에 Trap 수신기를 실행하고 UDP 162 수신을 허용합니다. 이미 다른 프로그램이 162를 사용하면 그 프로그램을 수신기로 쓰거나 테스트 포트를 별도로 맞춥니다.
1. 수신기에서 v2c Community를 시험용 값으로 등록합니다. Net-SNMP 수신기 예시: `trap-demo.conf`에 `authCommunity log DEMO_TRAP` 한 줄을 저장하고 아래처럼 실행합니다. 도구 설치와 포트 수신 권한은 별도 준비입니다.
```text
snmptrapd -f -Lo -C -c trap-demo.conf udp:162
```
2. **기타 설정 → 알림 설정 → SNMP Trap**에 다음을 입력합니다.
| UI 항목 | 값 |
|---|---|
| Trap 전송 사용 | 켬 |
| 대상 ID | 고정값 유지 |
| 대상 주소 | 수신 PC의 실제 유선 IP, 예: `192.168.0.100` |
| 대상 포트 / 버전 | `162` / `v2c` |
| Community / 인증 키 | 수신기와 동일한 시험값. 위 예시는 `DEMO_TRAP` |
3. **적용 → 테스트 전송**. 수신기에서 장비 출발 IP, 도착 시각, OID/변수 값을 확인합니다.
4. 이어서 A04의 키워드 이벤트에서 **SNMP Trap으로 전달**을 켜고 실제 문자열을 보내 별도의 이벤트가 들어오는지 확인합니다.
**통과:** 테스트 패킷과 실제 이벤트를 수신기에서 각각 확인. UDP 전송 성공 안내만으로 수신 성공을 판정하지 않습니다. **실패:** 대상이 장비 IP가 아닌 수신 PC IP인지, UDP 162 방화벽·Community·수신기 바인딩 확인.
**v1/v3 추가 시험:** 수신기가 해당 버전을 처리하도록 먼저 설정하고 UI 버전을 일치시킵니다. v3는 사용자·인증·암호화·키·Engine ID를 수신기 등록값과 맞춘 뒤 테스트 전송과 실제 이벤트를 반복합니다. v2c 수신 성공을 v3 성공으로 기록하지 않습니다. **원복:** 원래 대상·자격 증명·전송 여부, 시험 수신기 종료.
## A03. Syslog 수신과 기록 범위
1. PC/서버의 Syslog 수신기를 UDP 514로 실행합니다. Windows에서 간단한 **UDP 내용 확인**만 할 경우, 사용하지 않는 포트임을 확인하고 아래 PowerShell을 별도 창에서 실행할 수 있습니다. 이 창은 Ctrl+C로 종료합니다. Windows 방화벽에서 시험망의 UDP 514 수신도 허용돼야 합니다.
```powershell
$demoSyslog = [System.Net.Sockets.UdpClient]::new(514)
$demoSender = [System.Net.IPEndPoint]::new([System.Net.IPAddress]::Any, 0)
try {
while ($true) {
$demoBytes = $demoSyslog.Receive([ref]$demoSender)
Write-Host ((Get-Date -Format o) + ' ' + $demoSender.ToString() + ' ' + [Text.Encoding]::UTF8.GetString($demoBytes))
}
} finally {
$demoSyslog.Close()
}
```
2. **기타 설정 → 시스템 로그 → 로그 서버**에서 **원격 로그 전송 사용 켬**, 로그 서버 `192.168.0.100:514`(실제 수신 PC), 전송 프로토콜 **UDP** → **적용**.
3. **로그 이벤트** 탭에서 **설정 변경 이벤트 - 로컬 저장**, **설정 변경 이벤트 - 원격 전송**을 켜고 적용합니다. 시스템 이벤트·운영 모드 이벤트도 시험하려면 각각 로컬/원격 스위치를 켭니다.
4. **네트워크 설정 → 호스트 설정**에서 기존 이름을 기록하고 `tera-demo-log`로 변경·적용합니다.
5. **로그 → 시스템 로그**에서 시험 시각의 설정 변경 기록을 찾습니다. 동시에 수신 PC에 도착한 장비 출발 IP·설정 변경 메시지를 확인합니다.
6. 원격 전달만 끄고 이름을 다른 시험값으로 바꿉니다. 로컬에는 새 이벤트가 있지만 원격에는 같은 새 이벤트가 오지 않는지 비교합니다. 원격을 다시 켜고 다음 변경이 수신되는지 확인합니다.
**통과:** 같은 시험 이벤트의 로컬 저장/원격 수신이 스위치와 일치. **실패:** 서버 주소·UDP/TCP 일치·수신기·이벤트 종류 스위치 확인. **TCP 시험:** TCP 지원 수신기를 별도로 준비하고 수신기와 UI를 모두 TCP로 변경해 4~5번을 반복합니다. 위 PowerShell UDP 수신기로 TCP를 시험할 수 없습니다. **원복:** 호스트 이름·서버·전달 범위·방화벽 시험 규칙 복구.
## A04. 시리얼 감지 키워드와 포트 고급 설정 연동
**준비:** [CH01 양방향 통신](02-ports.md)과 A01/A02/A03 중 사용할 수신 경로 하나를 먼저 통과합니다. 아래는 메일을 예로 합니다.
| UI: 기타 설정 → 알림 설정 → 시리얼 이벤트 | 값 |
|---|---|
| 대상 포트 | CH01 |
| 수신 키워드 감지 | 켬 |
| 감지 키워드 | `DEMO_ALARM_01` |
| 메일로 전달 | 켬 |
| SNMP Trap / Syslog로 전달 | 각각 수신 시험을 할 때 켬 |
| DCD / DSR 상태 변경 | 우선 끔 — 키워드 시험과 분리 |
1. **적용** 후 다른 포트를 선택했다 CH01로 돌아와 키워드를 확인합니다.
2. **포트 설정 → CH01 → 고급 설정 → Alarm 키워드**에서 같은 값이 보이는지 확인합니다.
3. **상대 시리얼 장비/PC에서 TERA가 수신하는 방향으로** `DEMO_ALARM_01`을 한 번 보냅니다. 웹에서 상대에게 송신하는 것만으로 수신 키워드 시험을 대신하지 않습니다.
4. CH01 포트 로그에서 수신 데이터, 선택한 수신함/Trap/Syslog에서 해당 채널의 키워드 이벤트를 확인합니다. 시각으로 같은 시험임을 대조합니다.
5. 고급 설정에서 키워드를 `DEMO_ALARM_02`로 바꿔 적용합니다. 시리얼 이벤트 화면을 다시 열어 동일하게 바뀌었는지 확인합니다.
6. 상대에서 일반 문자열 `NORMAL_ONLY`와 이전 키워드 `DEMO_ALARM_01`을 각각 보내고 새 키워드 이벤트가 발생하지 않는지 관찰합니다. 이어 `DEMO_ALARM_02`를 보내 발생을 확인합니다. 각 문자열은 구분해 보내고 중복 억제/발송 지연이 있다면 처리 후 다음 시험을 합니다.
7. 수신 키워드 감지를 끄고 적용한 뒤 새 키워드를 다시 보내 알림이 발생하지 않는지 확인합니다. 포트 데이터 자체는 계속 수신돼야 합니다.
**통과:** 두 UI의 값이 양방향으로 연동되고 현재 키워드 수신 때만 선택한 목적지로 이벤트가 도착. 단순 저장 성공만으로 통과하지 않습니다. **실패:** 대상 포트·수신 방향·문자열·이벤트 감지 스위치·전달 스위치·목적지 설정 순서 확인. **원복:** 원래 키워드와 감지/전달 상태 복구.
## A05. DCD/DSR 및 시스템 이벤트
| UI와 이벤트 | 설정·발생 방법 | 확인 위치·통과 기준 |
|---|---|---|
| 시리얼 이벤트: DCD 상태 변경 | 대상 CH01, DCD 켬, 목적지 전달 켬 → 적용. 핸드셰이크 신호 제어가 가능한 시험 장치로 실제 DCD 신호 변화 | 수신 목적지에서 CH01의 DCD 변화 확인 |
| 시리얼 이벤트: DSR 상태 변경 | 위와 같이 DSR만 켜고 실제 신호 변화 | CH01의 DSR 변화 확인. 문자열 송신만으로 DSR 시험을 대신하지 않음 |
| 시스템 이벤트: 시리얼 링크 DOWN | 시스템 이벤트 탭의 해당 항목과 전달 켬 → 적용. 시험 포트를 정상 응답 상태로 만든 뒤 상대 분리 | 포트 상태 DOWN 전환·상태 이벤트·알림 시각 일치 |
| 이더넷 링크 DOWN | 해당 항목과 전달 켬. 관리 연결을 유지할 수 있는 보조 시험 링크만 분리 | 해당 인터페이스 DOWN 알림과 실제 연결 변화 일치 |
| OOB 경로 전환 | 해당 항목과 전달 켬. 준비된 OOB 시험망에서 주 경로 장애 발생 | 예비 경로 실제 통신 + 전환 알림 |
| Warm start | 해당 항목과 전달 켬. 백업 후 상단 저장 후 재시작 | 복구 후 Warm start 로그·수신 알림 확인 |
| Cold start | 해당 항목과 전달 켬. 시험 장비 정상 종료/전원 재인가 절차에 따라 수행 | 복구 후 Cold start 로그·알림 확인 |
| 로그인 실패 임계값 | 해당 항목과 전달 켬. 별도 시험 계정으로 설정된 임계값만큼 올바른 CAPTCHA/잘못된 암호 시험 | 서버/장비 실패 기록과 임계 이벤트·수신 알림 일치 |
| 저장 공간 경고 | 해당 항목과 전달 켬. 승인된 시험용 저장소/시뮬레이션에서 경고 조건 발생 | 실제 경고 조건·로그·알림 일치 |
시스템 이벤트의 UI에는 로그인 실패 횟수나 저장 공간 임계값을 직접 입력하는 칸이 없습니다. 시험 전 적용된 임계값을 담당자가 확인하지 못했다면 해당 항목은 ‘조건 미확인/미실시’로 둡니다. 경고 시연을 위해 운영 저장소를 임의로 가득 채우지 않습니다. DCD/DSR 배선·신호 발생 장치가 없을 때도 미실시입니다.
**원복:** 신호·배선·전원·계정 잠금 여부를 정상화하고 원래 이벤트/전달 설정 복구. 이벤트 발생 순간 전송 경로가 끊겼다면 미수신을 즉시 이벤트 감지 실패로 결론내리지 말고 장비 로컬 기록과 수신 경로를 함께 확인합니다.
## L01. 로그 조회와 다운로드
1. **기타 설정 → 시스템 로그 → 로그 이벤트**에서 시험할 종류의 **로컬 저장**을 켭니다.
2. 설정 변경, 포트 세션 연결/해제, P01 송수신, P05 상태 전환을 한 번씩 발생시키고 시각·채널을 기록합니다.
3. **로그 → 시스템 로그 / 포트 로그 / 포트 상태 이벤트**를 각각 엽니다. 시스템은 등급·검색어·시작/종료 시간, 포트는 채널과 검색 조건을 지정하고 **조회**합니다.
4. 보이지 않으면 **검색 초기화**, 시간 범위와 장비 시간 확인 후 다시 조회합니다. 자동 갱신을 켰다면 새 시험 이벤트가 들어오는지 확인합니다.
5. 다운로드 형식과 최대 다운로드 건수를 선택하고 **로그 다운로드**합니다. 내려받은 파일을 열어 UI에서 확인한 시험 시각·문자열·채널이 들어 있는지 확인합니다.
**통과:** 발생시킨 이벤트를 올바른 로그에서 찾고 파일에서도 확인. 다운로드에는 검색 조건·최대 건수 제한이 적용됩니다. 화면 내보내기를 무제한 전체 백업으로 가정하지 않습니다. **원복:** 원래 저장 범위·검색 설정 복구.
## L02. 단일 포트·전체 포트·상태 이벤트·시스템 로그 삭제
**준비:** 필요한 기록을 먼저 다운로드합니다. 설정 백업에는 로그 원문이 없습니다. 삭제 전 CH01/CH02에 서로 다른 시험 문자열을 남기고, 시스템·상태 이벤트도 하나씩 확보합니다. 삭제 범위는 검색된 몇 줄이 아니라 해당 저장 범위 전체입니다.
| 시험 | UI 조작 / 확인 입력 | 삭제 후 확인 | 보존 확인 |
|---|---|---|---|
| CH01만 삭제 | 로그 → 포트 로그 → CH01 선택 → 로그 클리어 (삭제) → `CH01` | 검색 초기화 후 CH01의 삭제 전 문자열 없음 | CH02와 시스템·상태 이벤트 존재 |
| 전체 포트 삭제 | 포트 로그 → 전체 포트 선택 → 로그 클리어 (삭제) → `ALL` | CH01·CH02 각각 조회해 삭제 전 문자열 없음 | 시스템·상태 이벤트 존재 |
| 포트 상태 이벤트 전체 삭제 | 로그 → 포트 상태 이벤트 → 로그 클리어 (삭제) → `LINKS` | 삭제 전 상태 전환 기록 없음 | 현재 링크 상태 및 시스템·포트 통신 로그 유지 |
| 시스템 로그 전체 삭제 | 로그 → 시스템 로그 → 로그 클리어 (삭제) → `SYSTEM` | 삭제 전 시스템 이벤트와 감사 기록 없음 | 포트 통신·상태 이벤트 유지 |
1. 먼저 잘못된 확인 문자열을 입력하거나 취소해 삭제되지 않는지 확인합니다.
2. 표의 시험을 한 개씩 수행합니다. 앞 시험에서 기록을 지웠다면 다음 시험의 보존 대조용 데이터를 새로 만듭니다.
3. 각 삭제 후 페이지를 새로 열고 검색 조건을 해제해 과거 문자열/시각이 사라졌는지 확인합니다.
4. 새 데이터를 발생시켜 다시 기록되는지 확인합니다. 새 수집과 삭제 작업 관련 기록 때문에 ‘영원히 0건’이 합격 기준은 아닙니다.
5. 마지막 유지 시험에서 **저장 후 재시작** 후에도 삭제 전 시험 기록이 되살아나지 않는지 확인합니다.
**통과:** 지정 범위의 과거 기록 삭제 + 다른 범위 보존 + 신규 수집 지속. **원복:** 삭제한 원문은 UI 복원할 수 없습니다. 필요한 증빙은 삭제 전에 다운로드해 보관합니다.

68
demo-guide/05-maintenance.md
View File

@ -0,0 +1,68 @@
# 5. 백업·복원·시간·재시작·펌웨어·초기화
[목차](README.md)
## M01. 설정 백업과 실제 복원 확인
1. **포트 설정 → CH01 → 매개변수**에서 원래 별칭을 기록하고 시험 별칭 `DEMO-BEFORE-BACKUP`을 적용합니다.
2. **관리자 운영 → 백업/복원 → 내보내기**에서 백업 암호와 확인값을 동일하게 입력합니다. 암호는 UI 범위인 8~64자 안에서 정하고 별도 보관합니다.
3. **백업 다운로드**를 눌러 파일이 저장됐는지, 크기가 0이 아닌지 확인합니다. 파일명·백업 시각·별칭을 기록합니다. 암호 불일치 입력은 다운로드가 진행되지 않아야 합니다.
4. CH01 별칭을 `DEMO-AFTER-BACKUP`으로 바꿔 적용하고 다시 읽어 변경을 확인합니다.
5. **백업/복원 → 복원**에서 방금 받은 설정 파일과 백업 암호를 입력합니다. 첫 시험은 **네트워크 설정 포함을 끕니다**. 복원 화면의 **복원 및 적용**을 실행합니다.
6. 화면 갱신/필요한 재로그인 후 CH01 별칭이 `DEMO-BEFORE-BACKUP`으로 돌아왔는지 확인합니다. 관리 주소도 유지되는지 확인합니다.
7. 동일 파일에 잘못된 암호를 입력해 복원이 거부되는지, 현재 별칭이 그대로인지 확인합니다. 정상 암호로 반복할 때는 설정이 다시 바뀔 수 있음을 고려합니다.
**통과:** 파일 다운로드뿐 아니라 실제 설정값이 백업 시점 값으로 복귀. **실패:** 파일 종류·암호·오류 안내 확인. 펌웨어 .pkg를 설정 복원 파일로 선택하지 않습니다. **원복:** 시험 전 별칭 복구. 복원은 별칭 한 개만 되돌리는 기능이 아니므로 그 사이 바꾼 다른 설정도 백업 시점으로 복귀하는지 점검합니다.
**네트워크 포함 복원:** 별도 시험망과 콘솔을 준비한 후 진행합니다. 백업 속 주소를 먼저 기록하고 현재 주소를 다른 시험 주소로 바꾼 다음, 네트워크 포함으로 복원합니다. 백업 속 주소로 재접속하고 주소·마스크·DNS가 복귀했는지 확인합니다. 주 관리망에서 첫 복원 시험으로 선택하지 않습니다.
## M02. 날짜·시간
**UI: 기타 설정 → 날짜와 시간.** 변경 전 시간대·NTP 설정을 기록합니다.
1. **시간대 Asia/Seoul**, **NTP 사용 켬**, 시험망에서 도달 가능한 **NTP 서버 1·2**를 입력하고 **적용**합니다.
2. 화면을 다시 열어 설정 유지와 장비 표시 시간을 확인합니다. 정확한 기준 시계와 비교하고 이후 생성한 로그의 시각도 확인합니다.
3. 수동 설정 시험은 **NTP 사용 끔**, 수동 날짜·시간을 현재 실제 시각으로 입력하거나 제공되는 PC 시간 동기화 기능을 사용해 적용합니다. 새 로그를 하나 만들어 시각을 비교합니다.
4. 시간대만 UTC로 바꿔 한국시간 대비 9시간 차이인지 확인한 뒤 Asia/Seoul로 복구합니다. 테스트를 위해 시간을 크게 틀리게 설정하지 않습니다.
**통과:** 저장값 유지 + 실제 표시/신규 로그 시각 일치. NTP 스위치 켜짐만으로 동기화 성공을 증명하지 않습니다. 정확한 동기화 상태가 UI에 없다면 실제 NTP 동기화 상태는 운영 도구로 추가 확인하고 그 전에는 ‘설정 확인’으로만 기록합니다. **실패:** DNS·UDP 123 경로·서버·시간대 확인. **원복:** 원래 시간대·NTP 설정 적용, 최종 실제 시각 확인.
## M03. 저장 후 재시작
1. 대표 설정(호스트 이름, CH01 별칭/통신 조건, 키워드, 알림 사용 여부)을 기록합니다. 활성 세션 종료, 필요한 로그 다운로드, 설정 백업을 마칩니다.
2. 화면 상단 **저장 후 재시작**을 누르고 확인 안내에 따라 실행합니다.
3. 잠시 접속이 끊기는 것을 기록하고 동일 관리 주소에서 준비 완료를 기다립니다. 실행 버튼을 반복해서 누르지 않습니다.
4. 재로그인 후 대표 설정을 각각 다시 열어 비교합니다. CH01 양방향 송수신, 키워드 실제 알림, HTTPS 접속을 반복합니다.
5. 시스템 로그/알림에서 재시작 이벤트를 확인합니다. 삭제 시험을 했다면 삭제 전 기록이 복구되지 않았는지도 확인합니다.
**통과:** 준비 완료·재로그인·설정 유지·실제 통신 복구. **실패:** DHCP라면 임대 주소, 링크, 콘솔 부팅 상태 확인. **원복:** 재시작 자체는 되돌릴 작업이 없으며 변경한 시험 설정을 원래 값으로 복구합니다.
## M04. 펌웨어
**UI: 관리자 운영 → 펌웨어.** 먼저 대상 모델·현재 버전·설정 백업·복구 방법·적용할 패키지의 출처와 버전을 기록합니다.
**현재 UI는 실행 확인 후 업로드 → 서명/호환성 검증 → 적용 요청으로 이어집니다. ‘검증만 하고 멈추기’용 버튼으로 사용하면 안 됩니다.** 실제 업그레이드를 할 시험 장비와 호환 패키지가 준비된 경우에만 실행합니다.
1. 장비 모델에 맞고 신뢰된 서명이 포함된 최종 `.pkg`를 선택합니다. `tera-api`, `tera-web` 등 개별 실행 파일이나 임의 ZIP의 확장자를 바꾼 파일은 패키지가 아닙니다.
2. **업데이트 적용** 버튼과 확인창을 통해 시작합니다. 표시되는 업로드·검증·적용·재연결 상태를 기록합니다.
3. 적용 중 전원/네트워크를 유지하고 재연결을 기다립니다. ‘업로드 완료’ 또는 ‘검증 완료’를 업데이트 완료로 기록하지 않습니다.
4. **펌웨어 업데이트 완료** 상태, 준비 완료 및 재로그인을 확인합니다. 장비 정보의 버전/빌드 표시가 제공되면 계획한 패키지와 비교합니다. 버전 표시만으로 구분할 수 없다면 배포 담당자의 설치 버전 검증 결과도 함께 확보합니다.
5. 대표 기능(포트 송수신, 인증, HTTPS, 로그, 설정 유지)을 다시 시험합니다.
**거부 시험:** 호환성/서명 실패용으로 준비된 시험 패키지가 있을 때만 수행합니다. 오류 사유와 기존 펌웨어로 정상 관리 가능한지 확인합니다. 유효한 패키지를 선택하면 실제 적용까지 진행될 수 있습니다.
**현 자료와의 관계:** 저장소의 `final-build` 실행 파일 묶음은 그 자체로 `.pkg`가 아닙니다. 이전 `external-fit-20260909-v8` 패키지가 이후 UI/로그 수정까지 포함한다고 가정할 수 없습니다. 시연에 사용할 최종 패키지는 해당 변경 포함 여부가 확인된 산출물을 배포 담당자가 지정해야 합니다.
**원복:** 이전 버전 재설치는 검증된 호환 패키지와 해당 버전의 복원 절차로 별도 수행합니다. UI 업그레이드 취소만으로 이미 적용된 펌웨어를 되돌릴 수 있다고 가정하지 않습니다.
## M05. 공장 초기화
**마지막 별도 시험입니다.** 설정·사용자·로그 등이 지워질 수 있으므로 시험 장비, 설정 백업과 암호, 로그 다운로드, 콘솔, **초기화 후 기본 네트워크와 초기 로그인 정보**를 먼저 확보합니다. 현재 주소 `192.168.0.223`이 초기화 후에도 유지된다고 가정하지 않습니다.
1. **공장 초기화** 화면에서 삭제 안내를 읽고 확인 입력란에 **`공장 초기화`**를 정확히 입력합니다.
2. **공장 초기화 실행**과 확인창을 통해 실행합니다. 전원을 유지하고 재부팅/준비 완료를 기다립니다.
3. 사전에 확보한 기본 주소와 초기 계정으로 로그인하고 초기 비밀번호 변경이 요구되면 완료합니다.
4. 시험용 사용자·별칭·필터·알림 설정이 초기 상태로 돌아왔는지 확인합니다. 펌웨어 교체 시험과 혼동하지 않습니다.
5. 필요하면 M01로 백업을 복원하고 통신·관리 접속을 재확인합니다. 네트워크 포함 복원 시 접속 주소 전환도 준비합니다.
**통과:** 초기 설정으로 관리 가능 + 필요한 경우 백업 복원 후 기능 회복. 기본 주소/계정과 복구 경로를 확보하지 못했으면 미실시로 둡니다. 백업 복원으로 삭제된 로그 원문까지 되살아난다고 가정하지 않습니다.

56
demo-guide/06-results.md
View File

@ -0,0 +1,56 @@
# 6. 시연 결과 기록표
[목차](README.md)
실시일: ______ / 시험자: ______ / 장비·버전: ______ / 장비 IP: ______ / PC A·B IP: ______
**판정:** 통과 / 실패 / 미실시. 준비물이 없거나 실제 결과를 확인하지 못한 경우 미실시입니다. 각 기능별로 입력값 화면과 실제 결과 증빙을 함께 남깁니다. 암호·키는 가립니다.
| ID | 시험 | 통과 판정에 필요한 증빙 | 결과 / 파일명 / 메모 |
|---|---|---|---|
| 공통 | 로그인·대시보드·언어 | 정상 로그인, CAPTCHA 거부, 장비 정보·배치 | 미실시 |
| N01 | 고정 IPv4 | 새 주소 웹 로그인·재조회 | 미실시 |
| N02 | DHCP | MAC 대응 임대 주소·로그인 | 미실시 |
| N03 | 경로·DNS·핑 | 같은 망/다른 망/이름 시험 출력 | 미실시 |
| N04 | IPv6 Static/Auto/Disable | 각 모드 실제 주소·접속 결과 | 미실시 |
| N05 | 호스트 이름 | 저장·재시작 후 이름 | 미실시 |
| N06 | Single/Bonding/Bridge/OOB | 모드별 배선·트래픽/장애 전환 기록 | 미실시 |
| N07 | DDNS | 공급자 갱신·DNS 실제 응답 | 미실시 |
| P01 | 매개변수·양방향 통신 | 양쪽 터미널 문자열과 CH01 로그 | 미실시 |
| P02 | Reverse SSH/Telnet·인증·세션 제한 | 프로토콜별 인증·송수신·제한 결과 | 미실시 |
| P03 | 동작 설정 2·비활성화·일괄 적용 | 두 번째 포트 접속·대상별 값 | 미실시 |
| P04 | 데이터 기록·디버그 고급 기능 | 방향별 기록·HEX 바이트·다운로드 | 미실시 |
| P05 | 포트 상태·별칭 | 실제 상태 전환·이벤트·별칭 | 미실시 |
| S01 | 계정·역할·채널·암호·삭제 | 허용/거부 화면·UI 배치 | 미실시 |
| S02 | RADIUS/TACACS | 각 서버 성공/거부/장애 복구 로그 | 미실시 |
| S03 | IPv4/MAC 블랙·화이트리스트 | A 허용/B 거부/원복 후 B 허용 | 미실시 |
| S04 | SNMP v2c/v3 | 변경 위치 GET·잘못된 키 거부 | 미실시 |
| S05 | SSL 생성·활성화 | HTTPS 실제 인증서·로그인 | 미실시 |
| S06 | SSL 가져오기·CSR | 키 대응·실제 제공 인증서·CSR 파일 | 미실시 |
| A01 | 메일 | 테스트 발송과 실제 수신함 | 미실시 |
| A02 | Trap | 버전별 테스트·실제 이벤트 수신 | 미실시 |
| A03 | Syslog UDP/TCP·저장 범위 | 각 프로토콜 수신·로컬 비교 | 미실시 |
| A04 | 키워드 편집·화면 연동·감지 | 이전/새 키워드 수신과 알림 비교 | 미실시 |
| A05 | DCD/DSR·시스템 이벤트 | 이벤트별 실제 조건·수신·원복 | 미실시 |
| L01 | 조회·다운로드 | UI 기록과 파일 내용 일치 | 미실시 |
| L02 | 단일/전체 포트·상태·시스템 삭제 | 범위별 삭제·보존·신규 수집·재시작 유지 | 미실시 |
| M01 | 백업·복원 | 백업값 복귀·암호 오류 거부 | 미실시 |
| M02 | 시간·NTP·시간대 | 설정과 실제 시간·로그 비교 | 미실시 |
| M03 | 저장 후 재시작 | 설정 유지·통신/알림 복구 | 미실시 |
| M04 | 펌웨어 | 최종 성공·버전 확인·대표 기능 재시험 | 미실시 |
| M05 | 공장 초기화 | 기본 설정 로그인·필요 시 복원 | 미실시 |
## 개별 시험 기록 — 복사해 사용
- 시험 ID / 세부 조건:
- 변경 전 값:
- UI에 입력한 값(비밀값 제외):
- 적용 결과:
- 시험 시작/종료 시각:
- 발생시킨 동작 또는 보낸 문자열:
- 실제 확인한 결과 / 증빙 파일:
- 기대 결과와 차이:
- 통과 / 실패 / 미실시:
- 원복한 값과 실제 재확인 결과:
여러 모드가 있는 행은 세부 시험마다 기록을 나눕니다. 예를 들어 SNMP v2c만 확인했으면 v3까지 통과로 적지 않습니다.

257
demo-guide/README.md
View File

@ -1,209 +1,68 @@
# TERA 장비 시연 자료
# TERA UI 설정·동작 확인 실습 절차서
작성일: 2026-09-10 · 대상: 현재 시연용 48포트 장비 · 권장 진행 시간: 35~45분
작성: 2026-09-10. 관리자 웹 UI 기준. **각 절차는 UI 입력값 → 적용 순서 → 실제 시험 → 성공 확인 → 원복 순서입니다.**
**시연 순서:** 로그인 → 포트 송수신 → 알림 → 사용자 권한 → 주소 필터 → SNMP → SSL 인증서 → 로그 조회·삭제 → 백업·복원.
이 문서는 수행할 시험 방법입니다. 문서 작성만으로 실장비 시험을 통과했다는 뜻은 아닙니다. 실제 결과는 [결과 기록표](06-results.md)에 별도로 작성합니다.
이 자료의 절차는 시연자가 수행할 시험입니다. 절차가 적혀 있다는 사실이 실기 시험 완료를 의미하지는 않습니다. 배포·자동 테스트 결과는 [최종 빌드 안내](../final-build/README.md)와 구분합니다. 첨부 화면은 사용자가 제공한 인증서 생성 입력 예시이며 활성화 완료 증빙은 아닙니다.
## 바로 찾기
## 1. 준비 및 기록
| 항목 | 시연 환경 / 입력 예시 |
| 설정할 기능 | 입력·시험·판정 절차 |
|---|---|
| 장비 관리 주소 | http://192.168.0.223/ |
| HTTPS 주소 | https://192.168.0.223/ |
| 현재 관리 PC | 192.168.0.100 — 시연 전 실제 유선 IP 확인 |
| 복구 콘솔 | COM4, 115200 baud, 8 data bits, parity None, 1 stop bit |
| 시험 포트 | 예: CH01. 실제 연결된 포트로 대체 |
| 상대 시리얼 장비 | 통신 조건과 송신 방법을 사전 확인 |
| 보조 시험 PC | 관리 PC와 다른 IP. 주소 필터 거부 확인용 |
| SNMP 도구 | Net-SNMP snmpget 또는 SNMP 조회 도구 |
| 기록 도구 | 화면 캡처, 다운로드한 로그, 결과 체크표 |
계정 비밀번호, Community, SMTP 비밀번호, 인증서 개인키는 발표 화면이나 저장소에 남기지 않습니다. 변경 전 포트 설정·알림 수신자·인증 방식·주소 필터·활성 인증서를 기록합니다. 로그 삭제는 복구할 수 있으리라 가정하지 말고, 필요한 범위를 먼저 내보냅니다. 설정 백업에는 로그 원문이 포함되지 않습니다.
## 2. 로그인과 준비 상태 (2분)
1. 장비 주소를 열고 준비 완료 표시를 기다립니다. 기존 화면이 남아 있으면 Ctrl+F5로 갱신합니다.
2. 관리자 계정과 CAPTCHA로 로그인합니다. 잘못된 CAPTCHA 1회는 로그인 거부를 확인하는 시험으로 사용할 수 있습니다.
3. 기타 설정의 날짜·시간을 확인하고, 틀리면 현재 PC 시간으로 동기화합니다.
4. 대시보드와 포트 상태 화면을 보여줍니다.
**기대 결과:** 준비 완료 후 로그인 가능. 날짜·시간과 실제 연결 포트 상태가 일치합니다.
발표 멘트: “장비 서비스가 준비된 뒤 관리 화면에 진입하며, 표시 시간은 이후 로그와 인증서 검증의 기준입니다.”
## 3. 포트 설정과 실제 송수신 (5분)
1. 포트 설정에서 시험 포트를 선택하고 현재 값을 기록합니다.
2. 상대 장비와 맞는 통신 조건을 적용합니다. 예: 9600 / 8 / None / 1 / 흐름 제어 None. 예시를 모든 장비에 강제하지 않습니다.
3. 별칭을 `DEMO_PORT`로 바꾸고 다른 화면에 갔다가 돌아와 유지되는지 확인합니다.
4. 관리자 포트 디버그에서 접속해 상대 장비가 지원하는 조회 명령을 전송합니다.
5. 실제 응답을 확인하고 연결을 해제한 뒤 재접속합니다.
**기대 결과:** 저장한 설정 유지, 실제 송수신 성공, 재접속 가능. 상태 확인용 신호나 CR 응답을 지원하지 않는 상대 장비는 상태 표시와 실제 송수신을 구분해 확인합니다.
## 4. 시리얼 키워드와 알림 (5분)
1. 포트 설정 → 고급 설정에서 시험 포트의 알림 키워드를 `DEMO_ALARM`으로 설정·적용합니다.
2. 기타 설정 → 알림 설정 → 시리얼 이벤트에서 동일한 대상 포트를 선택합니다.
3. 감지 키워드가 같은 값인지 확인하고 이 화면에서 `DEMO_READY`로 변경합니다.
4. 수신 키워드 감지를 켜고, 준비된 전달 방법(메일 / SNMP Trap / Syslog)을 선택한 뒤 적용합니다.
5. 다른 포트를 선택했다가 돌아와 값을 확인합니다. 포트 고급 설정에서도 `DEMO_READY`를 확인합니다.
6. 상대 장비에서 대상 포트로 `DEMO_READY`를 포함한 문자열을 송신합니다. 실제 RX 데이터로 시험합니다.
7. 포트 로그의 키워드 감지 결과와 선택한 수신처의 알림을 확인합니다.
8. 일치하지 않는 문자열로 새 키워드 알림이 발생하지 않는지도 확인합니다.
**기대 결과:** 두 화면이 같은 포트 키워드를 공유합니다. 키워드 감지를 켠 상태에서 빈 키워드로 적용하면 입력 오류가 나타납니다. 감지를 끄면 빈 값 저장이 가능합니다.
메일을 시연할 때는 SMTP 주소·포트·STARTTLS·인증·발신자·수신자를 실제 계정 조건에 맞춥니다. 테스트 발송 후 받은편지함과 스팸함에서 시각·내용을 확인합니다. 인증서 신뢰 오류가 발생하면 수신자를 바꾸는 대신 장비 시간과 CA 신뢰 설정을 점검합니다.
SNMP Trap은 아래 SNMP 조회 시험과 별개입니다. PC의 Trap 수신기, 수신 포트(통상 UDP 162), 장비의 Trap 대상 및 이벤트 전달 설정을 준비한 뒤 실제 이벤트로 확인합니다.
## 5. 사용자와 인증 서버 (4분)
1. 관리자 운영 → 사용자 계정에서 시연용 포트 운영자를 만들고 시험 포트만 허용합니다.
2. 별도 브라우저 세션으로 로그인합니다. 첫 로그인 암호 변경 요구가 있으면 먼저 완료합니다.
3. 허용한 포트 접근과 허용하지 않은 포트의 거부를 확인합니다.
4. 포트 운영자에게 관리자 메뉴와 로그 메뉴가 보이지 않는지 확인합니다. `/logs/ports` 직접 접속도 거부되어야 합니다.
5. 관리자 세션으로 돌아와 사용자 수정·비밀번호 재설정 버튼의 배치를 확인합니다.
외부 인증을 시연하는 경우 RADIUS 또는 TACACS+ 시험 서버를 준비합니다. 서버 주소·포트·공유 비밀·기본 역할을 맞추고 성공 로그인 및 오입력 1회 거부를 서버 로그와 함께 확인합니다. 외부 서버 중지 시험은 로컬 관리자 접속 경로를 확보한 상태에서 수행합니다. ‘장애 시 인증’ 고정 안내는 UI에서 제거되었으나, 그 UI 제거 자체가 인증 정책 변경을 뜻하지는 않습니다.
## 6. 주소 필터 — 차단 재현과 복구 (5분)
### 현재 사례
2026-09-10 조회 당시 차단 목록에 `192.168.0.0/24`, 전체 프로토콜 규칙이 켜져 있었습니다. 관리 PC `192.168.0.100`도 이 범위에 포함되어 `client address is denied by management address filter` 오류가 발생했습니다. 콘솔에서 설정을 백업하고 필터 사용만 꺼 접속을 복구했습니다. 이후 사용자가 변경했을 수 있으므로 시연 직전 상태를 다시 확인합니다.
### 안전하게 시험하기
1. 관리자 운영 → 주소 필터에서 필터 사용을 끈 상태로 기존 규칙을 검토합니다.
2. 광범위한 `192.168.0.0/24` 차단 규칙은 삭제하거나 비활성화합니다.
3. IPv4 탭에 **접속하는 관리 PC의 IP** `192.168.0.100/32`, 프로토콜 전체, 규칙 사용 켬을 추가합니다. 장비 IP를 입력하는 것이 아닙니다.
4. 기본 탭에서 허용 목록을 선택하고 필터를 켭니다.
5. 현재 PC에서 새 로그인 성공, 보조 PC에서 거부를 확인합니다.
6. 차단 목록 시험은 보조 PC의 실제 IP `/32`를 대상으로 합니다. 현재 관리 PC를 제외한 상태에서 적용합니다.
7. 완료 후 시연 전 정책으로 복원합니다.
| 표현 | 의미 |
| IPv4 고정 IP, DHCP, DNS, IPv6, 호스트 이름 | [1. 네트워크](01-network.md) |
| Single, Bonding, Bridge, OOB, DDNS | [1. 네트워크](01-network.md) |
| 시리얼 통신 조건, Reverse SSH/Telnet, 동작 설정 1·2 | [2. 포트](02-ports.md) |
| 포트 디버그, ASCII/HEX, 데이터 기록, 별칭, 포트 상태 | [2. 포트](02-ports.md) |
| 사용자 추가·권한·비밀번호, RADIUS, TACACS | [3. 사용자·보안](03-security.md) |
| 주소 필터 IPv4/MAC, 차단 시 복구, SNMP v2c/v3 | [3. 사용자·보안](03-security.md) |
| SSL 생성·활성화·HTTPS 확인·가져오기·CSR | [3. 사용자·보안](03-security.md) |
| 메일, SNMP Trap, 시리얼 키워드, DCD/DSR, 시스템 이벤트 | [4. 알림·로그](04-alerts-logs.md) |
| Syslog, 로그 저장 범위, 조회·다운로드·전체 삭제 | [4. 알림·로그](04-alerts-logs.md) |
| 백업·복원, 날짜·시간, 재시작, 펌웨어, 공장 초기화 | [5. 유지보수](05-maintenance.md) |
| 대시보드·로그인·언어·공통 조작 | 아래 준비 절차 |
## 0. 시험 환경을 먼저 정하기
아래 주소는 예시입니다. **현재 PC와 장비에서 확인한 값으로 바꿔 사용합니다.** 서버·계정 정보는 준비 담당자가 채워야 하며 임의로 추정하지 않습니다.
| 구분 | 이 문서의 예시 / 준비할 내용 |
|---|---|
| 192.168.0.100/32 | PC 한 대 |
| 192.168.0.0/24 | 192.168.0.x 대역 전체 |
| 허용 목록 | 일치하는 접속 허용, 나머지 거부 |
| 차단 목록 | 일치하는 접속 거부 |
MAC 규칙은 장비에서 해당 PC의 MAC을 확인할 수 있는 동일 LAN에서 별도로 시험합니다. 라우터를 경유한 원격 PC의 MAC이 그대로 전달된다고 가정하지 않습니다.
### 차단됐을 때
반복 로그인이나 공장 초기화 대신 COM4 콘솔 또는 허용된 다른 PC로 복구합니다. 콘솔 복구는 인증 설정 파일의 백업 → API 중지 → 주소 필터의 `enabled`만 false로 변경 → API 재시작 → 준비 상태와 로그인 확인 순서입니다. 현재 장비의 설정 경로는 `/var/lib/tera-api/auth.json`이었으며 다른 장비에서는 환경 설정으로 확인해야 합니다. 계정·암호 데이터 전체를 출력하거나 임의 문자열 치환으로 다른 `enabled` 필드를 바꾸지 않습니다.
## 7. SNMP 조회·거부 시험 (4분)
1. 관리자 운영 → SNMP에서 SNMP 사용 및 v2c를 켭니다.
2. Read Community를 시험용 값으로 정하고 장비 위치를 `TEST-RACK`, 관리자 연락처를 시연용 값으로 설정·적용합니다.
3. PC의 Net-SNMP 도구로 조회합니다. 아래 `TEST_COMMUNITY`는 실제 설정값으로 대체합니다.
```bash
# 장비 위치 sysLocation
snmpget -v2c -c TEST_COMMUNITY -t 2 -r 0 192.168.0.223 1.3.6.1.2.1.1.6.0
# 관리자 연락처 sysContact
snmpget -v2c -c TEST_COMMUNITY -t 2 -r 0 192.168.0.223 1.3.6.1.2.1.1.4.0
# 잘못된 Community 거부
snmpget -v2c -c WRONG_COMMUNITY -t 2 -r 0 192.168.0.223 1.3.6.1.2.1.1.6.0
```
**기대 결과:** 올바른 Community는 설정한 문자열 반환. 잘못된 값은 정상 데이터를 반환하지 않으며 통상 시간 초과가 발생합니다. 정상 값도 시간 초과라면 장비 IP, SNMP 사용 여부, UDP 161, PC 방화벽을 점검합니다. TCP 포트 검사만으로 UDP SNMP 정상 여부를 판정하지 않습니다.
v3를 추가 시연하려면 UI에서 v3와 사용자 사용을 켜고 사용자명·접근 권한·인증 방식·암호화 방식·각 키를 설정합니다. 조회 도구도 동일한 방식으로 맞춥니다. 예를 들어 UI를 SHA-1/AES로 정했다면:
```bash
snmpget -v3 -l authPriv -u TEST_USER -a SHA -A AUTH_PASSWORD -x AES -X PRIV_PASSWORD 192.168.0.223 1.3.6.1.2.1.1.6.0
```
위 명령은 SHA-1 설정의 예시입니다. UI가 SHA-256이면 도구가 지원하는 SHA-256 옵션을 사용해야 합니다. v3가 정상 동작한 뒤 시험에 사용하지 않는 v1/v2c는 원래 정책으로 복원합니다.
## 8. SSL 인증서 생성·활성화·검증 (5분)
사용자가 제공한 입력 화면:
![SSL 인증서 생성 입력 예시](assets/ssl-certificate-example.png)
| 필드 | 이번 입력값 |
|---|---|
| 인증서 ID | device-192-168-0-223 (자동 생성) |
| 공통 이름 CN | 192.168.0.223 |
| 국가 C | KR |
| 조직 O | TERA-TEST |
| 나머지 선택 항목 | 필요하지 않으면 빈 값 |
1. 장비 날짜·시간을 먼저 확인합니다.
2. 관리자 운영 → SSL 인증서 → 새로 만들기에서 위 값으로 생성합니다. 이미 같은 ID가 있으면 목록에서 확인하고 중복 생성하지 않습니다.
3. 인증서 목록에서 해당 인증서의 유효 기간과 개인키 보유 상태를 확인합니다.
4. 활성 인증서로 선택하고 적용합니다. **생성만으로 적용된다고 판단하지 않습니다.**
5. 새 브라우저 연결로 `https://192.168.0.223/`을 엽니다. HTTP 주소에서는 인증서 적용 여부를 확인할 수 없습니다.
6. 브라우저 인증서 정보에서 조직 `TERA-TEST`, SAN의 IP `192.168.0.223`, 유효 기간, 지문 또는 일련번호를 확인합니다.
7. HTTPS 로그인과 메뉴 이동을 확인합니다. 필요하면 기존 인증서로 다시 적용해 지문이 바뀌는 것도 확인합니다.
**자체 서명 인증서의 신뢰 경고와 적용 실패는 다릅니다.** 경고 없는 접속을 시연하려면 PC가 신뢰하는 CA에서 서명받고 접속 주소와 일치하는 SAN이 포함된 인증서가 필요합니다. 신뢰 경고를 무시한 접속은 신뢰 검증 성공으로 기록하지 않습니다.
추가 시험: PEM 인증서와 일치하는 개인키 가져오기 → 목록 확인 → 활성화. 개인키가 다른 파일은 오류로 거부되어야 합니다. CSR 다운로드는 CA에 제출할 요청을 만드는 절차로, 다운로드만으로 새 인증서가 발급되는 것은 아닙니다.
## 9. 로그 조회·내보내기·삭제 (5분)
먼저 포트 송수신, 로그인 시험, 키워드 이벤트로 기록을 생성합니다. 포트 상태 이벤트는 실제 연결 변화로 생성하되, 장비 관리에 사용하는 네트워크 케이블을 시험 중 분리하지 않습니다.
1. 시스템 로그에서 로그인·설정 변경 등의 발생 시각과 내용을 확인합니다.
2. 포트 로그에서 대상 포트, RX/TX, 키워드, 기간을 지정해 조회합니다.
3. 포트 상태 이벤트에서 UP/DOWN 변경을 확인합니다. 이력 삭제는 실제 연결 상태를 바꾸지 않습니다.
4. 필요한 로그를 CSV/지원 형식으로 내려받고 내용·시각·선택한 포트를 확인합니다. 내보내기 검색 조건과 최대 다운로드 건수를 확인합니다.
### 삭제 범위
| 화면 / 선택 | 삭제 대상 | 확인창 입력 | 유지되는 항목 |
|---|---|---|---|
| 포트 로그 / CH01 등 | 선택한 포트의 통신 로그 전체 | CH01 등 선택한 채널 | 다른 포트, 시스템·감사·상태 이벤트 |
| 포트 로그 / 전체 | CH01~CH48 통신 로그 전체 | ALL | 시스템·감사·상태 이벤트 |
| 시스템 로그 | 기존 시스템 이벤트 및 감사 기록 | SYSTEM | 포트 통신·상태 이벤트 |
| 포트 상태 이벤트 | 저장된 상태 이벤트 전체 | LINKS | 현재 연결 상태, 포트 통신·시스템·감사 로그 |
기간·검색어·표시 개수를 좁혀도 삭제 범위는 위 표와 같습니다. 관리자가 정확한 확인 문자열을 입력해야 실행됩니다. 취소하거나 틀리게 입력했을 때 삭제되지 않는 것도 먼저 확인합니다.
**시험 순서:** 시험 로그 생성 → 내보내기 → CH01만 삭제해 CH02 유지 확인 → 전체 선택 후 ALL 삭제 → 새 송수신 로그 재생성 확인 → 상태 이벤트 LINKS 삭제 → 현재 연결 상태 유지와 다음 상태 변경 기록 확인 → 시스템 로그 SYSTEM 삭제.
삭제 후 새 이벤트나 삭제 작업의 기록이 생길 수 있으므로, 화면이 영구적으로 0건인지를 기준으로 삼지 않습니다. 삭제 전에 있던 고유한 시험 메시지가 없어졌는지 확인합니다. 장비의 기존 로그를 실제로 지우는 시연은 필요한 자료를 확보한 뒤 수행합니다.
## 10. DDNS·백업·마무리 (3~5분)
DDNS는 IPv4 설정으로 시연합니다. 사용할 공급자·도메인·자격 증명이 있을 때 설정을 적용한 뒤 외부 DNS 조회로 주소를 확인합니다. 공급자 연결이나 DNS 전파 지연은 UI 저장 성공과 구분합니다. IPv6 항목은 제거되었습니다.
구성 백업은 암호를 정해 다운로드하고, 시험 포트 별칭 하나를 변경한 뒤 백업을 복원해 이전 값으로 돌아오는지 확인합니다. 복원은 여러 설정을 함께 바꾸므로 시험 장비에서 진행하고, 네트워크 포함 옵션과 변경 범위를 확인합니다. 펌웨어 업데이트·공장 초기화는 별도 시나리오입니다.
시연 후 계정·포트·알림·인증 방식·주소 필터·인증서·SNMP 설정을 원래 상태로 복원하고 시험용 계정을 정리합니다. 재시작은 저장 여부를 확인한 뒤 수행하며, 재로그인·포트 송수신·준비 상태를 다시 확인합니다.
| 장비 관리 주소 | `192.168.0.223`, HTTP 80 / HTTPS 443 |
| 계속 접속할 관리 PC A | 유선 IPv4 `192.168.0.100` |
| 차단 시험용 PC B | 같은 망의 별도 PC. `192.168.0.101`은 미사용 확인 후 할당한 경우에만 사용 |
| 보조 인터페이스 시험망 | 장비 `192.168.50.223/24`, 시험 PC `192.168.50.100/24`; 실제 구성 가능한 경우에만 사용 |
| 시리얼 시험 | CH01, 비교용 CH02, 통신 조건을 아는 상대 장비 또는 USB-RS232 어댑터와 적합한 케이블 |
| 외부 인증 | 서버 IP, RADIUS 인증 포트, TACACS 포트, 공유 Secret, 외부 전용 시험 사용자 |
| 알림 수신 | SMTP 서버·계정·수신자, Trap 수신기 UDP 162, Syslog 수신기 UDP 또는 TCP 514 |
| PC 도구 | 브라우저, PowerShell, 시리얼 터미널, SSH 클라이언트, 필요 시 Net-SNMP |
| 복구 연결 | 기존 환경은 COM4 / 115200 / 8N1. 현재 COM 번호와 콘솔 로그인을 미리 확인 |
1. PC에서 `ipconfig`를 실행해 **장비와 연결된 유선 어댑터**의 IPv4·마스크·게이트웨이를 기록합니다. Wi-Fi 주소를 주소 필터에 대신 입력하지 않습니다.
2. `http://192.168.0.223/`을 열어 준비 완료 표시를 기다리고 관리자 계정과 현재 CAPTCHA로 로그인합니다. OS 콘솔 계정과 웹 계정은 구분합니다.
3. **기타 설정 → 날짜와 시간**에서 장비 시간을 확인합니다. 모든 시험은 시작 시각을 기록합니다.
4. **관리자 운영 → 백업/복원**에서 변경 전 설정을 내려받습니다. [백업 방법](05-maintenance.md)을 먼저 수행합니다. 로그 원문은 별도 다운로드합니다.
5. 네트워크·주소 필터·인증 시험 전에 관리자 세션과 복구 콘솔을 준비합니다. 관리자 세션이 열려 있다고 앞으로의 요청까지 허용되는 것은 아닙니다.
6. 대상 포트·서버·수신 주소를 기록하고, 시험 문자열은 `DEMO_RX_01`, `DEMO_TX_01`, `DEMO_ALARM_01`처럼 구분합니다. 실제 암호·개인키는 캡처에서 가립니다.
## 공통 UI 동작 확인
| 시험 | 조작 | 성공 확인 |
|---|---|---|
| 로그인 | 정상 계정·현재 CAPTCHA로 로그인 | 대시보드 진입. 준비 중이면 준비 완료 후 재시도 |
| 로그인 거부 | 별도 창에서 CAPTCHA만 한 번 틀리게 입력 | 오류 안내 후 진입하지 못함. 새 CAPTCHA로 정상 로그인 가능 |
| 대시보드 | 장비 정보·포트 요약 확인 | 실제 장비 정보와 일치. 포트는 실제 통신 결과와 비교 |
| 언어 | 언어 선택 변경 후 같은 메뉴 다시 열기 | 메뉴·버튼 번역과 배치 확인. 시험 후 한국어로 복귀 |
| 설정 저장 | 변경 후 해당 화면의 적용 클릭, 다른 메뉴를 거쳐 돌아오기 | 성공 안내뿐 아니라 다시 읽은 값이 같음 |
| 재시작 후 유지 | 비파괴 시험 후 저장 후 재시작 | 재로그인 후 대표 값 유지 및 실제 송수신 재확인 |
## 결과 기록표
**판정 원칙:** 적용 성공 안내는 저장 요청의 결과입니다. 통신·인증·알림 성공 판정에는 상대 장비 출력, 서버 로그, 수신 메시지 등 실제 결과가 필요합니다. 준비물이 없으면 ‘미실시’로 기록합니다.
| 시험 | 기대 결과 | 실제 결과 / 캡처 / 시각 |
|---|---|---|
| 로그인·서비스 준비 | 준비 완료 및 관리자 로그인 | 미실시 / 기입 |
| 포트 설정·송수신 | 설정 유지 및 실제 응답 | 미실시 / 기입 |
| 키워드 양방향 설정 | 두 화면 일치 및 RX 감지 | 미실시 / 기입 |
| 메일 / Trap / Syslog | 선택한 수신처에서 확인 | 미실시 / 기입 |
| 사용자 권한 | 허용 포트만 접근, 운영자 로그 차단 | 미실시 / 기입 |
| 외부 인증 | 올바른 인증 성공, 오입력 거부 | 미실시 / 기입 |
| 주소 필터 | 관리 PC 허용, 보조 PC 거부 | 미실시 / 기입 |
| SNMP | 정상 값 조회, 오입력 거부 | 미실시 / 기입 |
| SSL | 생성·활성화 및 HTTPS 제공 인증서 일치 | 미실시 / 기입 |
| 단일 / 전체 포트 로그 삭제 | 선택 범위 삭제 및 새 로그 수집 | 미실시 / 기입 |
| 상태 이벤트 삭제 | 이력 삭제, 현재 상태 유지 | 미실시 / 기입 |
| 시스템 로그 삭제 | 기존 시스템·감사 기록 삭제 | 미실시 / 기입 |
| 백업·복원·재시작 | 설정 복원 및 정상 재접속 | 미실시 / 기입 |
## 진행 순서
## 발표 전 마지막 확인
1. 백업 → 시간 확인 → 대시보드.
2. 포트 송수신 → 포트 로그 → 시리얼 키워드 → 메일·Trap·Syslog 수신.
3. 사용자 권한 → 인증 서버 → SNMP → SSL.
4. 보조 인터페이스 네트워크 시험 → 주소 필터 허용·차단·원복.
5. 백업/복원 → 로그 다운로드 → 삭제 범위 확인 → 재시작 후 유지.
6. Bonding·Bridge·OOB는 배선 준비 후 별도로 수행합니다. 펌웨어·공장 초기화는 마지막에 별도 수행합니다.
- 실제 관리자 비밀번호·Community·인증서 개인키가 화면이나 캡처에 노출되지 않는가?
- 주소 필터를 켜기 전 현재 PC의 `/32` 규칙과 콘솔 복구 경로를 확인했는가?
- 인증서 “생성”, “활성화”, “브라우저 신뢰”를 각각 구분했는가?
- 로그 삭제 대상과 내보내기 범위를 확인했는가?
- 시험 성공을 실제 결과로 기록했으며 미실시 항목을 성공으로 표시하지 않았는가?
전체 기능 시험은 서버와 배선 준비를 포함하므로 35~45분 안에 모두 끝난다고 가정하지 않습니다. 발표 시간이 짧으면 포트·키워드 알림, 주소 필터, SNMP 조회, HTTPS 인증서, 백업 복원을 골라 시연하고 나머지는 기록표로 설명합니다.

Write Preview
Loading…
Cancel
Save