새 API 서비스를 로드밸런서 뒤에 붙이면서, 로드밸런서가 서버로 보낼 때 쓰는 SNAT 대역(10.40.9.0/28)에서 8080 포트를 허용하는 방화벽 규칙을 추가했습니다. 그런데 풀 멤버가 모두 DOWN이고 헬스 체크가 계속 시간 초과입니다. 규칙 문장은 두 사람이 함께 확인했습니다. 이 방화벽에는 몇 년 전 실험실 대역(10.40.0.0/16)을 막으려고 넣어 둔 규칙이 남아 있습니다. 담당자는 서버의 앱이 8080을 안 연 것 같다며 개발팀을 호출했습니다.
방화벽 규칙을 추가했는데 로드밸런서 헬스 체크만 계속 막힘
새 API 서비스를 로드밸런서 뒤에 붙이면서, 로드밸런서가 서버로 보낼 때 쓰는 SNAT 대역(10.40.9.0/28)에서 8080 포트를 허용하는 방화벽 규칙을 추가했습니다.
시나리오
단서
seq 20 deny ip 10.40.0.0/16 any (hits 18,442) # legacy lab seq 30 permit tcp 10.40.9.0/28 10.60.2.0/24 8080 (hits 0) # api health/traffic seq 999 deny ip any any
$ ss -ltn | grep 8080 LISTEN 0 511 0.0.0.0:8080 0.0.0.0:* $ curl -s localhost:8080/health OK
과제 원인을 좁히고, 서비스를 되살리는 순서(검증 포함)와 재발 방지책을 적어 보세요.
구독하면 이어서 볼 수 있어요
이 문제의 전체 시나리오와 점검 체크리스트, 복구 순서, 모범 풀이는 Pro 구독에서 열립니다.
먼저 볼 것
- 규칙이 위에서부터 평가된다는 점
- SNAT 뒤 출발지 IP가 무엇인지
점검 체크리스트
- 규칙별 적중 수(hit count)
- 허용 규칙보다 위에 같은 출발지를 막는 규칙이 있는지
- 서버가 포트를 열고 있는지(ss -ltn)
복구와 재발 방지
같이 보면 좋은 질문
현장에서 본 비슷한 케이스
0/10