오라클 클라우드 인스턴스 포트 개방 (우분투)

개요

 개인 프로젝트 성능 측정을 위해 scouter(apm) collector를 띄우고자 했습니다. 프로젝트는 온프레미스 서버에서 실행 중이었고 이와 분리된 환경에 scouter collector를 실행하길 원하였고, 평생 무료 인스턴스 2개를 지원하는 오라클 클라우드를 선택하였습니다. 하지만 AWS에서 설정하는 것과 비슷하게 오라클 클라우드 콘솔에서 포트 개방을 해주었으나 접속이 되지 않았고 누군가 도움이 되기를, 미래에 내가 찾아볼 수 있도록 해결하는 과정을 정리했습니다.

 

요약: 오라클 클라우드 인스턴스 포트 개방 방법 정리

 

환경

오라클 클라우드 인스턴스

구성: VM.Standard.E2.1.Micro

이미지: Canonical-Ubuntu-20.04-2023.10.15-0

 

비교용 AWS EC2

유형: t2.micro

이미지: Canonical, Ubuntu, 20.04 LTS, amd64 focal image build on 2023-10-25

  (Ubuntu Server 20.04 LTS (HVM), SSD Volume Type)

 

테스트

테스트를 위해 각각 80번 포트를 열었고, 포트 개방 설정이 정상적으로 되었는지 확인하기 위해 nmap과 nginx를 설치하여 포트 개방 여부를 확인했습니다.

 

각 VM에서 진행한 과정

- nginx 설치

- curl localhost 로 nginx 설치 확인

 

로컬 pc에서 진행한 과정

- nmap으로 포트 스캔

- 각 VM의 nginx로 접속

 

 

포트 개방 (with Web UI)

AWS EC2

보안 그룹의 인바운드 규칙에 80번 포트를 추가해 주었습니다.

 

오라클 클라우드 인스턴스

네트워크 보안 그룹을 설정해보기도 하였고, 서브넷 설정도 해보았습니다.

 

 

nmap, nginx 접근 테스트

AWS EC2

nmap 결과

nmap {ec2 ip}
Starting Nmap 7.94 ( https://nmap.org ) at 2024-02-01 16:35 KST
Nmap scan report for ec2-{ec2 ip}.ap-northeast-2.compute.amazonaws.com ({ec2 ip})
Host is up (0.013s latency).
Not shown: 998 filtered tcp ports (no-response)
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

 

nginx 접근

 

EC2의 경우 인바운드 규칙 설정으로 포트가 정상적으로 개방되었습니다.

 

오라클 클라우드 인스턴스

nmap 결과

nmap {instance ip}
Starting Nmap 7.94 ( https://nmap.org ) at 2024-02-01 16:48 KST
Nmap scan report for {instance ip}
Host is up (0.0096s latency).
Not shown: 998 filtered tcp ports (no-response)
PORT   STATE  SERVICE
22/tcp open   ssh
80/tcp closed http

 

nginx 접근

 

오라클 클라우드 인스턴스의 경우 보안 그룹 및 서브넷 설정을 해주었음에도 불구하고 nginx에 접근할 수 없었습니다.

 

만약 보안 그룹 및 서브넷 설정이 제대로 적용되지 않았다면 ssh 포트도 접근이 막혀야 정상일 것이고, nmap 결과를 보면 ssh의 경우 open, http(80) 는 closed 되어있는 것을 확인할 수 있었습니다.

open 상태는 접근 가능을 의미하고, closed는 접근 가능은 하나 해당 포트를 사용 중인 어플리케이션이 없는 경우를 의미합니다.

즉, Web UI에서 네트워크 설정은 정상적이지만 인스턴스에서 방화벽이 동작하고 있다고 추측하였습니다.

 

nmap state 의미 참고

Port Scanning Basics | Nmap Network Scanning

 

 

방화벽 확인

우분투의 경우 기본적으로 ufw를 사용하기 때문에 각 환경에서 ufw를 확인해보았습니다.

 

AWS EC2

ufw 활성화 확인

sudo ufw status
Status: inactive

 

EC2의 경우 ufw가 활성화되어 있지 않았습니다.

 

오라클 클라우드 인스턴스

ufw 활성화 확인

sudo ufw status
Status: inactive

 

오라클의 경우에도 ufw가 활성화되어있지 않음을 확인했습니다.

(?!?!?!?!)

 

뭔가 이상한 것 같아 다른 방화벽 서비스가 있는지 확인해 본 결과

service --status-all
...
 [ + ]  netfilter-persistent
...
 [ + ]  nginx
 ...
 [ + ]  ufw
 ...

 

netfilter-persistent가 확인되었고 활성화되어 있는 것을 확인했습니다.

sudo systemctl status netfilter-persistent
● netfilter-persistent.service - netfilter persistent configuration
     Loaded: loaded (/lib/systemd/system/netfilter-persistent.service; enabled; vendor preset: enabled)
    Drop-In: /etc/systemd/system/netfilter-persistent.service.d
             └─iptables.conf
     Active: active (exited) since Thu 2024-02-01 04:51:50 UTC; 3h 23min ago
       Docs: man:netfilter-persistent(8)
   Main PID: 596 (code=exited, status=0/SUCCESS)
      Tasks: 0 (limit: 1050)
     Memory: 0B
     CGroup: /system.slice/netfilter-persistent.service

 

혹시나 EC2도 다른 방화벽이 있는지 확인해 본 결과 ufw 외 방화벽 서비스는 확인되지 않았습니다.

 

즉, AWS에서 제공하는 우분투 이미지는 기본적으로 ufw, 방화벽이 비활성화되어 있고, 오라클의 경우 netfilter, iptables를 사용한 방화벽이 활성화되어 있었습니다.

 

결론 및 방법

오라클의 우분투 이미지는 기본적으로 방화벽이 활성화되어있어, 네트워크 설정뿐만 아니라 인스턴스의 방화벽 설정도 필요하다.

 

(오라클 공식 문서를 보니 접근에 문제가 있는 경우 방화벽 설정까지 확인하라고 되어있었네요.)

오라클 리눅스 방화벽 규칙

 

iptables, netfilter-persistent 설정

- 포트 개방

sudo iptables -I INPUT 1 -p tcp --dport 80 -j ACCEPT

 

- netfilter-persistent iptables 설정 저장

iptables의 경우 재부팅 시 설정이 초기화되어 netfilter-persistent로 저장해 줍니다.

sudo netfilter-persistent save

sudo netfilter-persistent reload

 

그리고 다시 nmap을 돌려보면

nmap {instance ip}
Starting Nmap 7.94 ( https://nmap.org ) at 2024-02-01 17:32 KST
Nmap scan report for {instance ip}
Host is up (0.0092s latency).
Not shown: 998 filtered tcp ports (no-response)
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

 

정상적으로 80번에 접근할 수 있음을 확인할 수 있습니다.

(+ nginx 접근도 잘 되네요.)

 

추가로 iptables 목록을 확인하는 명령어는 아래와 같고

sudo iptables -L

 

이 블로그에 따르면 iptables는 규칙 순서가 중요하다고 하니 참고하시면 좋을 것 같습니다.

https://blog.naver.com/koromoon/220415972008

iptables