[DevOps] Rinetd를 활용한 portforward

[DevOps] Rinetd를 활용한 portforward

안녕하세요? 정리하는 개발자 워니즈 입니다. 이번시간에는 Public subnet에있는 Deploy tool을 통해서 Private Subnet에 존재하는 서버들에 대해서 배포를 수행하기 위한 고민을 했던 포스팅 입니다.

필자가 소속된 프로젝트에서는 운영 환경에서 2개 이상의 AWS Region에서 서비스를 하고 있습니다. Deploy 같은 경우 하나의 Tool(Rundeck)에서 수행되어야 하는 것을 목표로 했었습니다.

이번 포스팅에서 소개할 내용은 rinetd라는 포트포워딩 툴입니다.

1. 구성 상황

서두에 기록을 해두었지만, 2개 이상의 Region에서 운영되는 서비스인데다가, 한개의 region의 public영역에서 다른 region의 private영역으로 연결을 시도할 때가 당연히 문제가 되었습니다. 그렇다고, 각 region별로 deploy tool을 둘수도 없는 상황이기에 약간의 꼼수(?)를 부리기 위해서 알아보다보니, rinetd를 알게 되었고, 한개의 region의 public에서 다른 region의 public으로 붙은다음에 거기서 포트포워딩으로 패킷을 전달해주는 방식을 채택하기로 했습니다.

rinetd_1

2. rinetd란 무엇인가요?

TCP 연결을 한 IP 주소 및 포트에서 다른 IP로 리다이렉션을 수행하게끔 해주는 툴입니다. 설정 파일을 통해서 from에서 to로 명시적으로 기록을 합니다.

설정 파일을 통해서 수행되지만, nonblocking I/O를 이용하여 단일 프로세스로 수행되기 떄문에 프로세스 수행상에 문제를 발생시키지 않는다고 되어있습니다.

rinetd_0

3. rinetd 설치 방법

# /etc/yum.repos.d/nux-misc.repo 내 추가 
[nux-misc]
name=Nux Misc
baseurl=http://li.nux.ro/download/nux/misc/el7/x86_64/
enabled=0
gpgcheck=1
gpgkey=http://li.nux.ro/download/nux/RPM-GPG-KEY-nux.ro

# rinetd 설치
yum --enablerepo=nux-misc install rinetd

설치는 상당히 심플 합니다. yum을 통해서 설치를 진행하면 되고, 포트포워딩을 수행할 서버에서 설치를 진행하면 됩니다.

3. rinetd 설정 방법

# rinetd 설정 파일 수정
vi /etc/rinetd.conf

rinetd_3

실제 설정파일에는 가이드도 친절하게 젂혀 있습니다.
예를들어, 10.10.10.2(rinetd가 설치된 서버) 80 포트로 접속을 수행했을때, 192.168.0.2:80 으로 보내라는 설정은 다음과 같습니다.

0.0.0.0 80 192.168.0.2 80   

IP기반으로 ACL에 대한 설정도 가능합니다.

# 172.16.32.0/24 대역 ALLOW
allow 172.16.32.*

# 192.168.32.12 아이피 DENY
deny 192.168.32.12

로그에 대한 기록도 수행해 줍니다.

# log 경로 셋팅
logfile /var/log/rinetd.log

설정을 모두 마친후, rinetd를 재시작하게 되면 적용이 됩니다.

[root@testuser ec2-user]# service rinetd restart
Restarting rinetd (via systemctl):                         [  OK  ]

4. 접속 테스트

그럼 서두에 기록했던, 한개의 region public subnet의 인스턴스에서 다른 region의 public subnet의 인스턴스로 접속을 수행합니다.

ap regsion public A ec2 -> eu region public B ec2 ->portforward -> eu region private C ec2

rinetd_2

5. 마치며..

이번 시간에는 rinetd를 활용한 포트포워딩 프로그램에 대해서 정리해보는 시간을 갖었습니다. 네트워크 쪽은 공부를 하면 할수록 정말 어려운 분야 인 것 같습니다. VPC 설계부터 subnet 그리고 route table, NAT의 개념에 대해서도 다시금 정리를 해두어야 할것 같다는 생각을 해보았습니다.

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다