2일차 (NACL, ACG, Prometheus)

둘째 날 아침에 서버 두 대를 만들었다. 관리용 한 대, 워크로드 쪽에 한 대.

관리 서버에서 워크로드 서버로 SSH를 걸었다. 연결이 안 붙고 confused 에러가 떴다.

전날 종일 만든 게 네트워크였으니 길은 있을 거라고 생각했다. Route Table도 확인했고 Peering도 운영 중이었다. 그런데도 안 됐다.

혼자서는 원인을 못 찾아서 강사님께 여쭤봤다. 설정을 같이 보고 나서야 알았다. NACL 아웃바운드가 비어 있었다. 강의 자료 표에도 있던 줄인데 내가 건너뛴 것이었다.

이날 배운 것들을 내가 이해한 대로 정리해둔다.

NACL과 ACG

무엇인가. 둘 다 방화벽인데 서 있는 자리가 다르다.

• NACL(Network ACL) — Subnet 경계에 놓인 검문소다. 그 Subnet 안의 서버 전부에게 똑같이 적용된다.
• ACG(Access Control Group) — 서버 한 대의 랜카드에 붙는다. 그 서버에만 적용된다.

언제 쓰나. NACL은 "이 구획 전체에 공통으로 거는 규칙", ACG는 "이 서버만의 규칙"으로 나눠 쓴다고 이해했다. 층이 겹쳐 있어서 NACL을 통과해도 ACG에서 막힐 수 있고 그 반대도 된다. 어느 쪽에서 막혀도 증상은 똑같이 "안 됨"이다.

Stateful과 Stateless

전날 노트에 이렇게 적어놨었다.

Stateful (NACL) — 인바운드로 들어온 규칙이 나갈 때도 유지됨
Stateless (ACG) — 나갈 때 그 규칙이 사라짐

반대로 적어놨다. 표에는 제대로 적어놓고 그 위 문장에서 뒤집어 놓은 걸 나중에야 봤다.

제대로는 이렇다.

• ACG가 Stateful이다. 허용한 요청의 응답은 자동으로 통과시킨다. 연결을 기억한다.
• NACL이 Stateless다. 기억하지 않는다. 나가는 패킷과 들어오는 패킷을 각각 따로 본다.

말로만 보면 별 차이 없어 보이는데, 규칙을 쓸 때 차이가 크게 벌어진다는 걸 이날 몸으로 알았다.

임시 포트

왜 차이가 벌어지는지는 SSH가 오가는 모양을 보고 이해했다.

관리 서버  :51234   →   워크로드 서버 :22      (요청)
관리 서버  :51234   ←   워크로드 서버 :22      (응답)

요청은 클라이언트의 임시 포트에서 서버의 고정 포트(22)로 간다. 응답은 서버의 22번에서 클라이언트의 임시 포트로 돌아온다. 이 임시 포트를 이 과정에서는 32768-65535로 잡았다.

ACG는 여기서 할 일이 없다. 22번 인바운드를 열어두면 그 연결의 응답은 알아서 나간다.

NACL은 다르다. 요청 방향을 허용해도 응답 방향을 자동으로 허용하지 않는다. 그래서 규칙이 이렇게 짝을 이룬다.

내가 빠뜨린 게 아래 줄이었다. 요청은 무사히 들어갔고 서버는 응답도 만들었고 그 응답이 Subnet 경계에서 버려졌다.

흐름으로 정리하면. NACL 규칙을 쓸 때는 한 번에 두 줄을 쓴다고 생각하면 될 것 같다. 요청이 가는 줄 하나, 응답이 돌아오는 줄 하나. ACG는 한 줄이면 된다.

기본값

기본 동작도 반대라고 했다.

NACL은 전체 허용에서 시작한다. 그래서 마지막 우선순위(이 과정에서는 199번)에 0.0.0.0/0 전체 Deny를 깔아두고 그 앞에 필요한 것만 하나씩 Allow로 올린다. 닫아놓고 여는 게 아니라, 닫는 규칙을 맨 뒤에 놓고 그 앞을 채우는 방식이다.

ACG는 전체 차단에서 시작한다. Deny 규칙이라는 게 아예 없다. 적어놓은 Allow만 통하고 나머지는 전부 막힌다.

우선순위 개념이 NACL에만 있는 것도 이 때문인 것 같다. Allow와 Deny가 섞여 있으니 순서가 결과를 바꾼다. 아래쪽에 잘 써놓은 Allow가 위쪽 Deny 때문에 한 번도 안 읽히는 일이 생긴다.

SSL VPN

무엇인가. 인터넷에서 VPC 안쪽으로 들어오는 전용 통로다. 접속하면 내 PC가 VPN Pool 대역의 주소를 하나 받는다.

언제 쓰나. Private Subnet의 서버를 만져야 하는데 그 서버에 공인 IP를 붙이고 싶지는 않을 때다. 서버를 열지 않고 내가 안으로 들어가는 방식이다.

흐름. VPN에 붙어서 Pool 주소를 받고 → 그 Pool 대역을 NACL과 ACG에 출발지로 허용해두면 → 안쪽 서버에 닿는다. 여기서도 관문 얘기로 돌아온다.

Prometheus와 Node Exporter

이날 오후에는 모니터링을 붙였다. 관리 서버에 Prometheus를 두고 워크로드 서버에 Node Exporter를 깔아서 메트릭을 긁어오는 구성이다.

무엇인가. Node Exporter는 서버 상태를 숫자로 뽑아서 9100 포트에 걸어두는 프로그램이다. Prometheus는 그걸 주기적으로 가져가는 쪽이다.

언제 쓰나. 서버가 여러 대가 됐을 때 어디가 아픈지 한 화면에서 보려고 쓴다.

여기서 Prometheus가 Pull 방식이라는 점이 중요했다. 각 서버가 데이터를 보내주는 게 아니라, Prometheus가 주기적으로 찾아가서 가져온다.

즉 이것도 방화벽 문제가 된다.

Ops Prometheus  →  Workload Node Exporter : TCP 9100

관리 서버 쪽 ACG 아웃바운드에 9100, 워크로드 서버 쪽 ACG 인바운드에 9100, 그리고 그 사이 두 Subnet의 NACL에 요청 방향과 반환 방향을 각각. Peering Route까지 포함하면 한 번의 수집을 위해 여섯 군데가 맞아야 한다.

모니터링을 붙이는 일이 결국 네트워크 설계 얘기로 돌아온다는 게 좀 의외였다. 그래프가 안 뜨면 이 여섯 군데를 다 봐야 한다는 뜻이기도 하다.

Stateful과 Stateless는 시험 문제처럼 외울 수 있는 단어다. 나도 전날 표에 적어놨다.

적어놓은 것과 아는 것은 달랐다. 규칙을 기억해주는 쪽과 기억해주지 않는 쪽이 한 경로 위에 같이 서 있는데, 어느 쪽이 어느 쪽인지 헷갈리면 헷갈린 만큼 정확히 그 자리에서 막힌다.

네이버 클라우드 심화 과정 회고 2일차 · 전체 목차로

← 이전 · 1일차 (VPC, Subnet, Route Table)

다음 · 3일차 (Docker 네트워크, Overlay) →