2024. 1. 1. 20:20ㆍ프로그래밍/AWS
이전에 AWS 실습으로 진행했던 가비아 도메인 네임 서버 연결 및 https 적용한 사이트에서 1가지 문제점을 발견해 이에 관한 수정 사항 및 이유에 대해 정리하려고 한다.
현재 서버에서 사용하고 있는 포트 포워딩은 80 -> 3000, 443 ->3000 으로 총 2개의 규칙이었다.
설정한 규칙을 확인하는 방법은 아래와 같이 iptables 명령어를 사용하는 것이다.
# iptable 관련 설정 규칙 확인
sudo iptables -t nat -L -n -v
pkts bytes target prot opt in out source destination
26 1560 REDIRECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 redir ports 3000
관련 유용한 명령어는 다음과 같다.
# 포트포워딩 방법
sudo iptables -t nat -A PREROUTING -p tcp --dport <원본포트> -j REDIRECT --to-port <대상포트>
# 설정한 포트포워딩 관련 규칙 삭제
sudo iptables -t nat -D PREROUTING <규칙번호>
여기서 나는 443 -> 3000 규칙을 제거했다. 그 이유를 알기 위해 우선 AWS에서 설정한 리스너 규칙에 대해 설명한다.
현재 사용중인 로드밸런서에 생성된 리스너 규칙은 위와 같다. 단순하게 설명하자면 80번 포트로 들어오는 요청은 HTTPS 프로토콜을 적용하며 443번 포트로 리다이렉션을 적용하고 443번으로 들어온 요청은 설정한 타겟 그룹과 연결된다. 여기서 타겟 그룹은 내가 서버에서 가동중인 EC2 인스턴스를 뜻한다.
여기서 인바운드 규칙에 웹 어플리케이션 포트(일반적으로 spring은 8080, node는 3000)를 열어놨다면 애시당초 서버에서 3000으로 리다이렉션 할 필요도 없었겠지만 우선 네트워킹을 이렇게 구성했으니 서버에서는 80번 포트로 들어온 요청을 웹 어플리케이션의 포트(3000번)로 포트포워딩을 해줘야 한다. 그런데 여기서 한가지 의문점이 있었다. 서버에 최종적으로 들어오는 요청의 포트번호는 80번일까 443번일까?
정답은 본인이 타겟 그룹에 설정한 포트대로 이다.
필자는 아래와 같이 설정하고 사용하고 있었다.
이를 HTTP:443 으로 변경 후 테스트 결과 health check도 성공하지 못하고 요청도 제대로 도달하지 못하고 bad gateway를 뱉어냈다.
이를 해결하기 위해서 443번도 포트포워딩을 해줬으나 결과는 마찬가지였다. 조금 리서치 한 결과 아래와 같은 글을 찾을 수 있었다. 필자도 방화벽 및 여러가지 설정을 뒤져봤지만 해결할 수 없었기 때문에 그냥 인스턴스와 타겟 그룹간의 통신은 HTTP로 하는 게 맞는 것 같다.
https://afrobambacar.github.io/2018/10/target-group-https-protocol.html
즉 클라이언트에서 AWS를 거쳐 서버로 요청이 가는 과정을 요약하자면
1. 클라이언트(80) -> 로드밸런서 // 443 으로 요청이 바로 들어온 경우 3번으로 이동
2. 로드밸런서의 리스너 규칙에 의해 80 -> 443 리다이렉션
3. 443번 통신을 유지한 채 타겟그룹으로 요청 이동
4. 타겟 그룹에 설정한 인스턴스(서버)와 HTTP(80)로 통신
5. 서버에서는 80번 포트로 요청이 들어온 것이기 때문에 80번 포트에 대한 포트포워딩을 설정해줘야 함.