[ DevOps ] - AWS 기반 소규모 & 중규모 아키텍트 설계 - NACL설정하기

NACL 설정

보통 클라이언트가 80번 포트로 request를 보내게 되면, 서버는 1025포트와 같이 다른 포트로 쏴줍니다.

다음과 가팅 들어오는 위치를 inbound라고 하고, 나가는 것을 outbound라고 합니다. outbound의 임시포트의 범위는 (1024 ~ 65535)입니다.

Security Group은 Stateful합니다. 이는 요청한 상태를 기억한다는 의미입니다. inbound가 80이고 outbound가 none이라는 뜻은 안으로 80번 포트로는 들어올 순 없지만 밖으로 나가는건 다 막아버리겠다라는 것입니다. 하지만 Security Group은 Stateful하기 때문에 상태를 기억해서 밖으로 1025번 포트로 다시 쏴줄 수 있다는 것입니다.

 

다음은 stateless한 NACL입니다. 이는 상태는 중요하지 않다 즉 어떻게 들어오든 기억하지 않겠다. 나는 오직 설정된 규칙에 따라서만 작동하겠다는 의미입니다.

이와 같이 stateless한 NACL은 1025번 포트로 다시 요청을 내보낼 수 없게 됩니다.

 

NACL이 SG보다 더 엄격한 룰이라고 할 수 있겠습니다. 이는 들어와도 나갈때 무조건 막히게 되기 때문입니다.

 

이제 이전에 설정한 VPC에서 NACL을 다시 설정해 보도록 하겠습니다. 기본적으로 VPC를 만들게 되면 기본 NACL이 하나 있는데 이를 private_NACL로 이름을 바꾸어 주겠습니다.

이 외에도 public_NACL을 만들어 주도록 하겠습니다.

public_NACL을 만들어주고 서브넷과 연결해 주도록 하겠습니다.

다음과 같이 자동적으로 private-subnet, public-subnet에 NACL이 자동적으로 배분된 것을 확인할 수 있습니다.

 

 

그 다음으로 이제 public_NACL의 인바운드 규칙을 설정해 보도록 하겠습니다.

규칙번호는 일종의 순서입니다. 먼저 22번 포트에 대한 규칙을 보고, 80번 포트에 대한 규칙을 보고 높은 규칙 번호 순으로 보게 되는 것입니다.

 

만약 규칙번호에 101을 저장하고 포트번위를 22로 하고 거부를 하게 된다면, 이는 소용없는 행동이 됩니다. 그 이유는 22번 포트로 들어오는 상황인데, 이는 이미 100번 규칙에서 끊긴것과 마찬가지이기 때문입니다.

 

근데 만약 추가하는 규칙번호를 99로 하게 된다면, 이를 거부하게 되는 원리입니다.

 

또 한가지 경우를 생각해 보겠습니다.만약 규칙번호로 101번을 저장하고 0~65535포트에 대해서 거부를 한다면 이는 22번 포트 외에는 다 차단하는 인바운드 규칙이 되는 것이라고 할 수 있습니다.

 

또한 인바운드를 했으니까, 아웃 바운드도 설정해 보도록 하겠습니다.

NACL은 stateless하기 때문에 정확하게 작성해 주어야 합니다. 임시포트인 1024~65535을 허용해주었습니다.