[Ribbon SBC] Core–Edge TLS/SRTP Hands on - 1 : 구성도와 목적, 라이선스를 지키면서 초기화하기

그림으로 보는 전체 흐름

SIPp에서 시작한 신호와 미디어가 Core와 Edge를 통과하는 전체 경로

전체 실습 목차 · 8편

1. [Ribbon SBC] Core–Edge TLS/SRTP Hands on - 1 : 구성도와 목적, 라이선스를 지키면서 초기화하기
2. [Ribbon SBC] Core–Edge TLS/SRTP Hands on - 2 : VirtualBox·Rocky·SIPp namespace·내부 DNS
3. [Ribbon SBC] Core–Edge TLS/SRTP Hands on - 3 : 공인 도메인 없이, 사설 CA와 SAN 인증서 만들기
4. [Ribbon SBC] Core–Edge TLS/SRTP Hands on - 4 : SWe Core, 7단계로 나눠 commit하는 전체 명령
5. [Ribbon SBC] Core–Edge TLS/SRTP Hands on - 5 : SWe Edge ①, 인터페이스·인증서·상호 TLS·미디어 암호
6. [Ribbon SBC] Core–Edge TLS/SRTP Hands on - 6 : SWe Edge ②, Signaling Group·SIP Server Table·Call Routing
7. [Ribbon SBC] Core–Edge TLS/SRTP Hands on - 7 : 5초 통화 시험과 TLS/SRTP 증적 판독
8. [Ribbon SBC] Core–Edge TLS/SRTP Hands on - 8 : 막혔을 때 좁혀 가는 순서, 최종 확인과 정리

이번 편에서 할 일

SBC 두 대를 이어 붙여서 "SIP 신호는 TLS로, 음성은 SRTP로" 보내는 랩을 처음부터 다시 만들어 보려고 합니다. 이번 연재는 Ribbon SBC SWe Core와 SBC SWe Edge 사이 구간을 암호화하고, 양 끝에는 SIPp를 붙여서 5초짜리 통화를 흘려 보는 과정입니다.

1편에서는 손을 대기 전에 세 가지를 먼저 고정하겠습니다.

1. 무엇을 증명하려는지(판정 기준)
2. 전체 구성도와 이름·번호·포트 계획
3. 이전 시험 구성을 지우되 라이선스는 그대로 두는 초기화 방법

이전에도 비슷한 랩을 돌려 본 적이 있습니다. 하지만 이번 연재에는 그때 결과를 한 줄도 쓰지 않습니다. 두 SBC에서 이전 시험 객체를 모두 걷어 내고 새로 구성한 뒤, 2026-09-15에 새로 측정한 값만 싣겠습니다.

시험 환경

항목	값	비고
하이퍼바이저	Oracle VirtualBox	7.2.16 r174877
SBC SWe Core	VM 메모리 16GB, CE 이름 vsbc1	12.01.08R004 / vCPU 4
SBC SWe Edge	VM 메모리 2GB, WebUI Device Name SWeEdge	13.1.0 build 43 / vCPU 2
시험 VM	Rocky Linux 9.8, VM 메모리 2GB, SIPp 3.7.7	OS와 SIPp 바이너리는 기존 설치본을 그대로 씀
재구축·시험일	2026-09-15	—

메모리 값은 이 랩에 제가 할당한 값입니다. 제품의 최소 사양이 아니니 참고만 해주세요.

이번 연재에서 검증하려는 것

한 문장으로 줄이면 이렇습니다.

SIPp client가 건 2000번 호가 Core와 Edge를 차례로 지나 SIPp server에 닿고, Core–Edge 구간에서는 SIP가 TLS 1.2 안에서, 음성은 SRTP로 5초 동안 오가는지 확인한다.

여기서 제가 가장 조심한 부분은 TLS와 SRTP를 따로 판정하는 것입니다. 둘은 보호하는 대상도, 협상하는 곳도 다릅니다.

구분	TLS	SRTP
보호 대상	TCP 위의 SIP 메시지(INVITE, 200 OK, SDP 포함)	UDP 위의 RTP 음성 패킷
이 랩에서 설정한 암호	TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (TLS 1.2)	AES_CM_128_HMAC_SHA1_80
협상하는 곳	TLS 핸드셰이크(ClientHello/ServerHello)	TLS로 보호된 SIP 안의 SDP a=crypto 줄
설정 위치	Core TLS 프로파일, Edge TLS Profile	Core packetServiceProfile, Edge SDES-SRTP Profile

이름에 똑같이 "AES"가 들어가지만 서로 다른 협상의 결과입니다. TLS 쪽 AES-GCM이 합의됐다고 해서 음성이 암호화됐다는 뜻은 아닙니다. 반대로 SRTP 키는 SDP에 실려 가기 때문에, TLS가 없으면 그 키가 평문으로 노출됩니다. 그래서 7편에서는 아래 네 가지 증적을 함께 놓고 판정하겠습니다.

1. 첫 호에서 잡힌 TLS 핸드셰이크(버전·암호군)
2. Core 로그에 남은 SDP(RTP/SAVP와 a=crypto, offer와 answer 양쪽)
3. Core–Edge 사이 전선(wire)에서 잡은 미디어 패킷 크기
4. 양 끝 SIPp가 오류 없이 끝났고 5초 동안 미디어가 오갔다는 end-to-end 결과

이 중 하나만으로는 결론을 내리지 않습니다. 예를 들어 패킷 크기 182바이트는 SRTP 인증 태그 80비트와 맞아떨어지지만, 크기만으로 암호화를 증명할 수는 없습니다. 이 부분은 7편에서 계산식과 함께 다시 설명하겠습니다.

전체 구성도

개념도 — 실제 신규 시험에 사용한 구성입니다.

 Rocky VM                                                                     Rocky VM
┌───────────────────┐        ┌────────────────────────┐        ┌────────────────────────┐        ┌───────────────────┐
│ ns: sipp-client   │        │ SBC SWe Core (vsbc1)   │        │ SBC SWe Edge (SWeEdge) │        │ ns: sipp-server   │
│ enp0s9            │  UDP   │ pkt0          pkt1     │  TLS   │ Ethernet 1  Ethernet 2 │  UDP   │ enp0s10           │
│ 10.77.10.10       ├───────►│ 10.77.10.1    10.77.20.1├───────►│ 10.77.20.2  10.77.30.1 ├───────►│ 10.77.30.10       │
│ SIP 5060 RTP 6000 │  RTP   │ SIP 5060               │  SRTP  │ TLS 5061    UDP 5060   │  RTP   │ SIP 5060 RTP 6002 │
└───────────────────┘        └────────────────────────┘        └────────────────────────┘        └───────────────────┘
                                                    ▲
                                                    │ 수신 전용(IP 없음, promiscuous) — Rocky enp0s16
                                                    │ VirtualBox 내부 네트워크 SBC-Lab-PKT1

구간	SIP 전송	미디어	주소·포트(설계)	보호
SIPp client ↔ Core	UDP	RTP (PCMU)	10.77.10.10:5060 ↔ 10.77.10.1:5060	평문
Core ↔ Edge	TLS over TCP	SRTP	10.77.20.1 ↔ 10.77.20.2:5061	TLS 1.2 + SRTP
Edge ↔ SIPp server	UDP	RTP (PCMU)	10.77.30.1 ↔ 10.77.30.10:5060	평문

보호 범위도(설계)

SIPp client ──[ 평문 SIP / 평문 RTP ]── Core ──[ TLS SIP / SRTP ]── Edge ──[ 평문 SIP / 평문 RTP ]── SIPp server

구성에서 신경 쓴 점이 두 가지 있습니다.

첫째, SIPp client와 server를 같은 Rocky VM 안의 서로 다른 network namespace로 나눴습니다. 두 namespace 사이에는 직접 가는 경로가 없어서, 패킷은 반드시 Core와 Edge를 거쳐야 합니다. 방법은 2편에서 다룹니다.

둘째, Core–Edge 사이 내부 네트워크 SBC-Lab-PKT1에 Rocky의 다섯 번째 NIC를 IP 없이 수신 전용으로 붙였습니다. SBC가 내부에서 보여 주는 캡처가 아니라, 실제로 선을 타고 흐르는 패킷을 제3자 위치에서 보려는 목적입니다. 이 차이가 왜 중요한지는 7편에서 보여 드리겠습니다.

이름·번호·포트 계획

항목	값	이유
Core FQDN	core.sbc.test	인증서 SAN과 Edge 이름 검증에 사용
Edge FQDN	edge.sbc.test	인증서 SAN과 Core의 tlsPeerName에 사용
사설 CA 이름	SBC Fresh Lab Root CA	이전 랩 CA와 헷갈리지 않도록 새 이름
시험 착신 번호	2000	Edge Transformation ^2000$로 정확히 이 번호만 통과
역방향 번호	1000	Edge에 구성은 넣었지만 시험하지 않음
Core 객체 이름 접두어	FRESH_	이전 랩의 LAB_ 객체와 섞이지 않게
Edge 객체 설명 접두어	FRESH	위와 같은 이유

도메인 sbc.test는 공인 도메인이 아닙니다. 그래서 공인 CA 대신 3편에서 사설 CA를 직접 만들고, 내부 DNS가 이 이름에 답하도록 하겠습니다.

이번 연재에서 새로 한 것과 그대로 둔 것

"처음부터 다시 했다"는 말이 어디까지인지 먼저 밝혀 두겠습니다.

영역	이번 재구축에서 한 일
Core 시험 구성	이전 객체 전부 삭제 → 새 FRESH_* 객체로 재구성
Edge 시험 구성	부분 공장 초기화 + 잔여물 정리 → 새로 구성
사설 CA·인증서	새 CA와 새 장비 인증서 발급
Rocky namespace	기존 두 namespace 삭제 후 다시 생성
통화 시험	새로 두 번 실행(각 5초)
Rocky OS 설치, SIPp 빌드·설치	다시 하지 않음. 기존 설치본(SIPp 3.7.7) 유지
SBC 라이선스·관리망 설정	유지. 초기화 대상에서 제외
번호 변환 규칙(DMPM), SIP 메시지 조작(SMM)	이전 것은 삭제했고, 새 구성에는 넣지 않음

2편에 SIPp 설치 스크립트를 싣기는 하지만, 이번에 다시 실행해서 검증한 절차는 아닙니다. 이 점은 해당 절에서도 한 번 더 말씀드리겠습니다.

왜 지우고 다시 하는가

이전 랩에는 번호 변환 규칙이나 SIP 메시지 조작 규칙 같은 객체가 남아 있었습니다. 이런 객체는 호가 성공하더라도 "내가 설정한 것 때문에 된 건지, 예전에 넣어 둔 규칙 덕분에 된 건지"를 헷갈리게 만듭니다. 그래서 이번에는 번호 변환이나 메시지 조작 없이도 호가 되는지까지 새로 확인하려고 모두 걷어 냈습니다.

반대로 라이선스는 다시 받기 번거롭고, 시험 내용과도 관계가 없습니다. 그래서 라이선스와 관리 접속 설정은 남기고, 시험용으로 만든 객체만 지우는 것을 원칙으로 잡았습니다.

지우기 전에 남겨 둔 것

어디서: 두 SBC 모두(관리 접속)

1. Edge 라이선스 파일 내려받기와 구성 백업
   • 초기화가 라이선스를 건드렸을 때 되돌릴 수 있도록 먼저 받아 두었습니다.
2. Core 대상 구성 백업
   • Core는 번호 계획 데이터 때문에 전체 설정 출력이 매우 큽니다. 그래서 전체 대신 이번에 지울 객체 계층만 골라서 백업했습니다.
3. 라이선스 현황 기록
   • 초기화 전후를 비교하려고 남겼습니다.

백업 파일과 라이선스 파일은 이 글에 싣지 않습니다. 라이선스 키와 시스템 ID가 들어 있기 때문입니다.

Core: 객체 단위로, 의존 관계의 역순으로 삭제

어디서: Core CLI(admin)

Core는 공장 초기화를 하지 않았습니다. 대신 시험용 객체를 하나씩 지우고, 지울 때마다 따로 commit했습니다. 한 번에 몰아서 commit하면 중간 객체 하나가 참조 오류로 거부될 때 전체가 적용되지 않습니다. 객체 단위로 commit하면 어디서 막혔는지 바로 보입니다.

순서는 "참조하는 쪽을 먼저, 참조당하는 쪽을 나중에"입니다. 예를 들어 라우트는 라우팅 레이블을 가리키고, 라우팅 레이블은 트렁크 그룹을 가리킵니다. 그래서 라우트부터 지웠습니다.

순서	지운 객체 종류	CLI 계층(4편 생성 명령과 같은 위치)	이 순서인 이유
1	라우트	global callRouting route	라우팅 레이블을 참조
2	라우팅 레이블	global callRouting routingLabel	트렁크 그룹과 IP 피어를 참조
3	SIP 트렁크 그룹	addressContext default zone <zone> sipTrunkGroup	프로파일·인터페이스 그룹을 참조
4	SIP 시그널링 포트	addressContext default zone <zone> sipSigPort	인터페이스 그룹·TLS 프로파일을 참조
5	IP 피어	addressContext default zone <zone> ipPeer	zone 안의 객체
6	zone	addressContext default zone	3~5를 담고 있던 상위 객체
7	IP 인터페이스	addressContext default ipInterfaceGroup <group> ipInterface	그룹 안의 객체
8	IP 인터페이스 그룹	addressContext default ipInterfaceGroup	7을 담고 있던 상위 객체
9	DNS local record의 data	addressContext default dnsGroup <group> localRecord <record> data	레코드 안의 값
10	DNS local record	addressContext default dnsGroup <group> localRecord	—
11	DNS 그룹	addressContext default dnsGroup	zone이 참조하던 객체라 zone 삭제 뒤에
12	SIP 메시지 조작(SMM) 프로파일	profiles signaling sipAdaptorProfile	비활성 상태로 남아 있던 것
13	IP 시그널링·미디어·TLS 프로파일	profiles signaling ipSignalingProfile, profiles media packetServiceProfile, profiles security tlsProfile	트렁크 그룹·포트가 모두 사라진 뒤라야 참조가 없음
14	번호 변환(DMPM) 규칙	profiles digitParameterHandling dmPmRule	—
15	DMPM criteria	profiles digitParameterHandling dmPmCriteria	규칙이 참조하던 조건
16	PKI 인증서 비활성화	system security pki certificate <name> state disabled	저는 삭제 전에 먼저 disabled로 바꿨습니다
17	PKI 인증서 삭제	system security pki certificate <name>	TLS 프로파일이 사라진 뒤

남겨 둔 것은 라이선스, 관리 인터페이스, OS와 기본 제공 설정, 장비 식별 정보입니다.

예를 들어 이전 시험의 라우트와 라우팅 레이블은 아래처럼 각각 커밋했습니다. 이름은 해당 랩의 이전 객체명입니다. 새 장비에 이 객체가 없으면 이 삭제 단계는 생략합니다.

configure private
delete global callRouting route trunkGroup LAB_TG_UAC VSBCSYSTEM standard Sonus_NULL 1 all all ALL none Sonus_NULL
commit check
commit
delete global callRouting routingLabel LAB_TO_UAS
commit check
commit
exit

활성 TG·포트·인터페이스는 먼저 비활성화한 뒤 참조하는 객체부터 제거했습니다. SMM과 PKI도 먼저 비활성화했습니다. 초기화 완료 후 show configuration addressContext | display set의 실제 결과에는 set addressContext default zone defaultSigZone id 1만 남았습니다. 라이선스 파일은 다시 설치하거나 변경하지 않았습니다.

실패 시: commit이 참조 오류로 거부되면, 방금 지우려던 객체를 아직 다른 객체가 가리키고 있다는 뜻입니다. 오류에 나온 객체부터 지우고 다시 시도하면 됩니다.

Edge: 부분 공장 초기화 후 잔여물 정리

어디서: Edge REST API와 Edge WebUI

Edge는 Core와 방법을 달리했습니다. REST API로 system 리소스에 action=factorydefaultpartial을 POST해서 부분 공장 초기화를 먼저 했습니다.

# 로그인 세션으로 인증한 뒤 Edge REST API에서 실행한 요청
POST https://192.168.56.102/rest/system?action=factorydefaultpartial
# 결과: http_code 200 (부분 초기화)

이 요청은 호 처리 설정을 초기화합니다. 현재 장비의 설정·라이선스를 먼저 내보내고, 라이선스와 관리 정보가 유지되는 부분 초기화인지 해당 버전 메뉴에서 확인합니다. 전체 공장 초기화와 혼동하지 않습니다.

부분 초기화 직후에 확인한 상태는 이렇습니다.

확인 항목	기대값	실측(2026-09-15)
라이선스 구성	초기화 전과 동일	동일
Signaling Group	0건	비어 있음
각종 테이블	기본 제공 항목만	기본 제공 항목만
관리 계정(admin), REST 계정	유지	유지

그런데 부분 초기화 뒤에도 이전 랩의 흔적이 몇 가지 남아 있었습니다. 그래서 아래 항목을 손으로 정리했습니다.

남아 있던 것	조치	이유
Supplementary Certificate(이전 장비 인증서, ID 1002)	삭제	새 CA로 발급한 인증서를 새로 넣기 위해
Trusted CA Certificate(이전 CA 2건, ID 2·3)	삭제	이전 CA를 계속 신뢰하면 "새 CA로만 검증됐다"고 말할 수 없음
Split DNS 항목(ID 201·202)	삭제	5편에서 새로 넣음
논리 인터페이스 36·37	비활성화, 주소 삭제	5편에서 새로 넣음
Primary DNS Server	값 삭제	5편에서 새로 넣음

WebUI 접속에 쓰는 기본 HTTPS 인증서(ID 1)는 건드리지 않았습니다. 이것까지 지우면 관리 접속이 흔들릴 수 있고, 시험 구간과도 관계가 없기 때문입니다. VM의 UUID와 MAC 주소도 바꾸지 않았습니다.

막혔던 지점

증상 Edge 초기화 과정의 재부팅 중에 VirtualBox의 Edge VM 프로세스(VBoxHeadless)가 access violation으로 비정상 종료됐습니다. 이어서 전원 끄기도 응답하지 않고 멈췄습니다.

원인 VirtualBox 프로세스 쪽 문제로 보이며, 정확한 원인은 확인하지 못했습니다.

조치 호스트에서 멈춘 Edge VM 프로세스 하나만 강제 종료했습니다. 다른 VM(Core, Rocky)은 건드리지 않았습니다. 그다음 Edge를 콜드 부팅했고, 정상으로 올라왔습니다.

조치 후 확인

• 라이선스가 초기화 전과 동일함
• admin·REST 계정 유지됨

이 경험 때문에 이후 작업에서는 VM이 켜진 상태에서 가상 NIC 설정을 바꾸는 일을 피했습니다. 2편의 캡처 전용 NIC도 Rocky를 끈 상태에서 추가했습니다.

초기화 후 확인

확인 항목	기대값	실측값	판정	증적
Core 이전 시험 객체(LAB_*)	0건	모두 삭제	일치	—
Core 기존 시험용 번호 변환·메시지 조작 규칙	0건	LAB 시험 객체 삭제	일치	—
Core 라이선스	삭제 전과 동일	초기화 후 SBC-RTU 20, SBC-SRTP 10, SBC-ENCRYPT 10 유지	—
Edge Signaling Group	0건	비어 있음	일치	—
Edge 라이선스 구성	초기화 전과 동일	동일(초기화 직후, 그리고 모든 시험을 마친 뒤 다시 확인)	일치	—

이번 연재가 다루지 않는 것

• HA(이중화) 구성
• 공인 CA 인증서, 운영 플랫폼 인증 요건
• 음질 점수(MOS), RTCP-XR, 패킷 손실 0 같은 품질 주장
• 번호 변환(DMPM)·SIP 메시지 조작(SMM)
• 역방향(1000번, Edge → Core) 호. 구성은 넣었지만 시험하지 않았습니다.
• 잘못된 CA, 이름 불일치 같은 부정 시험. 이번에 수행하지 않았습니다.

연재 순서

1. 구성도와 목적, 라이선스를 지키면서 초기화하기 (이번 편)
2. VirtualBox·Rocky·SIPp namespace·내부 DNS
3. 공인 도메인 없이: 사설 CA와 SAN 인증서 만들기
4. SWe Core: 7단계로 나눠 commit하는 전체 명령
5. SWe Edge ①: 인터페이스·인증서·상호 TLS·미디어 암호
6. SWe Edge ②: Signaling Group·SIP Server Table·Call Routing
7. 5초 통화 시험과 TLS/SRTP 증적 판독
8. 막혔을 때 좁혀 가는 순서, 최종 확인과 정리

정리

이번 편에서는 판정 기준과 구성도를 정했습니다. 그리고 두 SBC에서 이전 시험 구성을 걷어 냈습니다. Core는 객체 단위 역순 삭제로, Edge는 부분 공장 초기화와 잔여물 정리로 진행했습니다. Edge 라이선스는 초기화 전과 같다는 것을 확인했습니다.

아직 성공이나 실패를 말할 단계는 아닙니다. 다음 편에서는 SIPp가 반드시 두 SBC를 지나가도록 Rocky VM의 네트워크를 namespace로 나누고, 인증서 이름을 풀어 줄 내부 DNS를 준비하겠습니다.

전체 SOP 및 실습 파일 다운로드

Word/PDF 전체 SOP와 명령·음원·원본 PCAP이 포함된 실습 첨부입니다.

TLS-SRTP-attachments.zip

0.20MB

SBC_TLS_SRTP_신규구성_재현_SOP.docx

2.05MB

SBC_TLS_SRTP_신규구성_재현_SOP.pdf

2.84MB