[Ribbon SBC] Core–Edge TLS/SRTP Hands on - 8 : 막혔을 때 좁혀 가는 순서, 최종 확인과 정리

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

이번 편에서 할 일

7편에서 정방향 2000번 호가 TLS 1.2와 SRTP로 전달된 것을 판정했습니다. 마지막 편에서는 세 가지를 정리하겠습니다.

1. 이번 재구축에서 실제로 막혔던 지점과 풀어낸 방법
2. 호가 안 될 때 어느 단계에서 멈췄는지 좁혀 가는 순서
3. 시험이 끝난 뒤의 최종 확인과 정리(로그 수준 복원, 증적 보관, 종료)

한 가지 먼저 밝혀 두겠습니다. 이번 연재에서는 잘못된 CA, 이름 불일치, SRTP 불일치 같은 부정 시험을 하지 않았습니다. 그래서 아래 점검표에 "이 오류가 나면 이런 증상이 보인다"는 식의 증상을 지어내지 않았습니다. 대신 각 단계마다 이번 시험에서 확인한 정상 모습과 멈췄을 때 먼저 볼 설정 값만 적었습니다.

시험 환경

항목	값	비고
구성	1~7편 그대로	7.2.16 r174877
정리 작업일	2026-09-15	—

이번 재구축에서 실제로 막혔던 지점

1. Core: 설정을 한 번에 commit하면 거부됨

• 증상: 프로파일부터 라우트까지 한 파일로 모아 commit하자 백엔드 참조 오류로 거부됐습니다.
• 원인: 같은 commit 안에서 새로 만든 객체끼리 서로 참조하는 구조였습니다.
• 조치: 인증서 → 프로파일 → zone·인터페이스·DNS·피어 → 시그널링 포트 → 트렁크 그룹 → 라우팅 레이블 → 라우트, 이렇게 7단계로 나눠 단계마다 commit했습니다.
• 관련: 4편 <막혔던 지점>

2. Edge: 부분 공장 초기화 재부팅 중 VM 프로세스 비정상 종료

• 증상: 재부팅 도중 VirtualBox의 Edge VM 프로세스가 access violation으로 죽었고, 전원 끄기도 멈췄습니다.
• 원인: VirtualBox 프로세스 쪽 문제로 보이며, 정확한 원인은 확인하지 못했습니다.
• 조치: 멈춘 Edge VM 프로세스 하나만 강제 종료하고 콜드 부팅했습니다. 부팅 뒤 라이선스와 계정이 그대로임을 확인했습니다.
• 교훈: 이후에는 VM이 켜진 상태에서 가상 NIC 설정을 바꾸지 않았습니다.
• 관련: 1편 <막혔던 지점>

3. Edge: 부분 초기화 뒤 UDP 5060 Listen Port가 없음

• 증상: SIPp server 쪽 Signaling Group에 연결할 UDP 5060 Listen Port가 기본으로 없었습니다.
• 조치: Listen Port ID 1(UDP 5060)을 직접 만들었습니다.
• 관련: 6편 1절, 11-edge-listeners.png

4. Edge: 인증서 목록의 줄 순서와 ID가 다름

• 증상: Supplementary Certificate 목록에서는 edge.sbc.test가 첫 줄에 보이는데, 설정에서 참조하는 ID는 1002였습니다.
• 조치: TLS Profile의 Certificate에 1002를 넣었습니다.
• 관련: 5편 4절, 13-edge-sip-certificate.png

5. Edge 진단 캡처: 필터 조합이 거부됨

• 증상: Called 번호 칸을 비우고 Other를 1로 두자, 설정이 유효하지 않다는 오류(12204)로 거부됐습니다.
• 조치: Media 1, Other 0으로 두고 Called에 2000,+12000을 넣었습니다. 이 설정으로 1회차 캡처를 얻었습니다.
• 관련: 7편 캡처 지점 C

6. Edge 내부 캡처로는 전선 위 SRTP를 보여 줄 수 없음

• 증상: Edge 내부 캡처에서 Core–Edge 구간 미디어가 평문 RTP와 같은 172바이트로 보였습니다.
• 원인: 내부 캡처는 전선 위의 모습이 아닙니다. 캡처 지점이 SRTP 처리의 어느 쪽인지는 확인하지 않았습니다.
• 조치: Rocky를 끈 상태에서 SBC-Lab-PKT1에 수신 전용 NIC(모두 허용)를 추가했습니다. 콜드 부팅 뒤 두 번째 호를 걸어 전선에서 182바이트를 확인했습니다.
• 관련: 2편 <캡처 전용 NIC 추가>, 7편 <172바이트와 182바이트>

7. Edge WebUI: 스크립트로 폼을 제출하면 브라우저 로그인이 풀림

• 증상: 같은 관리 계정으로 스크립트가 WebUI 폼 제출(인증서 가져오기, Listen Port)을 하면, 브라우저에 열어 둔 WebUI 세션이 끊겼습니다.
• 조치: 스크립트 실행 뒤 브라우저에서 다시 로그인하고 스크린샷을 찍었습니다. 로그인 화면이 찍힌 캡처는 버리고 다시 찍었습니다.
• 참고: 별도 REST 계정으로 REST API를 호출할 때는 브라우저 세션이 끊기지 않았습니다.

8. 증적 파일이 섞일 뻔함

• 증상: Edge에서 캡처 파일을 내려받을 때 이번 호와 무관한 예전 캡처 파일이 함께 내려왔습니다.
• 조치: 파일명에 찍힌 시각과 호 발신 시각을 대조했습니다. 이번 호의 파일만 판독에 썼고, 나머지는 증적에서 뺐습니다.
• 교훈: "새로 측정한 값만 싣는다"는 원칙은 파일 단위에서도 지켜야 합니다.

멈춘 단계로 좁혀 가기

호가 안 될 때는 처음부터 순서대로, 정상 모습이 끝나는 지점을 찾으면 됩니다. 아래 순서도는 개념도이고, 표의 "정상 모습" 열은 이번 시험의 실측입니다.

점검 순서도(개념도)

[1] SIPp → Core 도달 ── 100 Trying 없음 ──► Core sipSigPort 20 / namespace 주소
     │ 정상
[2] Core 분류·라우팅 ── 180/200 없이 거절 ──► ingressIpPrefix / route / routingLabel
     │ 정상
[3] Edge 이름 해석 ───────────────────────► dnsGroup FRESH_TLS_DNS (EDGE 레코드)
     │ 정상
[4] TCP 연결 ─────────────────────────────► Edge Listen Port TLS 5061 / 피어 포트
     │ 정상
[5] TLS Hello ─── 암호군·버전 불일치 ────► cipherSuite1 ↔ Cipher List / v1_2
     │ 정상
[6] 인증서·이름 검증 ──────────────────────► CA 목록 / SAN / tlsPeerName / Validate FQDN
     │ 정상
[7] Edge SG 수용·라우팅 ───────────────────► Federated IP / Call Routing Table / ^2000$
     │ 정상
[8] Edge → SIPp server ────────────────────► SIP Server Table 202 / SG 2 / namespace
     │ 정상
[9] SDP crypto 합의 ──────────────────────► RTP/SAVP·a=crypto / fallback / suite
     │ 정상
[10] 미디어 흐름 ──────────────────────────► 구간별 패킷 수 / 전선 182B
     │ 정상
[11] BYE·종료 코드 0

단계	볼 곳	이번 시험의 정상 모습(실측)	멈췄을 때 먼저 볼 설정
1. SIPp → Core	캡처 A	INVITE 뒤 0.076초에 100 Trying(1회차)	Core sipSigPort 20 10.77.10.1:5060 sip-udp, client ns 주소 10.77.10.10
2. Core 분류·라우팅	캡처 A, Core 로그	Core가 Edge로 R-URI·To 2000 송신	FRESH_TG_UAC ingressIpPrefix 10.77.10.10/32, route → FRESH_TO_UAS
3. 이름 해석	Core 설정	Edge로 TLS 연결이 시작됨(ClientHello 발생)	dnsGroup FRESH_TLS_DNS EDGE = 10.77.20.2, zone FRESH_UAS에 연결
4. TCP 연결	캡처 C·D	TLS 레코드가 오감	Edge Listen Port TLS 5061, SG 1의 Listen Port, Core 피어 fqdnPort
5. TLS Hello	캡처 C	ClientHello(Core) → ServerHello(Edge) 0.053초, 0x0303, 0xC02F	Core cipherSuite1, v1_2 enabled ↔ Edge Client/Server Cipher List
6. 인증서·이름 검증	캡처 C, 장비 로그	핸드셰이크 뒤 SIP 진행(평문 SIP 0건, 호 성립)	Core FRESH_CA·FRESH_CORE·tlsPeerName edge.sbc.test ↔ Edge Trusted CA 1건·Certificate 1002·Validate Client FQDN·Hosts core.sbc.test
7. Edge SG 수용·라우팅	Edge 캡처, SG 상태	SG 1·2 Up, server로 INVITE 송신	SG 1 Federated 10.77.20.1/32, Call Routing Table 201, Transformation ^2000$ Mandatory
8. Edge → server	캡처 B	client INVITE 뒤 1.134초에 server INVITE 도착(1회차), 180/200 응답	SIP Server Table 202 10.77.30.10:5060 UDP, SG 2 Federated 10.77.30.10/32, server ns 주소
9. SDP crypto 합의	Core 로그	offer·answer 모두 RTP/SAVP, AES_CM_128_HMAC_SHA1_80	Core FRESH_SRTP enableSrtp enable·allowFallback disable, Edge Media List 201 → SDES-SRTP 201 Required
10. 미디어 흐름	캡처 A·B·D	모든 구간 방향별 248~250개, 전선 182B	Core·Edge 미디어 인터페이스, Edge SG 오디오 모드(DSP), SIPp -mi/-mp
11. 종료	SIPp 결과	BYE/200, 종료 코드 0/0	SIPp -timeout_error, 캡처 A의 BYE 응답

단계별로 조금 더

단계 1~2에서 멈출 때 캡처 A에 INVITE만 있고 응답이 없다면, Core까지 도달하지 못했거나 Core가 이 주소를 알아보지 못한 것입니다. namespace 주소가 Core ingressIpPrefix(10.77.10.10/32)와 다르면 트렁크 그룹이 호를 받지 못합니다. 2편 <분리 확인>의 명령으로 주소부터 보세요.

단계 3~6에서 멈출 때 Core–Edge 구간은 TLS라서, 캡처로는 SIP 내용을 볼 수 없습니다. 이럴 때는 전선 캡처(D)에서 어디까지 진행됐는지를 봅니다.

• TCP SYN에 응답이 없음 → 포트·주소 쪽을 먼저 의심(단계 4)
• ClientHello 뒤 ServerHello 없음 → 버전·암호군 합의 쪽을 먼저 의심(단계 5)
• ServerHello 뒤 인증서 교환 중에 연결이 끊김 → 인증서·이름 검증 쪽을 먼저 의심(단계 6)

이 구분은 TLS 진행 순서에서 나온 점검 방향입니다. 이번 랩에서 각 실패를 일부러 재현해 확인한 것은 아닙니다.

TLS 1.2에서는 인증서 메시지가 암호화되지 않으므로, 캡처에서 누가 어떤 인증서를 보냈는지도 볼 수 있습니다. 새 연결의 핸드셰이크를 보려면 첫 호 전에 캡처를 켜 두어야 합니다. 이미 연결이 맺어져 있으면 7편 2회차처럼 핸드셰이크가 다시 나오지 않습니다.

단계 9에서 멈출 때 SDP는 TLS 안에 있으므로 캡처가 아니라 Core 로그로 봅니다. offer에 a=crypto가 있는데 answer에 없다면, Edge가 SRTP를 받아들이지 않은 것입니다. 이 랩은 양쪽 모두 fallback을 막아 두었습니다. 그래서 이 단계에서 합의하지 못하면 평문으로 대신 연결되지 않도록 기대되는 구성입니다. 다만 이 동작은 부정 시험으로 확인하지 않았습니다.

단계 10을 판정할 때 Edge 내부 캡처의 크기를 보고 SRTP 여부를 판단하지 마세요. 이번에도 내부 캡처는 172바이트였습니다(막혔던 지점 6). 전선에서 잡은 크기, SDP 합의, end-to-end 결과를 함께 봐야 합니다.

최종 확인 체크리스트

#	항목	결과	어디서 확인
1	이전 시험 구성 제거(Core 객체 단위, Edge 부분 초기화 + 정리)	완료	1편
2	Edge 라이선스: 초기화 전 = 초기화 후 = 모든 시험 후	동일	1편, 아래 정리 절
3	Core 라이선스 보존	유지 확인
4	namespace 분리(client 10.77.10.10 / server 10.77.30.10)	재생성, 호 경로로 확인	2편, 7편
5	새 사설 CA와 SAN 인증서	발급, Edge 화면에서 값 일치	3편, 5편
6	Core 7단계 개별 commit	성공	4편
7	Edge 인증서·TLS·SRTP·Media List	구성, 화면 확인	5편
8	Edge SG 두 개 Up, 라우팅·Transformation	구성, 화면 확인	6편
9	5초 통화 2회, SIPp 종료 코드 0/0	성공	7편
10	TLS 1.2 / 0xC02F	확인(1회차)	7편
11	SDP RTP/SAVP + AES_CM_128_HMAC_SHA1_80 (offer·answer)	확인(1회차)	7편
12	전선 Core–Edge 미디어 182바이트, 방향별 250개	확인(2회차)	7편
13	상호 인증 메시지, TCP 목적지 포트	CertificateRequest·CertificateVerify, TCP 5061 확인	7편 원본 캡처
14	역방향 1000번	미시험	6편

시험 후 정리

시험 중에 올려 둔 것과 켜 둔 것을 되돌리는 절차입니다. 여러분 랩에서도 이 순서로 정리하시길 권합니다.

1. 캡처 중지

캡처	중지 방법	상태
client·server namespace tcpdump(A·B)	run-chain-call.sh의 trap cleanup EXIT가 스크립트 종료 때 자동으로 kill -INT	스크립트 종료와 함께 중지
Edge 진단 캡처(C)	캡처 파일을 내려받는 과정에서 중지	중지
Rocky enp0s16 전선 캡처(D)	tcpdump 종료	—

진단 캡처를 켜 둔 채 두면 장비 자원을 계속 씁니다. 그러니 시험이 끝나면 꼭 끄세요.

2. Core 로그 수준 복원

시험에서 INFO로 올렸던 로그를 아래 명령으로 major로 복원했고 Commit complete를 확인했습니다.

configure private
set oam eventLog typeAdmin debug filterLevel major
commit check
commit
exit

3. 실제 값과 원본 증적 첨부

공개 첨부에는 실습 IP·계정명·프로파일명을 그대로 사용했습니다. 두 신규 시험의 PCAP 6개도 원본으로 제공합니다. 파일 내용 검사에서 Authorization, password, 개인키 및 SDES inline 키 표식은 발견되지 않았습니다. TLS 안의 SDP는 복호화 전 패킷만으로 읽히지 않으므로 Core 로그 발췌를 함께 봅니다.

첨부	내용
core	실제 7단계 생성 명령 및 로그 수준 명령
sipp	실제 namespace·DNS·실행 파일, PCMU 5초 음원, UAC 시나리오
pki	인증서 생성 스크립트와 시험에 사용한 공개 인증서
evidence/fresh-20260915-130218	첫 호 client/Edge 내부/server 원본 캡처
evidence/fresh-20260915-131044	두 번째 호 client/server/wire 원본 캡처
evidence/*.json	호 판정, 상호 TLS 인증서 교환, 최종 VM 상태

개인키·P12·P12 비밀번호·라이선스 원본은 이 공개 패키지에 포함되어 있지 않습니다. 각자 PKI 생성 스크립트로 새 파일을 만들면 동일한 절차를 재현할 수 있습니다.

4. 라이선스 최종 확인

Edge는 초기화 전·직후·시험 후 라이선스 구성 필드를 비교했고 동일했습니다. Core는 라이선스 파일을 유지한 채 시험 객체만 제거했으며, 초기화 후 SBC-RTU 20, SBC-SRTP 10, SBC-ENCRYPT 10이 남아 있음을 확인했습니다. 라이선스를 새로 적용한 시험이 아닙니다.

5. 실제 VM 종료 결과

먼저 모든 시험과 캡처 수집을 끝내고 Core 로그를 major로 복원했습니다. Edge에 ACPI 종료를 요청했지만 VM이 계속 실행 중이었습니다. Core와 Rocky는 각각 OS 셸에서 아래 명령으로 정상 종료했습니다.

sudo shutdown -h now

SSH가 끊어지는 것만으로 종료를 판정하지 않고 VirtualBox VM 상태를 확인했습니다. Core와 Rocky는 poweroff였습니다. Edge는 ACPI 요청에 응답하지 않아 강제 전원 차단 대신 **상태 저장(savestate)**을 수행했습니다. 아래 명령의 진행률 100%를 확인했습니다.

& "C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" controlvm "SBC-SWe-Edge-13.1-Lab01" acpipowerbutton
# Edge가 계속 running인 것을 확인한 뒤 상태 보존
& "C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" controlvm "SBC-SWe-Edge-13.1-Lab01" savestate
& "C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" list runningvms

VM	실제 최종 상태	의미
SBC-SWe-12.01.08R004-Lab02	poweroff	게스트 OS 정상 종료
Rocky-SIPp-Lab01	poweroff	게스트 OS 정상 종료
SBC-SWe-Edge-13.1-Lab01	saved	RAM/장치 상태를 디스크에 저장, 게스트 OS 종료와는 다름

list runningvms 결과는 빈 목록이었고 VirtualBox 관리자 창도 닫았습니다. Windows의 사용 가능한 RAM은 약 21.4GB였습니다. 다음에 Edge를 시작하면 저장 시점부터 재개합니다. Rocky의 캡처용 NIC5는 다음 재현을 위해 유지했습니다.

이번 연재의 한계

항목	내용
재설치 범위	Rocky OS 설치와 SIPp 빌드는 다시 하지 않았습니다(SIPp 3.7.7 기존본). SBC 구성, CA, namespace, 통화 시험은 새로 했습니다.
시험 방향	정방향 2000번(SIPp client → Core → Edge → SIPp server)만 시험했습니다. 역방향 1000번은 Edge에 구성만 넣었습니다.
시험 횟수	한 호씩 2회차. 반복·부하·장시간 시험은 하지 않았습니다.
증적 분리	TLS 핸드셰이크·SDP는 1회차, 전선 SRTP 크기는 2회차에서 얻었습니다(TLS 연결 재사용).
미측정	음질(MOS), 손실률, 지터, RTCP·RTCP-XR, 수신 음원 일치, SBC 통계 화면의 SRTP 표시, 노드 간 시각 동기화
하지 않은 시험	잘못된 CA, 이름 불일치, SRTP suite 불일치, fallback 동작 등 부정 시험 / HA / DMPM·SMM
적용 방식	Core는 CLI만(EMA 화면 없음), Edge는 REST API·WebUI 폼 스크립트로 적용하고 화면은 적용 후 캡처
인증서	랩 전용 사설 CA와 호환성 위주의 P12 포장(PBES1/3DES/SHA-1). 운영 환경 기준이 아닙니다.
범위	이 랩의 구성·버전에 한한 결과입니다. 제품의 지원 사양이나 운영 플랫폼 인증과는 무관합니다.

연재를 마치며

8편에 걸쳐 두 SBC의 이전 구성을 걷어 내고, 라이선스는 지키면서 처음부터 다시 쌓았습니다.

• SIPp client와 server를 namespace로 갈라 호가 반드시 두 SBC를 지나게 했습니다.
• 사설 CA로 SAN 인증서를 만들었습니다.
• Core는 7번의 commit으로, Edge는 부품과 연결을 나눠 구성했습니다.
• 5초 통화 두 번으로 TLS 1.2 핸드셰이크, SDP의 SRTP 합의, 전선 위 182바이트 SRTP, end-to-end 성공을 각각 확인했고, 이 넷을 합쳐 판정했습니다.

여러분 랩에서 막히는 지점이 있다면, 위 점검표의 몇 번 단계에서 멈췄는지부터 찾아보세요. 그 단계의 "정상 모습"과 비교하면 어디를 고칠지 훨씬 빨리 보일 겁니다.

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