Cloud Computing On Demand

IPv4 의 주소 체계가 더이상 새로운 주소를 사용자들에게 주지 못할거라는 이야기가 나온지 참 오래된 것 같습니다. 마르지 않는 샘처럼 끊임없이 나오는 IPv4 주소 덕분에(?) 생명연장의 꿈을 꾸고 있습니다만 근래 애플(Apple)의 앱 검수 기준 변화는 IPv6 로의 트랜지션이 본격적으로 시작된 것이라는 느낌을 주기에 충분합니다.

IPv4 네트워크가 워낙에 광범위하게 사용되고 있기 때문에 어느날 갑자기 "오늘부터 IPv6 를 써야해!" 하기는 쉽지 않습니다. 때문에 많은 기술 표준과 이를 준수하는 어플라이언스를 통해 점진적인 트랜지션이 일어나고 있습니다. 개발을 하는 사람들은 사실 이걸 신경쓰지 않아도 됩니다만 이왕 세상이 변하고 있는것, 이해가 가는 부분까지 파보기로 했습니다.

NAT 라는 이야기는 많이 들어보셨을 겁니다. Network Address Translation 의 약자로 이 역할을 하는 장비들은 내부 주소(Private IP)를 외부 주소(Public IP)로 바꿔주는 역할을합니다. 당연한 이야기지만 내부 주소는 사적인 네트워크에서만 동작하기 때문입니다. 외부의 다른 인터넷 자원과의 통신을 위해서 주소 체계를 바꾸어 주는 것이지요. 이것을 IPv6 에 대응하여 IPv4 네트워크와 자연스러운 연결을 위해 만든 것이 바로 NAT64 입니다.

IPv6 체계가 퍼블릭 네트워크에 완전히 보급되는 것은 시간도 오래걸리고 어쩌면 불가능 할지도 모릅니다. 떄문에 IPv4, IPv6 는 한동안 혼용될 것입니다. 상대적으로 내부 네트워크는 IPv6 로의 전이가 쉬운 편이라 사내망에서는 이미 IPv6 를 쓰는 곳들이 꽤 많습니다. 내부에서 사용되는 IPv6 만 사용하는 기기들이 외부의 IPv4 로 구성된 기기에 접근하기 위해서 NAT64 를 활용한다고 보시면 되겠습니다. 시스코에서 게시해 둔 아래의 그림을 보면 이해가 빠를겁니다.

출처 : 시스코

IETF 에서는 NAT64 를 위해서 특정한 IPv6 주소를 활용할 수 있도록 규약을 정의해두었습니다. 이 주소를 활용하게 되면 패킷의 헤더 일부분에 실제 접근해야 하는 IPv4 주소를 포함시킬 수 있게 됩니다. NAT64 어플라이언스는 이 주소체계를 식별하여 IPv4 네트워크로 패킷을 전달할 때 목적지 주소로 활용할 수 있게 되는 것이죠. 실제 패킷의 응답을 다시 받아주기 위해서 NAT64 장비는 이 과정에 원본 주소로 활용할 IPv4 Pool 을 유지하면서 응답을 적절한 사용자에게로 리턴해 줄 수 있게 됩니다.

이러한 과정을 소화하기 위해서는 DNS 역시 AAAA 리소스 레코드로 IPv4 주소를 포함한 데이터를 가지고 있어야 하며 이는 다음글에서 DNS64 라는 주제로 살펴보도록 하겠습니다. NAT64 에 대해서 관심이 더 있으시다면 시스코의 아래 링크와 IETF 문서를 읽어보시면 ㄷ움이 되시겠습니다. 

대세는 https 입니다. 새로운 http 표준인 http/2 (aka h2) 는 Clear Text 에 관한 규약을 가지고 있긴 하지만 시장에 있는 대부분의 브라우저들은 TLS 기반의 통신을 http/2 를 이용하기 위한 기본 조건으로 내걸고 있습니다. 프로토콜의 변화 뿐만 아니라 렛츠인크립트(Let's Encrypt)와 같은 무료 인증서 배포가 대중화되기 시작하면서 스트리밍(Streaming)과 같이 레이턴시(Latency)에 민감한 부문을 제외하면 전반적인 https 로의 전이가 그리 오래 걸릴 것 같지는 않습니다.

그런데 https 규약 자체가 보안을 의미하지는 않습니다. https 는 공개키 기반의 인증 기술을 활용하여 브라우저(클라이언트)와 서버가 통신하는데 있어서 외부에서 침투할 수 없는 채널을 만들어주는 기술이지 사전에 악의적인 사용자가 서버측에 대한 탈취를 한 경우에는 큰 소용이 없습니다. 소위 맨 인더 미들 어택(MITM, Man In The Middle Attack)과 같은 것들이 그런 사고를 지칭합니다. 때문에 공개키 기반이라는 특성을 활용하여 SSL/TLS Handshake 를 하는 과정에 일종의 검증 절차를 넣어 그런 사고를 줄이고자 하는 것이 OCSP (Online Certificate Status Protocol) 입니다.

출처 : WWDC 2016 - 애플 시큐리티 세션

OCSP 는 기본적으로 클라이언트와 서버가 통신하는데 있어서 인증서를 발행한 사업자, 소위 CA (Certificate Authority) 라고 불리우는 회사의 서버를 통해 내가 접속하고자 하는 서버가 올바른 서버인지를 확인하는 절차입니다. 이 배경에는 각 CA 가 인증서를 발급하는 과정에 취하고 있는 다양한 확인 절차가 있습니다. 이 절차를 통해 발급된 인증서는 믿을 수 있다는 전제하에 클라이언트가 서버로 부터 전달받은 인증서를 발급자에게 "유효하고 정상적인 인증서인가?"를 질의하는 절차입니다.

문제는 안그래도 SSL/TLS Handshake 로 https 통신을 시작하기 위한 비용과 시간이 큰 편인데 CA 의 서버까지 컨택하고 와야 하니 딜레이가 더 커지면서 웹 사이트나 서비스 이용에 안좋은 영향을 끼치기 시작했다는 점입니다. 여기에 더하여 CA 의 서버가 과부하 등으로 제대로 응답하지 못하거나 이슈가 생긴 경우에는 OCSP 가 제대로 진행되지 못하는 상황이 발생할 수 있다는 것이 확인되었습니다. 그래서 이런 절차를 조금더 단순화하면서도 보안을 여전히 보장해보자 하는 관점에서 등장한 것이 OCSP Stapling 입니다.

출처 : WWDC 2016 - 애플 시큐리티 세션

OCSP Stapling 은 "스테이플링" 이라는 이름에서 보이는 것처럼 인증서가 유효하다는 정보를 클라이언트가 접속하고자 하는 서버가 CA 의 인증 서버를 통해 확인받고 이 정보를 사용자에게 인증서를 전달할때 같이 주는 방식입니다. 클라이언트가 글로벌에 분포된 불특정 다수의 사용자라고 하면 서버는 상대적으로 훨씬 적은 수라는 점에서 CA - 서버간의 통신이 이슈가 될 상황이 훨씬 적을거라는 추정이 가능합니다.

CentOS 환경에서 NPM (node package manager) 와 node.js 를 설치하는 방법을 정리해 봅니다. 환경 셋업을 자주 하지 않다보니 필요할때마다 겪는 시행착오를 줄이기 위해서 블로그에 적어둡니다 ^^;; 주기적으로 디지털 오션을 통해서 서비스 받고 있는 뉴욕 가상머신과 싱가폴 가상머신을 깨끗하게 정리하곤 합니다. 왠지 대청소를 하는 기분이라... 이렇게 해놓고 나면 바로 밀려오는 것이 패키지 설치에 대한 귀차니즘이죠.

간단한 테스트를 할일이 있어 DNS 셋업을 하고보니 가상머신에 아무런 패키지도 설치되지 않은 클린 설치라는 것을 발견했습니다. 이미지를 구워 놓아도 되련만, 그 이미지 조차도 왠지 찜찜해서 종종 하는 작업이 왠지 모르게 아깝게 느껴집니다. 오늘 정리하는 내용은 CentOS 에서 (버전은 6.7 입니다) yum repository 를 업데이트하고 nodejs, npm 을 설치하는 방법입니다.

yum 에 설정된 기본 repository 에는 nodejs 와 npm 이 존재하지 않습니다. 대신 epel repository 에 존재하는데요, epel repository 를 사용하기 위해서 위의 명령으로 epel 을 이용할 수 있도록 해봤습니다.

yum 명령으로 nodejs 와 npm 을 한번에 설치해 보겠습니다. 새롭게 준비한 epel repository 를 이용하기 위해서는 yum 옵션으로 --enablerepo=[repository이름] 을 지정해 주셔야 합니다. 위의 커맨드처럼 입력하시면 되겠죠? 약간의 시간이면 두 패키지와 종속된 패키지들이 모두 설치가 완료됩니다. 중간중간 인터렉티브하게 물어보는 질의에는 y 를 눌러주시면 됩니다. 

간편한 nodejs 버전 관리를 위해서는 n 을 설치해 주어야겠지요? 이제 npm 이 생겼으니 npm install -g n 명령으로 n 을 설치해 줍니다. 다른 지역의 가상머신과 node.js 버전을 맞춰주기 위해서 4.4.2 버전을 설치했습니다. 

간단한 테스트를 해보기 위해서는 node.js 의 핵심 패키지가 필요하겠죠. express 패키지가 그나마 익숙해서 요것까지 설치를 했습니다. 

- NoPD -

Node 의 새로운 버전이 릴리즈 되었습니다. Node 는 새로운 버전이 발표될 때마다 LTS (Long Term Support) 버전과 Stable 버전으로 나누어 공개하곤 합니다. 이번에 발표된 버전은 v4.4.2 (LTS) 버전과 v5.10.0 (Stable) 버전입니다. 아시는 분들은 아시겠습니다만 Stable 버전의 경우 이름의 뜻과는 달리 실험적인 기능들을 비롯한 덜 안정적인 기능들이 많이 들어간 버전이며 LTS 버전이 안정적인 버전이라고 생각하시면 되겠습니다.

Node 의 버전을 업데이트 하는 방법은 여러가지 있겠습니다만 개인적으로 추천드리는 방법은 n 을 이용하여 업데이트 하는 방법입니다. n 을 설치하고 사용하는 방법인 예전 포스팅에서 찾아보실 수 있습니다 (관련글 : http://ondemand.tistory.com/220) . n 은 여느 Node 패키지와 마찬가지로 NPM 을 이용하여 설치할 수 있습니다. 

간만에 또 한번 싱가폴에서 열심히 놀고 있는 서버에 접속을 했습니다. 업데이트를 하기 전 n 을 이용하여 현재 설치되어 있는 버전을 확인해 보았습니다. n 명령을 실행하면 현재 설치되어 있는 버전이 열거되며 활성화 되어 있는 버전은 특별히 밝은 색상과 o 표시가 되어 있어 식별이 쉽습니다. 

현재 설치되어 있는 버전이 두가지 이고 활성화된 버전은 4.2.4 로 확인됩니다. 새로 출시된 버전이 4.4.2 버전이니 n 명령을 이용해서 새로운 버전의 LTS 버전을 다운로드 받아 활성화 해보도록 하겠습니다. 명령은 무척 간단해서 n 뒤에 파라메터로 버전명을 기술해 주면 됩니다. 

약간의 시간동안 다운로드를 받고 설치하는 과정이 끝나면 준비 완료입니다. 다시 한번 n 명령을 이용해서 버전을 확인해보면 새로운 버전이 추가된 것을 확인할 수 있고 활성화까지 된것을 볼 수 있습니다. 느낌이 오셨겠지만 n 을 이용하면 현재 머신에서 어떤 버전을 활성화 해서 사용할 것인지도 쉽게 선택할 수 있습니다. 설치된 버전 목록에서 버전 넘버를 확인한 후, 다시 한번 n 명령 뒤에 해당 버전을 기술해 주면 됩니다. 저는 0.10.28 버전으로 다시한번 전환해 봤습니다.

네, 참 쉽습니다 ;-)