[AWS EC2 - Amazon Linux 2023 OS] 포트 리다이렉트(port redirect )하며 발생한 이슈 정리

Denia·2024년 1월 5일
2

TroubleShooting

목록 보기
11/24

AWS EC2의 포트 리다이렉트를 하면서 겪은 이슈를 이야기 하고, 어떤 것이 문제였는지 알아보겠습니다.

문제 상황

제가 진행중인 사이드 프로젝트를 AWS EC2에 배포 후, 80 포트로 접속을 하더라도 8080포트로 접속이 되게 하려고 포트 리다이렉트를 하려고 했습니다.

그래서 인터넷에서 리눅스 포트 리다이렉트에 관해서 검색 후, 블로그에서 알려주는 커맨드대로 진행을 했으나 80포트에서 8080포트로 리다이렉트가 되지 않았습니다.

아래 커맨드가 블로그에서 찾은 커맨드입니다.

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

포트 리다이렉트가 제대로 등록이 안되었나 싶어서 목록도 확인해봤습니다.

sudo iptables -t nat -L

내용을 확인해봐도 정상적으로 tcp의 입력에 대해서 80포트8080포트로 리다이렉트 시키고 있는게 나옵니다.

(※ 전에 제가 해당 명령어로 AWS EC2에서 포트 리다이렉트를 진행한 경험이 있었어서 더욱 더 문제의 원인에 대해서 감을 잡지 못했습니다.)

여러 글들을 찾아봤지만 위의 커맨드랑 동일한 내용만 나오고 다른 내용들을 찾아볼 수가 없었습니다.

그렇게 문제의 원인에 대해서 내용을 찾던 와중에, 약간 다른 명령어를 추천해주는 외국 포럼의 Q&A 글을 보게되었습니다.

해당 글에서는 다음과 같은 커맨드를 알려줬습니다.

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

처음에 봤을때는 전에 제가 입력한 명령어와 그리 다르지 않아서 넘어갈려고 하다가 혹시나 해서 적용을 해보니, 정상적으로 80포트에서 8080포트로 리다이렉트가 되었습니다.

혹시나 무엇이 다른가 싶어서 목록을 확인해보니 똑같은 내용이었습니다.

sudo iptables -t nat -L

정상적으로 동작을 하는 커맨드와 정상적으로 동작을 하지 않는 커맨드를 찾았으니, 이제는 무엇이 달라서 혹은 무엇 때문에 동작이 제대로 되지 않은 것인지 찾아볼 일만 남게 되었습니다.


트러블 슈팅

우선 제가 사용한 EC2OSAmazon Linux 2023 입니다.
(※ 해당 OS는 iptables가 기본적으로 깔려있지 않아서, 따로 설치해주셔야 합니다.)

설치 명령어 - yum install iptables

커맨드에 대해서 자세히 알아보기

인터넷에 AWS EC2 포트 포워딩 혹은 리눅스 포트 포워딩, 리눅스 포트 리다이렉트를 치게 되면 관련된 자료들이 많이 나옵니다.

해당 자료들의 내용은 대부분 iptables를 사용하여, 80 포트를 특정 포트로 포트 리다이렉트 하도록 되어있습니다.

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

해당 내용에 대해서 자세히 살펴 보면 다음과 같습니다.

  • sudo: 슈퍼유저(루트)로 다음 명령을 실행하는 데 사용되는 명령으로, 일반적으로 관리자 권한이 필요합니다.

  • iptables: 이는 Linux 시스템에서 방화벽 규칙 및 네트워크 주소 변환(NAT)을 관리하는 데 일반적으로 사용되는 netfilter 방화벽 시스템과 상호 작용하는 데 사용되는 명령입니다.

  • -t nat: 이 옵션은 규칙을 추가해야 하는 iptables 내의 테이블을 지정합니다. 이 경우에는 NAT(Network Address Translation) 규칙에 사용되는 'nat' 테이블입니다.

  • -A PREROUTING: 명령의 이 부분은 규칙이 추가되어야 하는 체인을 지정합니다. PREROUTING 체인은 NAT 테이블의 일부이며 라우팅 결정을 내리기 전에 패킷을 처리하는 역할을 담당합니다. 일반적으로 라우팅 전에 적용되는 패킷 맹글링 및 NAT 규칙에 사용됩니다.
    (※패킷 맹글링(Packet Mangling)은 보안을 위해 패킷 헤더 데이터를 의도적으로 변경하는 작업입니다.)

  • -i eth0: -i 옵션은 규칙을 적용해야 하는 네트워크 인터페이스(이 경우 eth0)를 지정합니다. 이 규칙은 eth0 네트워크 인터페이스에 도착하는 트래픽에 영향을 미치도록 설계되었습니다. 트래픽이 다른 인터페이스에 도착하는 경우 이 규칙은 적용되지 않습니다.

  • -p tcp: 명령의 이 부분은 규칙이 적용되어야 하는 프로토콜(이 경우 tcp)을 지정합니다. 이는 규칙을 TCP 트래픽으로 제한합니다. 즉, TCP 패킷에만 영향을 미칩니다.

  • --dport 80: 들어오는 패킷이 향하는 대상 포트(이 경우 80)를 지정합니다. 규칙은 수신 패킷을 HTTP 트래픽의 기본 포트인 대상 포트 80과만 일치시킵니다.

  • -j REDIRECT: -j 옵션은 패킷이 규칙과 일치하는 경우 수행할 대상 작업을 지정합니다. 이 경우 iptables에게 패킷을 다른 대상으로 리디렉션하도록 지시하는 REDIRECT입니다.

  • --to-port 8080: 명령의 이 부분은 패킷이 리디렉션되어야 하는 대상 포트(이 경우 8080)를 지정합니다. 따라서 대상 포트가 80인 모든 수신 TCP 패킷은 포트 8080으로 리디렉션됩니다.

이렇게 등록할 경우, 이 iptables 규칙은 대상 포트가 80(HTTP)인 eth0 네트워크 인터페이스에서 들어오는 TCP 패킷을 가로채서 포트 8080으로 리디렉션합니다.

두 커맨드간의 차이점 알아보기

두 커맨드의 차이점이 무엇인지, 기존 커맨드는 안되고 신규 커맨드는 된 이유를 바로 알아차리신 분들은 대단하신 것 같습니다.

두 커맨드간의 차이는 -i eth0 입니다.

기존 커맨드는 eth0 네트워크 인터페이스에 해당하는 요청들만 포트 리다이렉트를 진행하지만, 신규 커맨드는 -i eth0 옵션이 없기 때문에 특정 네트워크 인터페이스가 아닌 모든 네트워크 인터페이스의 요청을 포트 리다이렉트 하게 됩니다.

그러면 현재 사용중인 EC2의 네트워크 인터페이스가 어떻게 되길래 eth0 네트워크 인터페이스 요청들이 모두 무시가 된 것 일까요 ??

현재 사용중인 EC2의 네트워크 인터페이스 조사하기

ifconfig

해당 커맨드를 linux에서 사용하시면, 다음과 같은 내용들이 나타나게 됩니다.

(※ 사설 ip, 사용중인 네트워크 정보 등등의 데이터가 나오는 것을 보실 수 있습니다.)

여기서 가장 주목해서 보셔야 하는 내용은 맨 첫번째 줄의 맨 왼쪽 단어 enX0 입니다.

enX0 가 현재 제가 사용중인 EC2의 네트워크 인터페이스입니다.

결론

그렇습니다. 기존의 커맨드가 동작하지 않았던 가장 중요하고도 큰 이유는 네트워크 인터페이스제가 설정한 것(eth0)제가 사용중인 것(enX0)이 달랐기 때문에 정상적으로 동작을 하지않은 것입니다.

기존 커맨드 내용을 살펴보면 eth0으로 들어온 요청만을 처리하는데, 애초에 해당 요청이 들어오지를 않으니 (네트워크 인터페이스가 다르니... ) 처리가 되지 않은 것이었고, 모든 요청에 대해서 리다이렉트 되도록 처리를 하니 정상적으로 포트 리다이렉트가 된 것 이었습니다.


후기

이제는 문제에 대해서 명확하게 알게되었으니 추가적으로 실험을 해봤습니다.

모든 요청에 대해서 포트 리다이렉트를 하도록 하는 것이 아니라, 현재 제가 사용중인 네트워크 인터페이스 (enX0)에 대해서만 포트 리다이렉트 하도록 커맨드를 입력해봤습니다.

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

해당 커맨드도 역시나 포트 리다이렉트가 정상적으로 동작을 했습니다.

간단하다면 정말 간단하고도 쉬운 문제인데, 문제의 원인을 몰라서 한참을 헤맨 것 같습니다.
(모든 트러블 슈팅이 그러하지만 ...)

해당 트러블 슈팅 덕분에 리눅스의 네트워크 설정에 대해서 조금 더 공부하고 배울 수 있었습니다.

profile
HW -> FW -> Web

2개의 댓글

comment-user-thumbnail
2024년 4월 28일

감사합니다... 정말로...

1개의 답글