[Ribbon SBC] Core–Edge TLS/SRTP Hands on - 5 : SWe Edge ①, 인터페이스·인증서·상호 TLS·미디어 암호

1편 · 전체 SOP와 실습 첨부 | 이전 편

이번 편에서 할 일

4편에서 Core 쪽 준비를 마쳤습니다. 이번 편부터는 SWe Edge입니다. Edge는 두 편에 나눠 설명하겠습니다.

• 5편(이번 편): 호 경로에 쓰일 "부품"을 만듭니다. 논리 인터페이스, DNS, 신뢰할 CA, Edge 장비 인증서, 상호 인증 TLS Profile, SDES-SRTP Profile, Media List가 여기에 해당합니다.
• 6편: 그 부품을 Listen Port, SIP Server Table, Signaling Group, Call Routing Table로 연결합니다.

Edge는 어떻게 적용했나

솔직하게 먼저 말씀드리겠습니다. 이번 재구축에서 Edge 설정은 WebUI 화면에서 손으로 입력하지 않았습니다. Edge REST API와 WebUI 폼 제출을 스크립트로 자동화해서 넣었습니다. 같은 값을 여러 번 정확히 다시 넣기 위해서였습니다.

그래서 이 편의 스크린샷은 "입력하는 화면"이 아니라, 적용이 끝난 뒤 WebUI에서 찍은 실제 화면입니다. 캡처 시각은 Edge 화면 기준 2026-09-15 04:09입니다. 필드 표에는 두 가지 열을 나란히 두었습니다.

• REST 필드/값: 스크립트가 실제로 보낸 값
• 화면 필드명/화면에 보이는 값: WebUI에서 읽은 값

아래 표는 실제 적용한 REST 값과 화면에서 선택할 항목을 대응시켰습니다. WebUI에서 재현할 때는 각 메뉴의 추가(+) 버튼으로 객체를 만들고 표의 값을 입력한 뒤 Apply합니다.

스크린샷 상단의 로그인 정보 영역은 그대로 두었습니다.

시험 환경

항목	값	비고
장비	SBC SWe Edge, VM 메모리 2GB	13.1.0 build 43 / vCPU 2
Device Name	SWeEdge	화면 상단 표시
적용 방식	REST API + WebUI 폼 스크립트	화면은 적용 후 캡처
작업일	2026-09-15	—

이번 편의 구성도

Edge 부품도(설계) — 아직 부품끼리 호 경로로 연결되지 않은 상태입니다.

 Core 10.77.20.1 ──TLS──►  Ethernet 1 (ID 36) 10.77.20.2/24
                           Ethernet 2 (ID 37) 10.77.30.1/24  ──UDP──► SIPp server 10.77.30.10

 DNS:  Primary DNS 192.168.56.20 │ Hosts core.sbc.test=10.77.20.1 │ Split DNS sbc.test, 20.77.10.in-addr.arpa

 인증서:  Trusted CA (ID 2) "SBC Fresh Lab Root CA"
          Supplementary Certificate (ID 1002) "edge.sbc.test"
                    ▲
 TLS Profile 201 "FRESH Core mutual TLS" ─ Certificate 1002
 SDES-SRTP Profile 201 "FRESH SRTP Required" (AES_CM_128_HMAC_SHA1_80)
                    ▲
 Media List 201 "FRESH PCMU SRTP" ─ SDES-SRTP Profile 201

사전 조건

• [ ] 1편: Edge 부분 공장 초기화, 이전 인증서·Split DNS·인터페이스 주소 정리 완료
• [ ] 2편: DNS 서버(192.168.56.20)가 sbc.test 이름에 응답
• [ ] 3편: ca.pem, edge.p12, P12 암호 준비

1. 논리 인터페이스 두 개

어디서: Edge REST API — POST logicalinterface/36, POST logicalinterface/37

REST 필드	Ethernet 1 (ID 36)	Ethernet 2 (ID 37)	이유
ifName	Ethernet 1	Ethernet 2	1편 초기화 때 비활성화하고 주소를 지웠던 두 인터페이스
ifIPv4AddressPrimary	10.77.20.2	10.77.30.1	Core 쪽 / SIPp server 쪽 설계 주소
ifIPv4AddressPrimaryMask	255.255.255.0	255.255.255.0	/24
ifIPv4NextHop	10.77.20.1	10.77.30.10	각 구간의 상대 장비. 직결 구간이라 다른 라우터가 없음
ifIPv6AddressPrimary, ifIPv6NextHop	(빈 값)	(빈 값)	IPv6는 쓰지 않음
ifIPv4ConfigPrimaryEnabled	1	1	IPv4 주소 사용
ifIpAddrAssignMethod	0	0	고정 주소(DHCP 아님)
ConfigIEState	1	1	인터페이스 활성화
ifBridgeGroupId	1	1	적용한 구성 그대로
ifInterfaceIndex	3	4	적용한 구성 그대로

인터페이스 이름과 VirtualBox 어댑터의 대응은 2편과 같은 원칙으로 확인했습니다. 어댑터 번호만 보고 단정하지 말고 MAC 주소로 대조하세요.

• 즉시 확인: Settings > Networking Interfaces > Logical Interfaces 목록에서 두 인터페이스의 주소와 상태를 봅니다.
• 실패 시: 6편에서 Signaling Group이 Up이 되지 않으면 이 표의 주소와 넷마스크부터 확인하세요.

실제 관리·데이터 인터페이스 주소

2. DNS·Hosts·Split DNS

어디서: Edge REST API

REST 리소스	필드	값	이유
POST system	PrimaryDNSServer	192.168.56.20	2편 내부 DNS
—	useDynamicNetSettings	0	DHCP로 받은 DNS가 덮어쓰지 않게 고정
PUT hosts/1	HostName / IPAddress	core.sbc.test / 10.77.20.1	DNS 서버가 흔들려도 Core 이름은 Edge 안에서 풀리게
—	DynamicRefresh	0	고정 항목
PUT splitdnslist/1/splitdns/201	DomainName / DNSServerIP	sbc.test / 192.168.56.20	랩 도메인 조회를 내부 DNS로
PUT splitdnslist/1/splitdns/202	DomainName / DNSServerIP	20.77.10.in-addr.arpa / 192.168.56.20	10.77.20.x 역방향 조회를 내부 DNS로
POST splitdnslist/1	Sequence	201,202	두 항목의 적용 순서

Hosts와 역방향 영역을 함께 넣은 이유는 TLS Profile의 Validate Client FQDN 때문입니다. Core가 TLS client로 들어오면 Edge가 Core 쪽 이름을 검증합니다. 그때 쓸 이름 해석 경로를 미리 마련해 둔 것입니다. Edge가 검증할 때 이 중 어느 경로를 실제로 사용했는지는 이번에 따로 확인하지 않았습니다.

Core Hosts 항목

사설 영역 및 역방향 Split DNS

3. 신뢰할 CA 등록 (Trusted CA Certificate)

어디서: Edge WebUI — Settings 탭 > Security 아래 인증서 메뉴, 화면 제목 Trusted CA Certificate Table

3편의 ca.pem을 WebUI의 가져오기 폼으로 올렸습니다. 폼 제출은 스크립트로 했습니다. Settings > Security > SBC Certificates > Trusted CA Certificates에서 Import를 선택합니다. Mode를 Copy and Paste로 두고 Paste Base64 Certificate에 ca.pem의 BEGIN/END 줄을 포함한 전체 PEM을 넣습니다. 파일을 선택하는 방식은 File Upload입니다. 이번 적용은 Copy and Paste 방식이었습니다.

Edge WebUI Trusted CA Certificate Table에 SBC Fresh Lab Root CA 한 건이 ID 2로 등록된 화면

화면 열	화면에 보이는 값	기대값	판정
Common Name	SBC Fresh Lab Root C...	SBC Fresh Lab Root CA	일치(목록에서 잘려 표시)
Issuer	SBC Fresh Lab Root C...	자기 자신(자체 서명)	일치
Start Validity	Sep 13, 2026	2026-09-13	일치
Expiration	Sep 12, 2036	2036-09-12	일치
Key Length	3072	3072	일치
Primary Key	2	—	이 CA의 ID
전체 건수	Total 1 Certificate Row	1건(이전 CA 없음)	일치

전체 건수가 1건이라는 점이 중요합니다. 1편에서 이전 CA(ID 2·3)를 지웠기 때문에, 지금 Edge가 믿는 사설 CA는 이 새 CA 하나뿐입니다. 그래서 7편에서 TLS가 성립하면, 그것은 새 CA로 검증된 결과입니다.

• 실패 시: 목록에 이전 랩의 CA가 함께 보이면 1편 정리가 덜 된 것입니다. 이 경우 "새 CA로만 검증됐다"고 말할 수 없습니다.

4. Edge 장비 인증서 등록 (Supplementary Certificate)

어디서: Edge WebUI — Settings 탭 > Security 아래 인증서 메뉴, 화면 제목 SBC Supplementary Certificate Table (화면 상단에 Import | Export)

3편의 edge.p12를 P12 암호와 함께 가져왔습니다. 암호는 <EDGE_P12_PASSWORD>로만 표기하겠습니다. Settings > Security > SBC Certificates > SBC Supplementary Certificates에서 PKCS12 Import를 선택합니다. 대화상자 제목은 Import PKCS12 Server Certificate이며, Password에는 생성한 P12 암호, Select File에는 edge.p12를 넣습니다. 허용 확장자는 .pfx/.p12입니다. 성공 후 CN이 edge.sbc.test이고 issuer가 새 CA인지 확인합니다.

Edge WebUI SBC Supplementary Certificate Table에 edge.sbc.test 인증서가 ID 1002로 등록된 화면

화면 열	화면에 보이는 값	기대값(3편)	판정
Common Name	edge.sbc.test	edge.sbc.test	일치
Issuer	SBC Fresh Lab Root C...	SBC Fresh Lab Root CA	일치
Start Validity	Sep 13, 2026	2026-09-13	일치
Expiration	Sep 15, 2027	2027-09-15	일치
Key Length	2048	2048	일치
Primary Key	1002	—	TLS Profile에서 이 번호를 참조

여기서 한 가지 헷갈렸던 점이 있습니다. 목록 화면에서는 이 인증서가 첫 번째 줄에 보이지만, 설정에서 참조하는 ID는 1002입니다. REST로 TLS Profile을 만들 때 "1"이 아니라 "1002"를 넣어야 했습니다. 화면의 줄 순서와 ID를 혼동하지 마세요.

WebUI 접속용 기본 HTTPS 인증서는 1편에서 건드리지 않았습니다. 이 인증서는 시험 구간 TLS와 관계가 없습니다.

5. 상호 인증 TLS Profile

어디서: Edge WebUI — Settings > Security > TLS Profiles, REST PUT siptlsprofile/201

Edge WebUI TLS Profile 상세 화면. FRESH Core mutual TLS 프로파일의 Client·Server Cipher List가 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 하나로 설정되고 목록에 Default TLS Profile과 함께 ID 201로 표시됨

화면은 크게 Common Attributes, Client Attributes, Server Attribute 세 영역으로 나뉩니다.

영역	화면 필드	REST 필드 = 값	이유
—	Description	Description = FRESH Core mutual TLS	목록에서 알아보기 쉽게
Common Attributes	TLS Protocol	TLSVersion = 0	TLS 1.2 Only. 13.1 스키마에서도 TLSVersion=0은 TLS1.2로 정의
Common Attributes	Mutual Authentication	MutualAuth = 1 (사용)	Edge가 server일 때 Core에게도 인증서를 요구
Common Attributes	Handshake Inactivity Timeout	HandshakeTimeout = 15 (secs, 범위 1..30)	Core handshakeTimer 15와 맞춤
Common Attributes	Certificate	ClientCertificate = 1002, ServerCertificate = 1002	4절의 edge.sbc.test 인증서를 client·server 양쪽 역할에 사용
Common Attributes	OCSP Stapling	(기본값 유지)	사설 CA에 OCSP 응답기가 없음
Client Attributes	Client Cipher List	ClientCipherSequence = 9 → 화면 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256	Core cipherSuite1과 똑같이 한 개만
Client Attributes	Validate Server FQDN	ValidateServerFQDN = 1 (사용)	Edge가 client일 때 상대 서버 인증서 이름 검증
Server Attribute	Server Cipher List	ServerCipherSequence = 9 → 화면 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256	위와 같음
Server Attribute	Validate Client FQDN	ValidateClientFQDN = 1 (사용)	Edge가 server일 때(정방향 호) Core 인증서 이름 검증
(REST 적용값)	—	VerifyPeersCertificate = 1	상대 서버 인증서 검증 활성화. REST에서 1로 적용한 공통 검증 값
(REST 적용값)	—	FallbackCompatibleMode = 0	Disabled. 하위 SSL/TLS 호환 fallback 사용 안 함(13.1 스키마 정의)

그 밖의 필드는 프로파일 스키마의 기본값을 그대로 넣었습니다.

목록 영역에는 Total 2 TLS Profile Rows로 두 건이 보입니다. Default TLS Profile(1)과 FRESH Core mutual TLS(201)입니다. 기본 프로파일은 건드리지 않고 새 번호 201로 따로 만들었습니다. 기본 프로파일을 바꾸면 다른 용도에 영향을 줄 수 있기 때문입니다.

정방향 호에서 이 프로파일이 실제로 하는 일은 이렇습니다.

1. Core가 연결을 열면(ClientHello), Edge는 server로서 edge.sbc.test 인증서를 보냅니다.
2. Mutual Authentication이 켜져 있으므로 Core에게도 인증서를 요구합니다.
3. Core 인증서가 Trusted CA(ID 2)로 서명됐는지, 이름이 맞는지(Validate Client FQDN) 검사합니다.
4. 암호군은 양쪽 목록이 한 개로 같으므로 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xC02F)으로 정해집니다.

• 실패 시: 핸드셰이크가 인증서 단계에서 끊기면 Trusted CA 목록(3절)과 Certificate 번호(1002)를 먼저 보세요. 암호군 불일치라면 Core cipherSuite1과 이 목록을 비교하세요.

6. SDES-SRTP Profile

어디서: Edge WebUI — Settings 탭 > Media 아래, 화면 제목 SDES-SRTP Profiles, REST PUT mediacryptoprofile/201

Edge WebUI SDES-SRTP Profiles 목록. FRESH SRTP Required 한 건이 Crypto Suite AES_CM_128_HMAC_SHA1_80, ID 201로 표시됨

Edge WebUI SDES-SRTP Profile 상세 화면. SRTP Config 영역에 Operation Option, Crypto Suite AES_CM_128_HMAC_SHA1_80, Master Key 영역의 Key Identifier Length가 보임

화면 필드	REST 필드 = 값	화면에 보이는 값	이유
Description	Description = FRESH SRTP Required	FRESH SRTP Required	—
Operation Option	OperationOption = 1 (Required)	Required	SRTP 필수. 상대가 SRTP를 받지 않으면 평문으로 물러서지 않음. Core의 allowFallback disable과 같은 방향
Crypto Suite	CryptoSuite = 1	AES_CM_128_HMAC_SHA1_80	Core 쪽 SDP에서 협상될 suite와 같은 것
Master Key > Key Identifier Length	MasterKeyIdentifierLength = 0	스크린샷 참고	MKI를 쓰지 않음

목록은 Total 1 SDES-SRTP Profile Row입니다. SRTP 프로파일은 이 하나뿐입니다.

AES_CM_128_HMAC_SHA1_80이라는 이름은 두 부분으로 나눠 읽으면 됩니다.

• AESCM128: 음성 payload를 AES-128 카운터 모드로 암호화
• HMACSHA180: 패킷마다 HMAC-SHA1 인증 태그를 **80비트(10바이트)**로 잘라 붙임

이 10바이트가 7편에서 볼 172바이트 → 182바이트 차이와 연결됩니다.

TLS Profile의 AES_128_GCM과 헷갈리지 않도록 한 번 더 짚겠습니다. TLS의 암호군은 SIP 신호가 흐르는 TCP 연결을 보호합니다. SDES-SRTP의 Crypto Suite는 음성 RTP 패킷을 보호합니다. SRTP 키 자체는 SDP의 a=crypto 줄에 실려 SIP로 전달되는데, 그 SIP를 TLS가 감싸고 있습니다. 둘은 서로 다른 협상이고, 한쪽 결과로 다른 쪽을 판정할 수 없습니다.

7. Media List

어디서: Edge WebUI — Settings 탭 > Media 아래, 화면 제목 Media List View, REST PUT medialistprofile/201

Edge WebUI Media List 목록. Default Media List(1)와 FRESH PCMU SRTP(201) 두 건이 표시됨

Edge WebUI Media List 상세 화면. Media Profiles List에 Default G711A와 Default G711u가 있고, SDES-SRTP Profile 필드 아래에 Associated SIP SG Listen Ports should be TLS only 안내 문구가 보임

화면 필드	REST 필드 = 값	화면에 보이는 값	이유
Description	Description = FRESH PCMU SRTP	FRESH PCMU SRTP	—
Media Profiles List	VoiceFaxProfileID = 1,2	Default G711A, Default G711u	SIPp와 Core가 PCMU(G.711 μ-law)를 쓰므로 G.711 두 종류를 포함
SDES-SRTP Profile	CryptoProfileID = 201	스크린샷 참고	6절의 FRESH SRTP Required
나머지(Media DSCP, RTCP Mode, Dead Call Detection 등)	기본 Media List(ID 1)의 값을 복사	스크린샷 참고	SRTP 연결 외에는 기본 동작과 같게

상세 화면의 SDES-SRTP Profile 필드 아래에 안내 문구가 있습니다.

Associated SIP SG Listen Ports should be TLS only.

SRTP 키가 SDP에 실려 가니까, 이 Media List를 쓰는 Signaling Group은 TLS 포트로만 신호를 받으라는 뜻입니다. 그래서 6편에서 Core 쪽 Signaling Group의 Listen Port를 TLS-5061 하나만 걸었습니다.

이 Media List(201)는 Core 쪽 Signaling Group에만 씁니다. SIPp server 쪽 Signaling Group에는 SRTP가 없는 Default Media List(1)를 씁니다(6편).

Description은 "PCMU"지만 목록에는 G711A가 먼저 들어 있습니다. 이번 시험에서는 SIPp가 PCMU만 제안했고, 모든 구간 RTP에서 payload type 0(PCMU)이 관찰됐습니다(7편).

Core와 Edge 값 맞춰 보기

항목	Core (4편)	Edge (이번 편)	맞는가
신뢰할 CA	FRESH_CA = SBC Fresh Lab Root CA	Trusted CA ID 2 = SBC Fresh Lab Root CA	같음
자기 인증서	FRESH_CORE (core.sbc.test)	ID 1002 (edge.sbc.test)	각자 자기 것
상호 인증	authClient true, peerCertValidate true	Mutual Authentication 사용	같은 방향
이름 검증	peerNameVerify enabled, tlsPeerName edge.sbc.test	Validate Client FQDN / Server FQDN 사용	같은 방향
TLS 버전	1.2만	7편 실측 1.2	같음
암호군	tls_ecdhe_rsa_with_aes_128_gcm_sha256 한 개	TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 한 개	같음
핸드셰이크 타이머	15	15 secs	같음
SRTP 필수	enableSrtp enable, allowFallback disable	Operation Option = Required	같은 방향
SRTP suite	cryptoSuiteProfile DEFAULT → SDP에서 AESCM128HMACSHA1_80	AESCM128HMACSHA1_80	같음(7편 SDP 기준)
코덱	G711-DEFAULT	Default G711A, Default G711u	PCMU 공통

확인

확인 항목	기대값	실측값(2026-09-15 화면)	판정	증적
Trusted CA	SBC Fresh Lab Root CA 1건	1건, 3072, ~Sep 12, 2036	일치	12-edge-ca.png
Edge 인증서	edge.sbc.test, 발급자 새 CA	edge.sbc.test, SBC Fresh Lab Root C..., ID 1002	일치	13-edge-sip-certificate.png
TLS Profile 201 암호군	ECDHE-RSA-AES128-GCM-SHA256 한 개	Client·Server 모두 해당 값	일치	06-edge-tls-detail.png
SDES-SRTP Profile 201 suite	AESCM128HMACSHA1_80	AESCM128HMACSHA1_80	일치	07, 08
Media List 201	G.711 + SDES-SRTP 201	Default G711A/G711u, 201 연결	일치(연결 값은 스크린샷)	09, 10
인터페이스·DNS	위 표	REST 적용 완료	—

아직 Signaling Group이 없어서 Edge는 호를 받지 못합니다. 이 시점의 호 실패는 정상입니다.

정리

Edge에 두 인터페이스와 DNS 경로를 넣었습니다. 새 CA 하나만 신뢰하게 했고, edge.sbc.test 인증서를 ID 1002로 등록했습니다. TLS Profile 201에는 상호 인증과 양방향 FQDN 검증, 암호군 한 개를 걸었습니다. SDES-SRTP Profile 201은 AESCM128HMACSHA1_80 필수로 만들어 Media List 201에 연결했습니다.

다음 편에서는 이 부품들을 Listen Port, SIP Server Table, Signaling Group, Call Routing Table로 이어서 Core에서 온 2000번 호가 SIPp server로 나가게 하겠습니다.

1편 · 전체 SOP와 실습 첨부 | 이전 편