virbr0.net

RTP는 어떻게 NAT 환경에서 목적지 포트를 찾을까?

virbr0.net — Mon, 14 Apr 2025 23:55:26 +0900

SIP(Session Initiation Protocol)아래 Body 라고 불리는 SDP를 보신적 있으신가요?

일반적으로 SIP는 세션 제어(호개시, 호종료, 호제어 - 쉽게 말해 전화 걸고/끊고/통화중)를 하고,

바디에는 세션이 연결 되면 실제 주고 받을 내용을 적습니다.

표준에는 이미지도, 동영상도, 팩스도, 문서도 온같 잡 것 다 보낼 수 있지만, 실상 SDP(Session Description Protocol)는 거의 RTP를 주고받기 위한 용도로 많이 쓰입니다.

SDP 예제는 아래와 같습니다.

v=0
o=- 123456 654321 IN IP4 1.1.1.1
s=VoIP Call
c=IN IP4 1.1.1.1
t=0 0
m=audio 4000 RTP/AVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 opus/48000

주요 필드에 대한 설명은

o= (Origin): 세션 생성자 정보

c= (Connection): RTP를 받을 IP 주소

m= (Media): 미디어 타입, 포트 번호, 코덱 여기선 audio 4000이므로, RTP 수신 포트는 4000

a=rtpmap: 사용 가능한 오디오 코덱들

와 같습니다.

자 문제는여기서 시작 됩니다. 메세지에 IP와 포트정보가 기술되어 있으나,

현대의 대부분 인터넷은 NAT 환경입니다.

즉, 서버에서 보이는 단말의 IP와 포트가(공인IP, NAT 후) 단말이 알고 있는 IP와 포트(사설IP, NAT 전)와 다르다는 겁니다.

위 SDP 예제에서, 메세지만 보면, 서버 → 전화기의 RTP 흐름은

전화기는 "응, 나 포트 4000번에서 기다릴께"

서버는 "응, 나 1.1.1.1 IP에 포트 4000번으로 보낼께"

지만, 실제 전화기의 1.1.1.1 IP와 4000번 포트는 NAT 내부의 IP와 포트 정보입니다. 위와 같이 그냥 보내면

축하합니다. 원웨이 입니다.

이를 해결하기 위해,

1. STUN (Session Traversal Utilities for NAT)

2. TURN (Traversal Using Relays around NAT)

3. ICE (Interactive Connectivity Establishment)

등의 기술이 있지만, 자세한 건 검색이나 생성형 AI를 활용하고,

여기선 실제 통신사에서 쓰이는 SBC 동작을 알아보겠습니다.

단말기 IP	NAT라우터 IP	SBC IP
1.1.1.1	2.2.2.2	3.3.3.3

이라고 가정 하면, 전화기에서 아래와 같이 INVITE SDP 에 보냅니다.

c=IN IP4 1.1.1.1
m=audio 4000 RTP/AVP 0 8

그러나, SBC에서는 웬 메세지에는 없는 듣도보도 못한 IP인 2.2.2.2 에서 메세지를 받게 됩니다.

그리고 SBC는 아래와 같이 200OK SDP를 응답합니다.

c=IN IP4 3.3.3.3
m=audio 6000 RTP/AVP 0 8

일단, SBC 는 단말기가 NAT 내부에 있다는 걸, SDP와 메세지를 수신한 IP가 다르다는 사실로 알게 됩니다.

(사실 대부분의 SBC는 REGISTER 메세지의 Contact 헤더를 통해 등록 단계에서, 해당 전화기의 RTP NAT 처리 여부를 결정합니다.)

이제 SBC는 3.3.3.3:6000로 패킷이 들어오기를 기다립니다.

단말기는 SDP가 포함된 200OK 메세지를 받자마자, 1.1.1.1:4000 → 3.3.3.3:6000으로 보냅니다.

그러나, NAT 라우터가 포함 된 경로에서는 1.1.1.1:4000 → 2.2.2.2:5000 → 3.3.3.3:6000으로 보냅니다.

SBC는 3.3.3.3:6000 으로 실제로 들어오는 IP와 포트가 2.2.2.2:5000 라는 걸 확인하고,

3.3.3.3:6000 → 2.2.2.2:5000 → 1.1.1.1:4000 로 보내게 됩니다.

드디어 양방향 정상적으로 음성이 들리게 됩니다!!!

그런데 말입니다.

악의 적인 누군가(feat. 나쁜 놈)가 SBC가 대기 중인 3.3.3.3:6000 으로 RTP를 보내서, 어쩌다 보니, 단말이 보낸 것보다 먼저 도착하게 되면, 호가 나쁜 놈과 연결되는 문제점이 있습니다. (RTP Inject)

이를 방어하기 위해, 대부분의 NAT 라우터의 NAT Pool은 네트워크로 지정된다는 점을 활용합니다.

같은 NAT 라우터를 거치는 경우 SIP 메세지는 2.2.2.2 에서 받았는데 RTP는 4.4.4.4 에서 오는 경우는 거의 없다는 점을 활용해, 2.2.2.2 외의 IP(또는 네트워크)에서 오는 RTP는 무시합니다.

(물론, 2.2.2.2에서도 RTP Inject 공격하는 놈이 있을 수 있지만 그러면, 범인은 이안에 있다!!!)

그리고 요즘 SRTP를 지원하는 단말이 많아지고 저렴해지면서, SRTP를 단말과 SBC에서 적용해 SDP의 키값을 모르면 통화가 불가능하게 만들기도 합니다.

마지막으로 좋은 SBC는 자체의 보안기능도 훌륭합니다.

RTP 공격을 받은 포트는 오픈하지 않거나, 특정 IP에서 허용되지 않은 포트로 RTP를 전송하면 해당 IP를 차단하는 등의 기능도 가지고 있습니다.

SBC는 가성비 좋은 친구 입니다.

SIP 인증암호를 복잡하게 해야되는 이유

virbr0.net — Fri, 11 Apr 2025 01:53:35 +0900

※ 과거 제가 네이버 카페에 작성했던 글을 옮긴 포스트 입니다.

안녕하세요.

요즘 딱히 할 일 없어서, 이전에 SIP 인증암호는 '복잡하게', '자주 변경' 해야되는 이유에 대해 간단히 적어 봅니다.

암호를 복잡하고 주기적으로 변경하는게 좋은 것을 모르는 IT 쪽 사람은 아무도 없을 껍니다.

그러나...SIP가 다른 웹 사이트보다 더 복잡하게, 더 자주 변경해야 되는 이유는 아래와 같습니다.

1. TLS 미지원

- 모든건 여기서 시작 됩니다. TLS (SIPS) 지원하는 통신사 아직 못 봤습니다.

회사에서 고객 대상으로 TLS 올리려 시도 해보았으나 아래 같은 이유로 포기 했습니다.

우선 고객쪽에선 단말가격이 비싸집니다...

그리고 사업자 쪽에선, 대부분의 장비가 TLS를 지원하지만...완벽하지 않습니다.

어떤장비는 SIP URI Scheme 을 그냥 TLS로 암호화 해서 보내고 어떤 장비는 SIPS URI Scheme 으로 보내고 아주

환장 합니다.

무엇보다 중요한건...SIP 장비는 대부분 B2BUA 방식으로 동작(아랫단으로는 서버 역할, 윗단으로는 클라이언트 역할)

해서, 결국 SIP 관련 장비 (SBC, GW, PBX 등등) 지날때마다 복호화 하고 다시 보낼 때 암호화 하기 때문에,

암호화에서 가장 중요한 단대단 암호화 및 무결성 검증이 불가능 합니다.

결국 TLS 사용의 의미가 없죠. 그래서 대부분 TLS 적용 고객은 사내 전화망에만 사용 합니다.

그래서 평문 SIP에 SRTP만 쓰는 경우도 있는데, SRTP는 결국 코덱 네고 시 키 교환을 하기 떄문에 처음부터 끝까지

패킷을 도청 당한다면 의미없습니다...

2. 대부분 키 해시함수로 md5 알고리즘을 씁니다.

- 표준에 키 해시알고리즘으로 md5, sha-256, sha-512, token 까지 쓸 수 있다 했지만,

표준에도 sha-256을 추천하지만 md5 외에 다른 알고리즘을 쓰는 경우를 못 봤습니다.

웹 분야에서 보안 수검을 할 때, "md5 알고리즘으로 키가 암호화 되어 있습니다." 라고 하면

신명나게 까입니다...

여담으로 SIP 인증의 한 축인 Authorization 헤더가 어떻게 만들어지는지 보면...

1. 클라이언트에서 인증 없이 request 전송

2. 서버에서 401 Unauthorized 인증을 위안 nonce 및 알고리즘 응답

ex) WWW-Authenticate: DIGEST realm="BroadWorks",qop="auth",nonce="BroadWorksXl8cllu6vT2lz9coBW",algorithm=MD5

3. 인증값을 다시 추가하여 서버로 전송

ex) Authorization: Digest username="0709999999", realm="BroadWorks", nonce="BroadWorksXl8cllu6vT2lz9coBW", uri="sip:192.168.10.10", response="7d1dac0fb87740a72b7c753875b5f0c3", algorithm=MD5, cnonce="000027dc5d764a9ead0e6f3fb99e12d6", qop=auth, nc=00000001

인데, 여기서 응답 값인 response 는, 아래와 같이 만들어 집니다.

algorithm=MD5 해시함수는 md5 사용,

A1 = md5(username:realm:password)

A2 = md5(method:ur")

response = md5(A1:nonce:nc:cnonce:qop:A2)

로 만들어지는데, 여기서 모르는건 password 밖에 없으니, 숫자로 6~7 자리로 만들면 무작위 대입에 수십분 안에 찾을 수 있습니다.

관련 RFC 문서는 http의 인증 절차와 같은데,

sip 단독으로 나오는 RFC 문서는 https://datatracker.ietf.org/doc/html/draft-smith-sipping-auth-examples-01 입니다.

파이썬 코드로 짜면 기껏해야 몇 줄 안됩니다.

#!/usr/bin/env python

#Upgraded python 3.6
from hashlib import md5

# Authorization: Digest username="0709999999", realm="BroadWorks", nonce="BroadWorksXl8cllu6vT2lz9coBW", uri="sip:192.168.10.10", response="7d1dac0fb87740a72b7c753875b5f0c3", algorithm=MD5, cnonce="000027dc5d764a9ead0e6f3fb99e12d6", qop=auth, nc=00000001

login = str('0709999999')
uri = str('sip:192.168.10.10')
nonce = str('BroadWorksXl8cllu6vT2lz9coBW')
realm = str('BroadWorks')
password = str('1234')
nc = str('00000001')
cnonce = str('000027dc5d764a9ead0e6f3fb99e12d6')
qop = str('auth')


str1 = md5("{}:{}:{}".format(login,realm,password).encode('utf-8')).hexdigest()
str2 = md5("REGISTER:{}".format(uri).encode('utf-8')).hexdigest()
str3 = md5("{}:{}:{}:{}:{}:{}".format(str1,nonce,nc,cnonce,qop,str2).encode('utf-8')).hexdigest()
print(str3)

결론...암호는 복잡하게...IP허용 및 차단은 철저히...뭔가 이상하면 암호 변경...

이 답입니다.

해외발신 인터넷전화 발신자번호에 해외발신 표시하기 -시작 부터 구축 완료까지- 3부

virbr0.net — Fri, 11 Apr 2025 01:50:30 +0900

아무리 생각해도 해외IP 등록 모니터링 후 API 호출을 통한 발신번호 변경은 실시간으로 변경하기 어려워 국제전화 식별번호 표시를 100% 성공하기도 어렵거니와 1개 번호로 여러 단말을 사용하는 추가단말 서비스(Shared Call Appearance) 사용자 중에는 한국과 해외에 동시에 단말을 사용하는 사용자도 있을텐데 이런 경우는 어떻게 처리해야 할지 난감했습니다.

많은 해결방법을 고민을 하였지만 단순하게 생각했습니다.

국내-해외 구별은 어떻게 하는가?

- 단말기의 소스IP를 기반으로 구별 한다.

국제전화 식별번호 표시를 어떻게 할 것인가?

- 해외에서 들어온 발신호에 대해서만 조치를 취한다.

다음 각 구간 별로 확인 할 수 있는 정보(국내호? 해외호?)와 어디서 발신번호를 변경해야하는지 생각했습니다.

우선, 발신단말 → 교환기로 전달되는 INVITE에서 발신번호를 뜻하는 From 헤더를 변경한다면, SBC(session border controller)나 단말에서 없는 가입자로 판단, 403 Forbidden 을 응답하고 호는 실패 할 것 입니다.

그래서 발신단말 → 교환기 구간이 아닌, 교환기 → 착신단말 구간에서 변경을 해야합니다.

그러나, 발신단말의 IP는 발신단말 → 교환기에서만 확인 가능하니, 해당 구간에서 확인해야만 했습니다. 그래서 해당 구간의 장비에서 해외 발신 호 인지 아닌지 확인 후 착신 시까지 전달해야 했습니다.

다행히 B2BUA로 동작하는 브로드웍스 교환기에서 임의로 붙인 특정 헤더만 proxy기능으로 by-pass 하는 기능이 있었습니다. (만세~)

이제 이런 동작이 가능한 장비를 생각해 보니, 운영 중인 Radware Alteon ADC가 떠올랐습니다.

해당 장비는 소스IP기반의 라우팅 혹은 특정 동작이 가능한 PBR(Policy-based routing)이 가능하고, Appshape++ 라는 Tcl(Tool Command Language)기반의 스크립트를 통해 SIP 헤더의 변경이 가능한 장비 였습니다.

대략적인 구성은 아래와 같이 하였습니다.

1. 한국 IP 대역 확보

- 아래 KISA의 정보를 참고해서, 해당 대역이 아니면, 국제전화로 간주

https://한국인터넷정보센터.한국/jsp/statboard/IPAS/inter/sec/currentV4Addr.jsp

2. ADC에서 발신 단말 IP에 따라 해외IP일 경우 헤더 추가

- ADC에서 해외 IP일 경우 x-oversea-call: true 와 같은 헤더를 추가, Alteon ADC에서 Filter 기능 사용

3. 브로드웍스 SIP Server는 x-oversea-call 헤더 By-Pass

4. 착신 시 SBC에서 해당 헤더 값 유무에 따라 From 헤더와 Remote-Party-ID 변경

위 4단계만 두고 보면 어려울 것 없어보이지만, 하나하나의 컨피그를 생각하고 짜내는 과정이 쉽지 않았습니다.

특히 국내 IP 대역을 Filter로 만드니 대략 1,000줄 가량되어, ADC에 이를 밀어 넣는 것도 엄청 난 일이었습니다.

(터미널로 밀어 넣으니 끊기고 잘 안들어가 python ssh 구현체인 paramiko 를 활용해 넣었습니다.)

시간이 지난 지금 보니 별거 아니지만, 결론은

나 혼자 아키텍쳐 설계하고, 장비 주워다가 검증하고, 모르는거 ADC 벤더에 물어보면 SIP에서 appshape++쓰는거 처음 봅니다라고 하고, 어찌어찌 구현해서 상용망에 올리고

고정비 외 투자금 0원 (기존 장비 재활용), 해외발신의 경우 국제전화 발신번호 표시율 100%, 과기정통부에서 요청한 기간보다 더 빠르게 적용한 점

나를 많이 칭찬 합니다.

PS. 2025년 지금, 그때도 노후화 된 ADC는 지금 빼고 PBR을 다른 장비로 구현하였지만, 기본적인 구조는 아직도 큰 차이가 없습니다.

해외발신 인터넷전화 발신자번호에 해외발신 표시하기 -시작 부터 구축 완료까지- 2부

virbr0.net — Wed, 9 Apr 2025 10:01:23 +0900

※ 과거 제가 쓴 블로그 포스트를 옮긴 포스트 입니다.

해외발신 인터넷전화 발신자번호에 해외발신 표시하라는 업무를 담당 공무원에게 전달받고, 상사는 제일 먼저 교환기 운영자, 교환기 모니터링 시스템 담당자, 프로비저닝 담당자를 불러 해외IP에서 단말이 등록되면 교환기의 발신자 번호 앞에 해외발신 표시를 붙이도록 설정하라고 지시하였습니다.

매우 단순하고 쉬워보이는 지시였지만, 앞서 1부에서 말한 것과 같은 문제가 있었고, 상사들은 아래와 같은 해결책을 제시하였습니다.

1. 단말을 국내와 해외에서 동일하게 쓰는 경우 어떻게 할것인가?

- 해외에서 1개라도 등록된 단말은 모두 국제전화 식별 번호를 붙인다.

2. 프로비저닝 속도보다 호처리 속도가 빠를텐데 어떻게 할 것인가?

- 실시간이 아니라 특정 주기로 배치 돌려서 특정 시간 동안은 발신번호가 잘 못 표시될 수 있음을 고지하자

3. 단말의 모든 등록메세지(SIP REGISTER)를 어떻게 검사할 것인가?

- 모니터링 시스템을 증설하자

4. SIP-Connect 방식의 경우, 대표번호 1개만 등록을 하는데, 1개의 대표번호가 해외로 옮겼을 경우, 모든 종속번호의 발신번호를 변경 가능한가?

- SIP-Connect 방식은 기업이 사용하므로 해당 문제가 발생하지 않을 것이다.

물론 어찌어찌 구현은 되겠지만, 과학기술정보통신부의 보도자료까지 나갔던 사안인데, 저렇게 두루뭉술하게 넘어가도 되나 생각하였습니다.

또한 이어지는 고객 민원에 대한 대응은 상사와 모니터링시스템 담당자, 프로비저닝 담당자가 아닌 고객센터와 교환기 담당자인 저의 몫이 었습니다.

일하면서도, 밥 먹으면서도, 휴가 중에도 좋은 방법에 대한 고민을 하였고, 여러 방안 중 지금 상황에서 최적의 방안을 찾았습니다.

고민했던 여러 방안은 다음 장에서 소개하겠습니다.

해외발신 인터넷전화 발신자번호에 해외발신 표시하기 -시작 부터 구축 완료까지- 1부

virbr0.net — Wed, 9 Apr 2025 09:58:51 +0900

※ 과거 제가 쓴 블로그 포스트를 옮긴 포스트 입니다.

별 생각없이 출근한 날입니다.

갑자기 회의가 소집되어 들어갔는데, 6월까지 해외에서 발신되는 인터넷전화의 발신자번호에 국제전화식별번호 (001, 002, 00700 등)을 붙여야 한답니다.

아래 과학기술정보통신부의 보도자료 입니다.

과기정통부 보이스피싱 등 통신 부정사용 방지 보도자료 중

과학기술정보통신부 보도자료 전문

대통령 아래 국회의원 있고 그 아래 공무원 있고, 그 아래 민간기업 있고, 그 아래 우리 부장님 있고, 그 아래 제가 있으니, 저 위에서 타고 내려온 지시니 어떻게든 해야 됬습니다.

게다가 기간도 6월까지, 처음 전달받은게 보도자료가 나온 2월 초니 정말 정말 시간이 없었습니다.

그러던 중에 보도자료에도 나와 있는 것처럼 "3월 ~ 6월 순차 시행" 이라는 단어처럼 모 통신사는 4월 전 끝내라고 지시 받았다고...

그렇습니다.

일은 언제나 제일 나중에 하는 사람이 편합니다. 앞에서 다른 곳에서 한걸 보고 "따라"하면 쉽기 때문입니다.

앞 사람이 먼저 금액을 투자해서 했기때문에, 우리는 그걸 참고해서 예산을 산정하고 투자해 따라하기만 하면 되기 때문입니다.

제 나름의 인맥을 동원해 알아 봤지만, 다들 우왕좌왕 할 뿐 그렇다할 성과를 보인 통신사가 보이지 않았습니다.

확인 된 각 통신사들의 대략적으로 구현 방법은 아래와 같았습니다.

A통신사 : 모니터링 시스템을 활용, 단말이 해외에서 등록된 것이 확인 되면, 프로비저닝을 통해 고객의 발신번호를 변경
B통신사 : 단말이 켜지면 서버나 계정 정보를 보내주는 단말관리시스템에서 해외IP 에서 요청이 들어오면 프로비저닝을 통해 고객의 발신번호를 변경
C통신사 : 해외IP에서는 아예 전화가 되지 않도록 설정

뭐 하나 마음에 드는 방안이 없었습니다.

우선 1번은 전화번호 한개로 여러 단말을 쓸수 있는 부가서비스를 쓰는 고객이 한대는 국내에, 한대는 해외에 사용하면 주기적으로 해외발신번호 표시가 됬다 안됬다, 통제가 안됩니다. 또 해외에서 단말을 등록시키고 프로비저닝으로 발신번호를 변경하기 전에 발신하면, 일반적으로 프로비저닝 속도보다 전화 호처리 속도가 더 빠르기에, 해외발신번호 표시 설정이 되기전에 전화를 할 수도 있습니다.

2번은 우선 단말이 단말관리시스템을 통해 등록이 이루어져야 하는데, 기업전화는 SIP 트렁크로 연결되어 있어, 통신사는 트래픽만 받아 착발신만 해주고, 단말관리는 개별 기업에서 하는 경우도 많습니다.

3번은 생략하기로 하겠습니다.

또 한 1, 2번 공통으로, 해외에서 인터넷전화를 통해 해외로 걸때 교환기 상의 발신번호를 수정하면, 위의 보도자료의 예제대로 하면 001-070-111-1111로 설정될테고 해외 사업자에 발신하면 8201-070-111-1111 로 나가게 될테고,

(일반적으로, 해외 사업자로 발신시 제일 앞에 0 한자리를 떼고 한국 국가번호인 82를 붙입니다.)

이걸 해외 통신사가 받아서 착신 고객에게 보여주게 되면 +82-010-7011-1111 이라는 듣도보도 못한 번호가 상대방에 표시되게 됩니다.

이런 문제점이 있다는 것을 뻔히 알면서 우리도 따라가자고 차마 말할 수 없었습니다.

(물론 몇몇 부장님은 그냥 가자고 하셨지만, 나중에 담당자인 저에게 다른 소리 할 가능성이 99.9999% 이므로)

위 요구사항을 10년차 엔지니어의 이름을 걸고, 해결해보려고 합니다.

오라클 SBC(구 ACME SBC), 브로드웍스 SIP 교환기(이제는 시스코), 라드웨어 ADC(구 알테온 L4)...대부분의 통신사들이 활용하는 업계 순위권 업체의 장비를 활용해 정부가 요구한 사항을 구현하며, 어떻게 구현하는지 뒤에서 차차 설명하도록 하겠습니다.

VMWare 에서 다른 VLAN 간 라우팅 (부제 NSX 안 사주는데 어떻해)

virbr0.net — Wed, 9 Apr 2025 09:56:11 +0900

※ 과거 제가 쓴 블로그 포스트를 옮긴 포스트 입니다.

최근 회사에서 기존 물리 서버(Bare Metal Server)를 가상화 환경으로 전환하기로 하고, VMWare사의 가상화 플랫폼인 vSphere를 구매하였습니다. 각 서비스 간 네트워크가 다르니, 서비스 별로 VLAN을 만들어 네트워크를 분리하였습니다.

같은 네트워크의 VM 간 통신

먼저 같은 네트워크 간의 통신은 Host 내에서 처리되며 VM 외부로 트래픽이 나오지 않습니다. 그러나 다른 네트워크 간 통신을 하기 위해서는 라우터(Router) 역할을 하는 무엇인가가 필요합니다.

vSphere 상 의 서로다른 VLAN 간 통신을 위해서는 2가지 방법이 있습니다.

방법 1. 물리적인 라우터를 활용 - VM의 Gateway를 물리적인 라우터의 IP로 설정하여, 다른 네트워크와 통신을 위해 VM - 물리적인 라우터(Gateway) - VM 간 통신을 하게 설정

방법1. 물리적인 라우터를 활용

방법 2. VM Host 안에 라우터 역할을 하는 VM을 올려 처리 - DLR(Distributed Logical Router), DD-WRT, pfSense, Mikrotik RouterOS 등을 VM에 설치해 라우팅을 하거나, 라우터 용도로 리눅스 VM을 설치

방법2. VM 라우터를 활용

방법 1은 router-on-a-stick inter-VLAN routing 고전적인 방법으로 서로 다른 네트워크 간 통신하는 모든 트래픽 들이 Trunk 를 통해 VM 밖으로 나와, 처리 되므로, 비효율 적이며 보안에 상대적으로 취약합니다.

방법 2는 모든 트래픽이 VM 내에서 처리되므로, 메모리 속도로 처리되며 물리적 네트워크 장비를 거치지 않아 네트워크 오버헤드가 상대적으로 적습니다.

위 내용을 보면 누구나 방법 2가 가상화 환경에 더 적합한 방법이라는 사실을 알수 있습니다.

다시 회사 이야기로 돌아와, 저는 기존 물리 서버와 그에 연결 된 물리 L3 스위치를 담당하고 있습니다. 서버를 가상화 하면서 가상화 서버를 관리하는 담당자가 별도로 있고, 저는 단지 VM의 사용자가 되었습니다.

담당자에게 물었습니다.

우리 NSX 샀어요? 아니면 VM라우터 설치할껀 가요?

아니요. 돈이 없어서 NSX는 내년에 투자될지 안될지도 모르고 VM라우터는 뭐에요?

모르는 사람 데려다가 강의할수도 없고, 윗분들에게 East-West, South-North 부터 설명할 자신이 없었습니다.

네, 그렇습니다. 그냥, 방법 1로 진행하기로 했습니다.

그래서 아래 시스코 L3 스위치에서 설정 샘플을 작성합니다.

우선 vSwitch와 L3 스위치 간 dot1q 트렁크 설정을 합니다.

lacp 방식으로 이더채널설정을 해도 됩니다.

(config)# interface GigavitEthernet1/2

(config-if)# switchport (포트를 L2 스위치 용도로 사용)

(config-if)# switchport trunk encapsulation dot1q (ESXi/ESX 는 ISL이 아닌 dot1q 만 사용합니다. 최신 시스코 IOS에서도 dot1q 만 지원하여 해당 설정이 없을 수도 있습니다.)

(config-if)# switchport trunk allowed vlan 10-100 (ESXi/ESX에서 허용할 VLAN 추가합니다.)

(config-if)# switchport mode trunk (트렁크 모드로 변경합니다)

(config-if)# switchport nonegotiate (ESXi/ESX는 DTP를 미지원 합니다. 최신 시스코 IOS는 dot1q 만 지원하므로 해당 설정이 없을 수도 있습니다.)

(config-if)# no ipaddress

(config-if)# no cdp enable (ESXi/ESX 3.5 이상은 CDP 를 지원합니다)

(config-if)# spanning-tree portfast trunk (링크가 바로 up이 될수 있도록 portfast 설정을 합니다.)

이 후, VM에서 Default Gateway로 사용할 IP를 설정합니다.

(config)# interface Vlan200

(config-if)# ip address 10.10.100.1 255.255.255.0 (이 IP는 VLAN 200 Gateway 역할을 합니다.)

VLAN 마다 Gateway 로 사용할 IP를 설정 합니다.

이중화를 위해서 HSRP 등을 사용해도 됩니다.

자 이제 저는 다른 사람들을 설득/설명할 자신이 없으니 모릅니다.

그러나 궁금한 점이 있으면 언제든 댓글 달아주세요. 확인 후 답변 드리겠습니다.

BFS 알고리즘 (백준 2021번: 최소 환승 경로)

virbr0.net — Fri, 2 Aug 2024 22:22:15 +0900

https://www.acmicpc.net/problem/2021

파이썬으로 아래와 같이 구현하였다.

import sys
from collections import deque

input = sys.stdin.readline

n, l = map(int, input().split())
station_visited = [0] * (n + 1) # 각 역의 깊이 저장 (환승 횟수)
line_visited = [0] * (l + 1) # 해당 노선을 이용한 적 있나?
subway = [list(map(int, input().split())) for _ in range(l)]
graph = [[] for _ in range(n + 1)]

for i in range(l):
    for j in subway[i]:
        if j == -1:
            break
        graph[j].append(i)

start, end = map(int, input().split())

q = deque()

# 큐에 시작 역 추가 후 방문 처리
q.append(start)
station_visited[start] = 1
flag = 0
while q:
    cur = q.popleft()

    # 목적지 까지 도착했다면
    if cur == end:
        if start == end:
            # 시작과 끝이 같은 경우 환승 없음
            print(0)
        else:
            print(station_visited[cur] - 2)
        flag = 1
        break

    for i in graph[cur]:
        # 해당 역에 도착하는 노선들
        if line_visited[i]:
            # 노선 중 이미 방문한 노선이 있다면 패스
            continue

        # 노선을 방문 처리
        line_visited[i] = 1

        for j in subway[i]:
            # 해당 노선이 운행하는 역들 목록을 가져와
            if station_visited[j] or j == -1:
                # 이미 방문한 적이 있으면 패스
                continue

            # 역 방문한 적이 없다면 현재 방문한 라인 에서 1단계 깊은 곳이므로 추가
            # 단 시작점은 0 단계, 시작점과 같은 라인은 1단계...따라서 최종 결과에서 -2 함
            # 시작점이 환승 역인 경우, 이미 방문한 노선은 line_visited 에서 처리 되므로 중복 처리 안됨
            station_visited[j] = station_visited[cur] + 1
            q.append(j)

if not flag:
    # 목적지에 도달할 수 없다면 -1 출력
    print(-1)

원격 데스크탑(RDP, RDS) 인증서 구성

virbr0.net — Wed, 31 Jul 2024 23:39:27 +0900

윈도우 서버를 운영하다보면 대부분 서버에 원격 데스크탑 (Remote Desktop) 연결을 통해 접속 할 것입니다.

DNS에 해당 서버에 맞는 IP를 연결해도, 실제로 연결하려면 아래와 같은 경고창이 한번 뜰 것입니다.

RDP 접속 시 인증서 알람

해당 경고를 무시하고 접속해도 해당 연결은 암호화 된 통신을 하므로 무시해도 무방하나,

서버에 인증 된 기관에서 발급한 유효한 TLS 인증서가 있다면 해당 인증서를 연결함으로써 해당 경고가 안뜨도록 할 수 있습니다.

우선 사전 조건으로 컴퓨터에 사용하려는 개인용 인증키 설치가 필요합니다.

개인용 인증키 설치가 완료되었다면, 인증서 적용 방법은 2가지 방법이 있습니다.

방법 1: WMI(Windows Management Instrumentation) 스크립트 사용

1. 시작 > 실행 > certlm.msc 입력 후 실행 > Personal > Certificates 이동 후

적용하려는 인증서 더블 클릭 후 Details 탭으로 이동하여 Thumbprint 필드 까지 스크롤 후 값 확인 합니다.

인증서 지문 값 확인, 위 예에서는 "47faa7cb8702269c9dbb08aeccfe28f8aa0d4635"

2. 해당 문자열을 메모장과 같은 곳으로 복사합니다.

경우에 따라, 아래와 같이 공백이 있는 경우가 있는데, 해당 공백을 제거해 줍니다.

경우에 따라 정상적으로 제거되지 않을 수 있으니, 아래와 같이 명령 프롬프트에 복사하여, 유효성을 검사합니다.

3. 명령 프롬프트에서 다음 명령어를 입력합니다. SSLCertificateSHA1Hash= 이후의 문자열은 2번과정에서 유효성을 검증한 값을 붙여 넣습니다.

wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="THUMBPRINT"

아래는 위의 값을 복사해 실행 한 예제 입니다.

방법 2: 레지스트리 편집기 사용

1. 아래와 같이 레지스트리 값을 만듭니다.

레지스트리 경로:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
값 이름: SSLCertificateSHA1Hash
값 형식: REG_BINARY
값 데이터: 인증서 지문

reg 파일 등을 이용해 입력 할 경우, 아래와 같이 쉼표(,)로 구분해 작성해야 합니다.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp]
"SSLCertificateSHA1Hash"=hex:47,fa,a7,cb,87,02,26,9c,9d,bb,08,ae,cc,fe,28,f8,aa,0d,46,35

아래와 같이 설정 됩니다.

RDS는 NETWORK SERVICE 계정으로 실행됩니다. 따라서 NETWORK SERVICE 계정에 키 파일을 읽을 수 있는 권한을 추가해야 합니다.

2. 시작 > 실행 > certlm.msc 입력 후 실행 > Personal > Certificates 이동 후 적용하려는 인증서에서 우클릭 후 All Tasks > Manage Private Keys... 클릭

3. Add 클릭 후 NETWORK SERVICE 을 입력 후 확인하여 추가 후, 읽기 권한 허용 클릭 후 확인 버튼을 클립합니다.

이후 다시 접속 시 인증서 관련 알람이 뜨지 않습니다.

[참조]

원격 데스크톱 수신기 인증서 구성, https://learn.microsoft.com/en-us/troubleshoot/windows-server/remote/remote-desktop-listener-certificate-configurations

HTTP Chunking 과 테스트 클라이언트 구현

virbr0.net — Sat, 22 Jun 2024 01:24:40 +0900

HTTP 1.1은 HTTP 메세지를 나눠서 보낼 수 있는 청크 인코딩을 지원 합니다.

HTTP 1.1은 기본적으로 TCP 세션을 지속적으로 유지하며 (Persistent Connection = keep-alive = connection reuse), 이는 새로운 TCP 세션을 생성하기 위한 오버헤드를 제거해 네트워크 대기시간을 줄이는 방법 중 하나 입니다.

소켓 프로그래밍을 해본 사람을 알겠지만, 소켓을 재사용하기 위해서는 보내는 메세지의 정확히 길이를 알거나 종료 조건을 알아야 합니다. 따라서 사전에 HTTP 메세지의 본문(body)의 길이를 Content-Length 헤더를 통해 알려 주고, 수신 받는 쪽에서는 해당 바이트수(길이) 만큼 읽어 동일한 소켓을 종료하지 않고 연결을 유지하며 재사용 할 수 있습니다.

그러나, 매우 큰 데이터와 같이 사전에 전송할 본문의 길이를 알 수 없다면, 전통적인 HTTP 구현체에서 HTTP 1.0은 Content-Length 헤더를 생략하고 종료 조건인 EOF 표식 -1 이 나올 때까지 읽었습니다.

HTTP 1.1 에서는 이 문제를 해결하기 위해 Transfer-Encoding 이라는 헤더를 사용했습니다. Transfer-Encoding 헤더에 chunked 라는 값을 사용하면, Content-Length 헤더가 생략되며, 각 청크의 앞부분에 현재 청크의 길이가 16진수 형태로 오고 그 뒤 '\r\n'이 오고 그 다음에 청크 (분할 된 본문)이 오며, 길이가 0인 청크로 큰을 나타냅니다. 경우에 따라, 이후 연속된 엔티티 헤더 필드로 구성된 트레일러가 옵니다.

다음은 POST 요청을 chunking 해서 테스트한 HTTP 메세지 입니다.

POST /api/test HTTP/1.1
Host: localhost:8080
Accept-Encoding: identity
Transfer-Encoding: chunked
Content-Type: application/json

2c\r\n
{"Person":[{"id":1,"name":"Jaxon","age":35},
21\r\n
{"id":2,"name":"Jhon","age":40}]}
0\r\n
\r\n

본문 부분의 첫번째 청크인 {"Person":[{"id":1,"name":"Jaxon","age":35}, 길이는 총 44바이트로 이를 16진수로 표기하면 2c 가 됩니다. 이어 두번째 청크인 {"id":2,"name":"Jhon","age":40}]} 은 길이가 33바이트며, 이를 16진수로 표기하면 21이 됩니다. 마지막으로 길이를 0으로 표기함으로써 종료 청크를 나타냅니다.

HTTP Chunking 된 요청의 경우 테스트 시 많이 사용하는 curl 이나 httpie 로는 원하는 대로 본문을 나눠서 전송하는 테스트가 불가능합니다.

HTTP Chunking 된 메세지를 보낼수 있는 파이썬 클라이언트 코드는 아래와 같이 간단히 작성할 수 있습니다.

import http.client
import time

if __name__ == "__main__":
    conn = http.client.HTTPConnection('localhost', 8080)
    conn.connect()
    conn.putrequest('POST', '/api/test')
    conn.putheader('Transfer-Encoding', 'chunked')
    conn.putheader('Content-Type', 'application/json')    
    conn.endheaders(encode_chunked=True)
    
    chunk1 = '{"Person":[{"id":1,"name":"Jaxon","age":35},'
    chunk2 = '{"id":2,"name":"Jhon","age":40}]}'

    print(f'{hex(len(chunk1))[2:]}\r\n')
    conn.send(f'{hex(len(chunk1))[2:]}\r\n'.encode())
    print(f'{chunk1}\r\n')
    conn.send(f'{chunk1}\r\n'.encode())
    time.sleep(1)
    
    print(f'{hex(len(chunk2))[2:]}\r\n')
    conn.send(f'{hex(len(chunk2))[2:]}\r\n'.encode())
    print(f'{chunk2}\r\n')
    conn.send(f'{chunk2}\r\n'.encode())
    time.sleep(1)
    
    print("0\r\n\r\n")
    conn.send("0\r\n\r\n".encode())

    r = conn.getresponse()
    print(r.status, r.reason, r.read())

요청을 간단히 출력해 주는 서버를 파이썬 플라스크로 작성한 코드 입니다.

from pprint import pprint
from flask import Flask, request, jsonify


app = Flask(__name__)

@app.route('/api/test', methods=['POST'])
def post_body():
    header = dict(request.headers)
    data = request.get_json()
    pprint (header)
    pprint (data)
    res_body = data["Person"]
    return jsonify(res_body)

if __name__ == '__main__':
    app.run(debug=False, host='0.0.0.0', port=8080)

위를 실행하면,

Flask 구현체에서는 클라이언트에서 분할 전송한 바디를 하나의 json 으로 정확히 인식하는 것을 확인 할 수 있습니다.

[참조]

HTTP Chunking, Eric D. Larson, https://www.oracle.com/technical-resources/articles/javame/chunking.html
Transfer-Encoding, mdn web docs, https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Transfer-Encoding

유니온 파인드 알고리즘 (백준 1717: 집합의 표현)

virbr0.net — Sat, 3 Feb 2024 01:18:35 +0900

https://www.acmicpc.net/problem/1717

1717번: 집합의 표현

초기에 $n+1$개의 집합 $\{0\}, \{1\}, \{2\}, \dots , \{n\}$이 있다. 여기에 합집합 연산과, 두 원소가 같은 집합에 포함되어 있는지를 확인하는 연산을 수행하려고 한다. 집합을 표현하는 프로그램을 작

www.acmicpc.net

파이썬으로 아래와 같이 작성했다.

import sys
sys.setrecursionlimit(10**6)
input=sys.stdin.readline

n, m = map(int, input().split())

# 노드의 부모 노드를 저장하는 배열
# 최초 각 노드의 부모는 자기 자신
parent = [i for i in range(n+1)]

# 각 노드의 랭크를 저장하는 배열
rank = [0] * (n+1)

def find(x):
    # 경로 압축: 루트 노드를 찾을 때까지 부모 노드를 따라 이동하며 부모 노드를 업데이트
    if parent[x] != x:
        parent[x] = find(parent[x])
    return parent[x]

def union(x, y):
    # 루트 노드 찾기
    x_root = find(x)
    y_root = find(y)

    # 이미 같은 집합에 속한 경우
    if x_root == y_root:
        return

    # 랭크 기반 합집: 랭크가 낮은 노드의 루트 노드를 랭크가 높은 노드의 루트 노드의 자식으로 만듭니다.
    if rank[x_root] < rank[y_root]:
        parent[x_root] = y_root
    else:
        parent[y_root] = x_root
        # 랭크가 같으면 합쳐진 집합의 랭크를 1 증가
        if rank[x_root] == rank[y_root]:
            rank[x_root] += 1

for _ in range(m):
    o, a, b = map(int, input().split())
    if o == 0:
        union(a, b)
    elif o == 1:
        if find(a) == find(b):
            print("YES")
        else:
            print("NO")


'''
예제 입력
7 8
0 1 3
1 1 7
0 7 6
1 7 1
0 3 7
0 4 2
0 1 1
1 1 1

예제 출력
NO
NO
YES
'''