지난번에 글을 적다 말았다,,
AWS에서 제공하는 NAT 이미지를 사용해도 되지만, 그러면 과금이 된다는 말에 놀라서 직접 NAT Instance 를 구축하기로 했다.
어렵지도 않은 일을 못해서 공부한다고 하루를 날렸더니 온 몸이 뻐근ㅠ
아무리 웹개발자라지만 너무하지않나 생각
일단 내가 만들고싶은 구성은 이러했다.
간단하기는 한데 암튼 private subnet에 있는 api서버랑 db서버의 라우팅을 변경해서 NAT로 쏘게 만드는 것이었음.
원래는 회사에서 하던것처럼 아주 베이스부터 하나하나 설정해주려고 했는데 AWS에서는 그렇게 할 수 없다는 것을 깨달았다. 그 이유는 나중에 서술.
실제로 우리 프로젝트에서는 Bastion Host랑 NAT를 분리하고 싶은데.. 그게 Bastion Host의 의미가 맞는지 솔직히 잘 모르겠다
NAT Instance 구축
- 일단 NAT Instance로 쓸 EC2를 하나 생성한다
앞서 말했듯 나는 기본으로 제공하는 NAT용 AMI를 이용할 생각이 없었기 때문에 그냥 Red Hat으로 t3.micro를 하나 올려줬다.
당연하게도, 보안 그룹은 SSH 설정을 나의 IP만 가능하도록 최초에 설정해두었다.
처음부터 보안 그룹을 잘 설정하면 되지만 난 천재가 아니니까
- EC2 Instance에 Putty로 SSH 접속 후 해야할 일
서비스 시작
yum isntall iptables-services -y
systemctl enable iptables
systemctl start iptables그리고 나서 net.ipv4.ip_forward라는 녀석을 사용하겠다(1)로 바꿔줘야 한다고 한다.
이유는 아래의 블로그에서 잘 설명해주셔서 감사하게도 이해가 잘 되었다.
나의 것을 drop하지 않고 흘려주는 router 역할을 해야하기 때문에 해당 설정을 켜준다는 의미
sysctl -w net.ipv4.ip_forward=1echo로 넣는 글들이 많았는데 sysctl의 w 옵션을 이용하면 간단하게 write 가능
그다음에 AWS document에서는
sysctl -p /etc/sysctl.d/custom-ip-forwarding.conf를 사용하라고 되어있는데 이걸 사용하면
sysctl: cannot open "/etc/sysctl.d/custom-ip-forwarding.conf": No such file or directory
이런 오류가 뜬다.
이유는? 잘모르겠다. 근데 위치 가서 찾아보니까 저런 컨픽 없더라.
그래서 다른 블로그를 참조하여 net-tools를 먼저 설치하고 iptables 설정을 먼저 한 다음에 서비스를 저장하는 방법을 사용했다.
(나 일할 때 service 옛날거라고 들었는데 사용하고 있음.. 왜지?)
- iptables 설정
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -F FORWARD
service iptables save여기서 고생을 많이 했는데..
다른 블로그에서는 FORWARD 를 기본 DROP으로 설정하도록 했음.
그리고 룰을 넣어줬어야 하는데... 그 부분까지 못가고 나와버렸다...
(만약 eth0이랑 eth1에 관한 룰을 넣어줬으면 됐을까? 테스트해보고 후기 적자.)
어쨌든 FORWARD 설정은 초기화만 해주고 ACCRPT로 남긴 채 POSTROUTING (받는거 어떻게 보낼건지) 만 설정해주도록 하였다.
여기서 잠깐 이야기해보자면, 난 처음에 ifconfig에서
local이랑 eth0만 뜨길래
당연히 eth1을 넣어줘야 할거라고 생각했다.
그래서 네트워크 인터페이스에 들어가서
무려 인터페이스를 집어넣는 만행을 저질렀음.
그런다음에 아~ 이 인터페이스에다가 private subnet을 연결해주면 되겠지~~ 했음
근데 그건 안됨. 왜? 솔직히 잘 모르겠음...ㅠㅠㅠ
회사에서는 자사 인프라 구축을 해서 써서 이렇게 직접 했어야 했는데, (남자친구도 같이 헤맸음) 근데 AWS document를 확인하니 그냥 기본 eth0에다가 다 설정을 하는 것으로 확인했음..
그래서 그냥 eth0만 사용하기로 하고 네트워크 인터페이스는 드랍했다 ,,,
여기서 시간을 너무 날려먹었어 흑흑흑
암튼 NAT Instance 서버 내에서의 설정은 여기까지만 하면 됨.
결론, eth1은 필요없었다.
그 다음은 이제 API 서버에 대한 설정이다.
실제로 API 서버에 들어가서 route를 직접 설정해주려고 했는데, 그건 나의 판단 미스였다 ㅠ
왜냐면, subnet이 다르기 때문에 NAT 과 API 서버는 다른 대역폭에 존재하고 있으므로, 바로 라우팅 설정을 해줄 수 없다,,,
그림에 있는 파란색 GW를 통해서 밖으로 나가기 때문에 GW에다가 '너는 여기로 가야 해.' 라는 걸 알려줘야 했다,,
- API 서버가 속한 private subnet의 게이트웨이 설정
막말로 이거 한줄 넣는건데..
말 그대로 private subnet의 라우트 테이블한테 가서
너는 들어오는 모든 걸 여기로 보내. 하고 알려주는 과정이다.
친절하게도 라우팅 편집 > 추가 를 누르면 어디서 어디로 갈건지 추가하도록 뜨는데,
여기서 도착지 설정할 때 인스턴스 옵션을 선택하면 내가 가진 인스턴스들이 나온다. 거기서 방금 설정을 마친 NAT Instance를 선택해준다.
그리고 ip route show을 하면? 놀랍게도 아무것도 안나온다. 당연하지 왜냐면 subnet 라우팅 설정을 한거인걸. ㅋㅋㅋ..
그런 다음에 ping을 날렸더니 안날라가서 또 20분 까먹음
- NAT Instance의 보안 그룹 설정
방화벽 설정을 깜빡했다.
NAT Instance의 인바운드 설정을 SSH로 나의 IP만 걸어놓고 아무것도 안걸어놨으므로 당연히 API 서버에서 접근이 불가능하다.
그래서 NAT Instance의 인바운드 설정에 프로토콜을 ICMP, IP를 내 Private Subnet의 대역폭으로 설정하고 룰을 추가해줬다.
난 정말 여기서 끝인 줄 알고 ping을 때렸는데.. 또 안가는것이다 ㅠㅠㅠㅠㅠ 마지막 AWS의 숨겨진 함정카드 발동!!!
- 인스턴스의 원본/대상 확인 비활성화 옵션 확인
어쩌면 AWS가 참 잘 되어있다는 생각을 하면서도, 막상 이용을 하려니 이 내부적인 옵션들이 참 많다는 걸 깨닫게 되는 부분이었다.
어쨌든 옵션을 비활성화 해주어야 한다.
기본적으로 아래 사진의 중지 옵션이 꺼져 있는데, 체크박스를 눌러서 비활성화 시켜주자!
그러고 나면 ?
짜잔,,
나 이 4 bytes from ... 이 안내문이 너무 보고싶었다...
성공적으로 인터넷에 연결!!!!!!
ref: https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/work-with-nat-instances.html#EIP_Disable_SrcDestCheck