[Dev] 23.04.28. 탄력적 IP 설정 및 도메인 연결 (feat. 가비아)

프로젝트/Recipository

[Dev] 23.04.28. 탄력적 IP 설정 및 도메인 연결 (feat. 가비아)

규글 2023. 4. 28. 17:11

지인의 조언에 따르면, 단순하게 해봤다는 말과 함께 해당 작업 기록을 남기는 것보다 실제로 작업에 대한 오픈을 해놓는 것이 훨씬 좋다고 한다. 직접 눈으로 볼 수 있고, 작동을 볼 수 있도록 하는 것이 가장 좋다고 했다. 그래서 도메인을 연결하기로 했다.

탄력적 IP 설정

먼저 할 작업은 EC2 인스턴스에 탄력적 IP를 설정하는 것이다. 필자는 기존에는 과금 여부 때문에 따로 탄력적 IP를 설정하지 않았으나, 도메인과 연결하기 위해서는 고정된 IP를 가져야할 것 같아서 탄력적 IP를 설정하기로 했다. 과정은 다음과 같다.

AWS EC2 console에서 좌측 네트워크 및 보안 > 탄력적 IP 를 클릭하면 탄력적 IP 주소를 할당할 수 있게 된다.

위와 같은 설정들을 볼 수 있으나, 필자는 그대로 둔 채로 IP 주소를 할당했다.

생성된 탄력적 IP를 클릭하고 작업 > 탄력적 IP 주소 연결을 누른다.

인스턴스 항목에 만들어둔 인스턴스를 선택하여 연결하면 기존의 EC2에 방금 만든 탄력적 IP를 연결하게 되는 것이다.

도메인 생성

필자는 '가비아' 에서 도메인을 생성했다. 가장 저렴한 것은 500원으로 뒤에 store나 shop이 붙는데, 필자는 site가 붙는 것으로 1900원에 1년 기간동안의 도메인을 결제했다. 무료로 도메인을 생성해주는 곳도 있다고 하니, 원한다면 검색을 통해서 무료로 생성해보자.

가비아에서 생성한 필자의 경우, 결제 후 약 10분 내로 계정에서 도메인 정보를 확인할 수 있었다.

도메인 연결

가비아에서 생성한 도메인과 AWS EC2 인스턴스의 탄력적 IP를 연결하는 방식을 검색해보면, 대부분의 블로그에서 AWS의 Route 53 서비스를 활용하는 방식이 정리되어 있는 것을 볼 수 있다.^[각주:1] ^[각주:2] 필자는 도메인을 연결하는 방식을 전혀 모르는 상태였으므로 검색을 통해 몇 가지 블로그에 작성된 내용을 따라가다가 의문에 봉착했다. 왜 Route 53을 써야하지?

사용에 대한 의문을 가지게 된 이유는 '네임 서버 (Name Server)'라는 용어 때문이다. 처음 해당 용어를 접한 것은 도메인을 생성할 때다. 가비아의 네임 서버를 이용할 것인지 타사의 네임 서버를 이용할 것인지 택하는 항목이 있었는데, 도메인을 생성한 후에도 따로 네임 서버에 대한 정보를 변경해줄 수 있어서 우선 가비아의 네임 서버 이용에 체크했었다. 그리고 해당 도메인 관리 페이지에서 한 번 더 확인할 수 있다.

AWS Route 53 console에서는 '호스팅 영역'을 생성하면 해당 영역에 대한 '레코드'가 생기고, 그 중에 네임 서버 정보가 있다. 그 네임 서버 정보를 가비아의 네임 서버 자리에 작성하는 방식을 footnote의 블로그에서 언급하고 있다. 그럼 결국에 가비아의 네임 서버 대신에 AWS의 네임 서버를 활용하기 위해 Route 53을 사용했다고 생각할 수 있겠다.

이 Route 53 서비스는 프리티어 계정이더라도 프리하게 사용할 수 있는 것은 아니다. 과금이 필요하기도 하고, 활용 가능한 네임 서버가 없다면 모를까 도메인을 생성한 가비아의 네임 서버를 활용할 수 있기 때문에 필자는 Route 53 서비스를 활용하지 않기로 결정했다.

우선 가비아의 도메인 관리 페이지에서 네임 서버 바로 하단에 있는 DNS 정보의 도메인 연결에 대한 설정을 누른다.

그러면 도메인에 대한 DNS 설정을 할 수 있는데, 이미지에 표기된 레코드 수정 버튼을 눌러보자. 레코드라 함은 앞서 Route 53을 언급했을 때의 그 레코드이다. 버튼을 누르면 수정할 수 있는 작은 창이 뜨는데, 이미지에 작성된 것처럼 A타입에 호스트는 각각 www와 @, 값에는 AWS EC2 인스턴스의 탄력적 IP를 입력해주고 확인 뒤 저장을 눌러준다. 이때 참고한 것은 가비아 홈페이지에서 볼 수 있는 매뉴얼^[각주:3]이며, 혹시 필요한 DNS 레코드의 타입이 궁금하다면 가비아에 설명된 것^[각주:4]이 있으니 참고하면 좋을 것 같다. 필자는 현재 단순하게 도메인으로의 접속만이 목적이기 때문에 A타입 설정만을 해두고 마친다.

문제는 이렇게 해도 도메인을 통해 접근하는 것이 불가능하다는 점이다. 그렇다면 무엇을 더 해야하는 것일까?

Port Forwarding (포트 포워딩)

한 github 게시글에서 그 이유를 알 수 있었다.^[각주:5] 해당 게시글에서는 http의 기본 port는 80, https의 기본 port는 443이라고 언급하고 있다. 해당 내용은 이미지로 첨부한 RFC2616^[각주:6]의 3.2.2 http url 파트를 읽어보면 알 수 있다. 즉, 로컬에서는 8080 port로 개발했지만, 웹에서 http로 도메인을 요청할 때는 80 port가 기본으로 동작하고 있기 때문에 접근할 수가 없는 것이다.

이때 작업해줄 수 있는 것이 port forwarding이다. 글자 그대로 생각하면 port를 나아가게 해준다는 것으로, 특정 port로의 접근에 대해서 다른 port로 접근할 수 있도록 보내준다고 생각할 수 있겠다.

sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080

필자는 EC2 인스턴스에 접속하여 위 명령어를 작성해주었다. 명령어 각 파트의 의미를 친절하게 정리해둔 블로그가 있어서 그 내용을 가져왔다.^[각주:7] 대문자는 반드시 대문자로 표기해야 한다. 필자가 소문자로만 작성하는 것을 좋아해서 소문자로만 작성했다가 명령어가 목표한대로 동작하지 않았다.

iptables : 리눅스상에서 방화벽을 설정하는 도구
-t : 테이블을 지정하는 옵션. 설정하지 않으면 filter 테이블을 default 로 지정
- -t nat : NAT 기능을 사용하겠다
- NAT : Network Address Translation, ip와 port 등을 변환하는 역할,
  실무에서 대부분 서비스는 클라이언트의 ip, port를 내부 프로그램으로 돌릴 때 NAT 테이블을 사용
-A : 새로운 규칙을 추가하는 것(append)
- -A PREROUTING : 목적지가 결정되기전에 적용한다
- PREROUTING : 패킷을 INPUT rule 로 보내기 전 ip 와 port를 변경하는 역할
-i : 새로운 규칙을 삽입(insert)
- -i eth0 : Gateway의 eth0 인터페이스로 들어오는 패킷들에 적용한다
- eth0 : 랜카드의 지정 번지, 이더넷카드 번호0번 이라는 뜻
-p TCP : TCP 프로토콜이면(protocol)
-dport 80 : 목적지(destination) 포트 번호(접속하려는 포트번호가 80번이면..)
-j : 방화벽을 지난 후 패킷을 어떻게 처리해야 할지(jump)
REDIRECT : ~~로 리다이렉트 처리
--to-port : 사용할 destination port

정리하자면 방화벽을 설정할 것인데, Network Address Translation table을 활용하여 routing 전에 이더넷 카드 0번에 들어오는 TCP 프로토콜인 경우 목적지가 80번 포트인 것을 8080 포트로 redirect 하는 규칙을 추가하겠다는 의미이다. 만약 반대로 해당 규칙을 제거하려고 한다면 A(dd)를 D(elete)로 변경해주면 되겠다.

EC2 인스턴스 인바운드 규칙 변경

기존에 필자는 EC2 인스턴스를 생성하면서 80번 포트로의 접근은 허용한 적이 없다. 해당 포트를 열어주어야 할 것이다. 기존 인바운드 규칙에 해당하는 보안 그룹의 이름을 체크하여, 이미지의 왼쪽 하단에 보이는 보안 그룹을 눌러 들어가서 직접 해당 보안 그룹의 인바운드 규칙을 변경해주면 된다. 만약 80번 포트가 이미 규칙에 설정되어있다면, 그냥 넘어가도 될 부분이다.

DNS란 무엇인가?

DNS란 Domain Name System의 약자로, 등록한 도메인과 연결된 IP주소로 사용자를 연결해주는 역할을 하는 전 세계에 배포된 서비스이다. 위 설명은 AWS Route 53에 대한 설명에서 가져왔다.^[각주:8] 관련하여 아주 잘 정리한 게시글이 있어서 해당 내용을 참조하여 정리해보려고 한다.^[각주:9]

Browser에서 특정 도메인에 대한 요청을 하면, 먼저 DNS server로 도메인 주소가 전달된다. DNS server에서는 전달받은 도메인을 기반으로 해당 도메인에 대한 IP 주소를 browser에 전달하여 이쪽으로 가면 된다고 알려준다. 그러면 browser는 해당 IP로 요청하여, 가고자 하는 hosting server에서 제공하는 화면을 보게 되는 것이다. 이것이 가장 기본적인 구조이다. 하지만 인터넷은 넓고 도메인의 수는 너무도 많기 때문에, DNS server의 종류를 계층화하여 단계적으로 처리한다고 한다. 다음의 이미지를 보자.

Root DNS Server : ICANN이 직접 관리하며, TLD DNS Server의 IP를 저장하고 안내한다. 여기에서 ICANN은 Internet Corporation for Assigned Names and Numbers(국제 인터넷 주소 관리 기구)의 줄임말로, 1998년에 설립된 인터넷의 비즈니스, 기술계, 학계 및 사용자 단체 등으로 구성된 기관으로 인터넷 DNS의 기술적 관리, IP 주소공간 할당, 프로토콜 파라미터 지정, 루트 서버 시스템 관리 등의 업무를 조정하는 역할을 한다.^[각주:10]
TLD DNS Server : TLD는 Top Level Domain의 줄임말로, '최상위'를 의미한다. 도메인 등록 기관이 관리하며, Authoritative DNS Server의 IP를 저장하고 안내한다.
Authoritative DNS Server : 개인의 도메인과 IP주소의 관계가 기록되고, 저장되고, 변경되는 server. 일반적으로 도메인/호스팅 업체의 네임 서버를 말한다. 필자의 경우는 가비아의 네임 서버를 의미한다고 생각하면 되겠다. 개인 DNS Server를 구축한 경우도 이곳에 해당한다.

위와 같이 계층화하여 단계적으로 처리된다. 도메인을 요청했을 때, 가장 먼저 Root DNS server에서 .xxx 도메인 IP를 관리하는 TLD DNS Server로 안내한다. 그러면 .xxx 도메인 IP를 관리하는 DNS Server에서 해당 도메인을 관리하고 있는Authoritative DNS Server로 안내한다. 필자의 경우는 가비아의 DNS Server로 안내하는 것이다. 마지막으로 도메인에 대한 IP 주소를 browser에 안내하는 것으로 broswer에서 원하는 도메인에 대한 사이트로 접근할 수 있게 되는 것이다.

Recursive DNS Server : 매번 도메인을 요청할 때, 계층화된 DNS Server를 반복적으로 통과하는 것은 효율적이지 않다. 따라서 일정 기간(TTL : Time To Live)동안 캐시의 형태로 저장하는 역할을 한다. 단순히 캐싱의 역할만을 하기 때문에 Authoritative와 반대되는 Recursive라는 이름으로 불리며, 대표적으로 통신사(ISP : Internet Service Provider)의 DNS server와 구글 DNS와 같은 public DNS Server가 있다.

모든 작업이 완료되었고, 도메인으로의 정상적인 접근을 확인했다. 이번 게시글에서는 가비아에서 도메인을 구입하고, AWS EC2 인스턴스에 탄력적 IP를 연결하여 도메인과 연결했고, 구입한 도메인에 대한 DNS 설정과 port forwarding을 통해서 접속이 원활이 되는지 확인해보았다. 이어서 https에 대한 것은 어떻게 작업하는 것인지 궁금해졌으니 알아보러 가겠다.

티스토리