Cloud Computing On Demand

HTTPS 통신을 위해서는 SSL/TLS 인증서가 필요합니다. 서버측에 Private Key 와 Public key 를 설치하고, 웹 브라우저로 대표되는 User-Agent 는 Public Key 를 전달받아 통신 구간의 암호화에 사용하게 됩니다. 이러한 인증서에는 여러가지 정보들이 담겨 있는데요 가장 대표적인 것으로 도메인 정보를 담고 있는 CN (Common Name) 입니다. 

 CN 이외에도 인증서에는 인증서와 관련한 여러가지 정보를 담기 위한 필드들이 존재합니다. 위의 네이버 인증서 정보에 나오는 주/도, 소재지, 조직 등의 모든 정보들이 인증서의 Public Key 에 포함되어 사용자에게 전달되는 값 들입니다. 네, 당연히 전송되는 용량에 포함되는 값들입니다. openssl 명령으로 이 인증서를 조금 더 자세히 살펴보면...

...인증서의 발급 체계에 따라 서버 인증서, 중간 인증서, 루트 인증서의 정보를 확인할 수 있습니다. 서버 인증서에 있는 C, ST, L, O 등의 값이 브라우저에 표시되었던 정보임을 알 수 있습니다. 가장 위에 있는 루트 인증서를 보면 OU Organization Unit 라는 값이 있는데요 여기에 www.digicert.com  이라는 인증서 발급사의 도메인 정보가 들어가 있는 것을 볼 수 있습니다.

OU 를 직역하면 조직 단위 내지는 부서명 정도가 될 것 같은데 좀 엉뚱한 정보가 들어가 있는 느낌이죠? 회사에서 사용하는 LDAP 정보를 살펴봐도 보통 OU 에는 부서 혹은 조직 단위에 따른 편제 정보가 들어가 있곤 합니다. SSL/TLS 인증서 세계(?)에서는 이 필드를 원래의 목적과 다르게 사용하는 경우가 많았고, 이로 인해 불필요한 바이트의 전송이 관례적으로 있어 왔다는 것을 짐작할 수 있겠습니다 (=우리의 소중한 데이터를 소모해 왔다는 것도...)

이 필드에 대한 논란이 있어온 이래 저렴한 인증서의 대명사였던 Sectigo (과거 COMODO 였죠) 는 진작에 필드를 제거했습니다. Sectigo 쪽에서는 SSL/TLS 인증서의 제품 정보를 표현하는 것과 같은 용도로 쓰이고 있었던 것 같습니다. 역시나 제정되었던 표준, 약속과는 다른 방향이었습니다.

Digicert 는 대한민국발 인증서 사태이후 시만텍의 인증서 사업을 인수해서 운영하고 있는 가장 큰 CA 중 하나입니다. 이제 Digicert 가 OU 필드를 인증서 발급에 사용하지 않고 인증서 정보에도 포함시키지 않을 것이라고 하니, OU 필드는 퇴출이 확정된 거라 봐도 무방할 것 같습니다. 아울러 사용자들은 자신의 인터넷 회선, 모바일 플랜에서 불필요한 전송 비용을 줄일 수 있게 된 것이기도 합니다. 

[ 참고 링크들 ]

https://knowledge.digicert.com/alerts/ou-removal.html

https://www.xolphin.com/news/Change_in_use_of_OU-fields_in_Sectigo_certificates

코딩이라는 용어는 더 이상 해당 분야 종사자만의 용어가 아닙니다. 아이들도 할 수 있고 비전공자도 할 수 있는 모두에게 열린 영역이 된지 오래인 것 같습니다. 비전공자 분들 중에서도 전공자나 업계 종사자보다 더 뛰어난 코딩 실력을 가진 분들도 종종 뵙게 되어, 늘 반성하는 삶을 살고 있습니다 ^^;;

학교 정규 교육 과정에서 블럭코딩은 이미 편제된지 오래입니다. 집에서 아이들이 엔트리나 스크래치로 만드는 블럭 코드의 양을 보면 실무에서 만드는 코드 이상으로 복잡하고 방대한 경우도 많습니다. 아이들이 논리적인 생각을 블럭으로 쉽게 표현할 수 있는 것이 쉬운 접근을 위한 좋은 방법이 되었다고 생각합니다.

그럼에도 막상 코딩의 세계에 뛰어들고 싶은데 어디서부터 시작하면 좋을지 모르겠다는 이야기도 많이 들립니다. 시중에 책도 너무 많고 어떤 것이 내 수준에 맞는지 찾는 것도 만만치 않죠. 책 가격도 저렴하지 않아 시행착오로 이것 저것 잔뜩 사서 보는 건 현실적으로 좀 어렵습니다. 그나마 부담을 덜어주던 도서관도 비대면 예약, 드라이빙 스루 책 수령이라 쉽지 않습니다.

코드잇 Code It (www.codeit.kr/) 은 바로 그런 고민에서 출발한 것 같은 코딩 강의 서비스입니다. 개인적으로 인프런 Inflearn 에서 여러 강의를 들어 보았고, 유데미 Udemy 같은 곳에서 유료 강의도 듣고 도움도 받고 있지만 개별 강의 단위의 결재 방식이라 <시작지점>을 찾기 어려운 분들에게 -물론 무료 강의도 있으나...- 난이도가 조금 있다는 느낌입니다.

반면 코드잇은 일단 -현재까지는!- 쉬운 시작지점을 제시하며 코스형으로 성장하는 모델을 제안하고 있습니다. 사실 조금 더 심화된 내용을 다루는 강의가 아직은 부족한 느낌입니다만, 처음 시작하는 사람들이 <방향을 설정>하고 강의를 듣기 시작하는데에는 적당합니다. 결정적으로 이를 뒷받침 해주기 위해 월/연간 단위의 무제한 구독권을 제공하고 있기 때문에 강의 선택 실패의 리스크를 줄일 수도 있습니다.

한달 무제한 구독권으로 나와 잘 맞는 강의 서비스인지 확인을 해보면서 다양한 영역의 강의를 들어보고, 잘 맞다는 판단이 든다면 연간 구독권으로 코딩 공부의 세계에 푹 빠져보는 것이 방법이겠죠? 파이썬 강의를 중심으로 프론트엔드와 웹 퍼블리싱, 알고리즘과 컴퓨터 공학 개론까지 입문자를 위한 여러가지 영역을 제안하고 있습니다. 

<코드잇 Codeit, 자세히 살펴보기 [바로가기]>

요즘 느끼는 것이지만 코딩은 결국 <매일매일 조금씩이라도 코드를 다루고 있는가?>가 핵심인 것 같습니다. 간헐적으로 필요할 때만 열심히 구글링해서 돌아가는 코드를 만드는 것도 의미 있지만 내 것으로 만들기는 어렵습니다. 부담 없는 무제한 구독권 방식의 코딩 강의 서비스 코드잇은 스스로 얼마나 듣느냐에 따라 구독권 비용 뽕을 뽑을 수 있으니 모티베이션으로도 넉넉하다는 느낌이네요!

다가오는 긴~~ 추석 연휴. 코로나 바이러스 때문에 놀러가기도 쉽지 않은 요즈음! 코딩 인강에 푹~ 빠져보시는 건 어떨까요? 추석 연휴동안 코딩 실력을 늘려봅시다. 저는 밀린 유데미 강의를 꼭 털어보도록 하겠습니다... 하아... 코세라는 또 어쩔... 

본 포스팅은 제휴마케팅을 통해 일정 수수료를 지급받을 수 있습니다

업무에 따라 다르겠지만 개인적으로는 DNS 에 대한 핸들링이 무척 많이 필요합니다. 커맨드라인에서 Shell 스크립트를 이용해서 여러가지를 만들어 사용하고 있긴 하지만, 가능하면 Python 이나 node.js 로 필요한 기능을 만들어 사용하는 것이 좋지 않을까 생각하고 있었습니다.

Python 쪽에서 사용할 수 있는 DNS 패키지가 어떤것이 있는지 살펴보다보니 `dnspython` 이라는 걸출한 물건이 있는 것을 발견했습니다. 패키지 공식 페이지에서 이야기 하는 것처럼 dnspython 은 DNS Toolkit 을 표방하고 있습니다. 정말 많은 기능들을 제공하고 있기 때문에 DNS 관련한 도구 개발에 무척 도움이 될 것 같습니다. 

간단하게는 Resolver 역할을 수행하는 것에서 시작할 수 있고, 좀 멀리 나가면 Zone 에 대한 핸들링도 수행할 수 있는 것 같습니다. 개인적으로 사용해 본 내용이 Resolver 중심이고 도메인 이름에 대한 핸들링 정도여서, 실제 필요한 과제에 맞도록 Research 는 조금 더 해봐야 할 것 같습니다. PyPi 에 패키지가 등록되어 있기 때문에 pip 로 패키지를 설치하면 편리하게 사용해 보실 수 있습니다. 

코로나 바이러스의 두번째 웨이브가 한창입니다. 다행히 오늘(9/3) 기준으로 확진자 수가 200명 밑으로 내려오긴 했지만, 긴장의 끈을 놓기에는 여전히 확진자 수가 많습니다. 많은 기업들이 원격 근무를 진행하고 있고 코로나 바이러스 초기에 각 VPN 회사들이 제공해 주었던 임시 라이센스 등을 잘 활용해 왔습니다. 

비용 지불 여력이 되면 유료 계약으로 라이센스를 추가하는 경우도 있겠지만, 소규모 사업장이나 여력이 되지 않는 곳에서는 다른 옵션을 찾아보는 것도 방법이 되겠습니다. 몇 개의 포스팅으로 나누어 소개할 OpenVPN 은 은근 손이 가긴 하지만 저렴하게 VPN 을 구축하는 방법이 될 수 있습니다.

AWS EC2 - OpenVPN 서버 구축 개요

본 포스팅은 OpenVPN 을 설치하여 사용하는 환경으로 IPv4 와 IPv6 를 모두 제공하는 것을 목표로 합니다. VPN 서버를 어디에 구축하느냐에 따라 달라지는 부분들이 있겠습니다만, 널리 사용되는 AWS 의 EC2 를 OpenVPN 서버로 활용하는 방법을 설명하도록 하겠습니다. 작업 순서는 아래와 같습니다.

1. AWS 환경 준비
   • IPv6 대역을 갖고 있는 신규 VPC 생성
   • VPC 내에 Public Subnet 생성
   • Gateway 구성 : Internet Gateway / Egress Only Gateway
   • Routing Table 조정
   • IPv6 주소를 갖는 EC2 배포
2. OpenVPN 설치 및 구성
3. VPN 접속 시험
4. 기타
   • 라우팅 조정

OpenVPN 을 IPv4 전용으로 사용하는 경우에는 절차가 조금 더 간단합니다. 하지만, 미래 지향적인 작업을 추구하는 동시에 AWS 환경에서 IPv6 를 어떻게 활성화 하는지 공부해 본다는 관점에서 단계를 따라해 주시면 좋겠습니다 ^^

1-1. IPv6 대역을 갖고 있는 신규 VPC 생성

AWS 콘솔에 접속후 VPC 를 먼저 생성하겠습니다. VPC 생성시 몇 가지 옵션 항목이 나오는데 <IPv6 CIDR Block> 의 두번째 옵션인 "Amazon provided IPv6 CIDR block" 을 선택합니다. 

IPv4 와 달리 IPv6 는 AWS 에서 자동으로 할당하는 대역을 이용하게 되며, 공인 IPv6 주소를 할당 받습니다. 이렇게 되는 이유는? 저도 조금 더 공부를 해보고 포스팅으로 정리해 보도록 하겠습니다. (요약 : 아직 잘 모르겠습니다) 

1-2. VPC 내에 Public Subnet 구성

VPC 가 생성되었으니 이번엔 Public Subnet 을 구성하도록 하겠습니다. 서비스에서 쓸 서버들이라면 역할에 맞게 Public, Private Subnet 을 구성해야하지만 OpenVPN 서버는 외부 접근이 필수인 서버이니 Public Subnet 만 구성하도록 하겠습니다.

Sunet 생성시 VPC 가 IPv6 를 활성화 해 둔 VPC 가 맞는지 확인하셔야 하구요, 가장 마지막에 있는 <IPv6 CIDR block> 을 "Custom IPv6" 로 선택하여 해당 Subnet 에 할당할 /64 블럭을 입력해 주어야 한다는 정도만 잘 챙기시면 됩니다. 제 경우에는 00 으로 지정을 했습니다.

Subnet 이 생성되었으면 Subnet 의 속성을 조정해 주어야 합니다. IPv6 를 지원해야 하기 때문에 Subnet 에 생성되는 자원에 IPv6 주소를 자동으로 할당하도록 해보겠습니다. 네, 유심히 보셨다면 아시겠지만 "Public" 이라는 단어가 나오지 않습니다. IPv6 주소 체계는 IPv4 와 묘하게 다른 점들이 있는데, 조금 더 공부하고 포스팅으로...

자동 할당 정책들 중 가장 마지막에 있는 <Auto-assign IPv6> 의 체크박스를 체크해 줍니다. 이후 해당 Subnet 에 자원이 생성되면 IPv6 주소를 자동으로 할당 받게 되고, Network ACL, Security Group 에 문제가 없다면 할당된 주소로 Public 에서 접근할 수 있게 됩니다. 

여기까지 문제 없으셨나요? 다음 포스팅에서는 인터넷 구간으로의 통신을 위해 필요한 두가지 Gateway 설정을 해보도록 하겠습니다. 하나는 쉘 접근을 위한 Internet Gateway 이고, 다른 하나는 IPv6 터널링시 외부로의 통신에 필요한 Egress Only Internet Gateway 입니다. 왜 두개를 따로 써야 하는지는 다음 포스팅! 에서 말씀 드리겠습니다.

2020.12.25 - 다음 포스팅이 올라왔습니다. 아래의 링크로 고고!

Stay tuned..!