SOA-C03 15/16 — 네트워크 문제 해결과 증거 해석
정보보안기사 응시 후 학습을 위해 미리 작성한 본문이다. 작성·보존은 대화 전달이나 학습 완료를 뜻하지 않는다.
1. 실패한 요청을 재현 가능한 좌표로 고정한다
네트워크 장애라는 표현만으로는 조사 범위가 너무 넓다. 먼저 누가 어디서 어떤 이름·주소·포트에 언제 접속했으며 어떤 오류를 받았는지 적는다. 정상 요청 하나를 비교 대상으로 확보하면 account·AZ·subnet·client network·배포 version 중 다른 조건을 좁힐 수 있다.
이름 해석
→ 목적지 route
→ 요청 방향 filter·middlebox
→ listener·target
→ application·dependency
→ 응답 route·filterTimeout, connection refused, TLS error, HTTP 403, HTTP 502는 관찰된 실패 단계가 다르다. HTTP status를 받았다면 어떤 HTTP endpoint가 답했다는 근거지만, 그 답변이 origin에서 왔는지 CloudFront·WAF·ALB에서 왔는지는 추가 확인해야 한다.
2. VPC 설정은 실제 연결된 자원에서 읽는다
콘솔에 비슷한 이름의 route table이 있다는 사실보다 실패 ENI가 속한 subnet과 그 subnet의 실제 연결을 확인한다. Longest-prefix 등 route 선택과 blackhole·삭제된 target, 겹치는 주소 범위, 요청·응답의 비대칭을 조사한다.
Reachability Analyzer는 구성 모델을 분석해 지원하는 source·destination 경로와 차단 요소를 보여 준다. 실제 packet을 보내거나 guest OS·프로세스 상태를 시험하는 도구는 아니다. Reachable 결과 뒤에도 listener·TLS·애플리케이션 동작은 별도로 확인한다. Reachability Analyzer 동작
이 분석은 “어느 SG·NACL·route 구성이 막는가”를 좁히는 데 적합하다. 손실·간헐적 지연처럼 시간에 따라 달라지는 문제에는 실제 로그·지표·probe를 연결한다.
3. Transit Gateway의 association과 propagation을 구분한다
VPC subnet의 route table과 TGW route table은 다른 표다. Subnet route가 TGW를 가리켜도 TGW 안에서 다음 attachment로 갈 경로가 없으면 전달되지 않는다.
- Association: 해당 attachment에서 들어온 트래픽에 어떤 TGW route table을 적용할지 정한다.
- Propagation: attachment의 경로 정보를 어떤 TGW route table에 넣을지 정한다.
- Static route·blackhole: 명시적으로 정한 경로나 차단을 확인한다.
- Return path: 반대 attachment에서 돌아올 때 적용되는 route table도 확인한다.
예를 들어 VPC A의 CIDR을 B가 사용하는 TGW route table에 전파했다고 A에서 B로 가는 모든 경로까지 자동 완성되는 것은 아니다. A의 ingress attachment가 사용하는 표의 B 경로, B subnet의 A 경로, 반대 방향 TGW 표를 각각 대조한다.
Hybrid 연결에서는 VPN tunnel·BGP 또는 static route, Direct Connect의 연결·virtual interface·routing 상태와 고객 측 router를 확인한다. 물리 연결 또는 tunnel이 up인 상태와 원하는 prefix가 양방향으로 전달되는 상태는 별개다. 사설 연결도 DNS forwarding이나 애플리케이션 권한을 자동 구성하지 않는다.
4. NAT 장애는 route와 연결 자원 압력을 함께 본다
외부 호출이 일부 대상이나 높은 동시성에서만 실패하면 NAT의 연결 지표를 확인한다. ErrorPortAllocation은 source port 할당 실패를 나타낸다. PacketsDropCount, 연결 시도·성립, idle timeout 같은 지표를 같은 NAT ID와 시간 구간에서 비교한다. NAT metrics
Port allocation 오류는 목적지별 연결 집중·연결 재사용·동시성·지원 주소 구성과 연결해 조사한다. 모든 timeout을 NAT 용량 부족으로 단정하거나 instance CPU를 늘리는 것으로 해결하려 하지 않는다.
SG는 stateful이어도 NACL의 응답 포트, 중간 방화벽의 idle timeout, client의 connection pool이 정상인지는 따로 확인한다. NAT metric의 변화는 가설을 지지하는 근거이며 최종 외부 API 성공률로 조치 효과를 확인한다.
5. Flow Logs는 IP 흐름의 메타데이터다
VPC Flow Logs는 ENI를 오가는 IP 트래픽 정보를 기록한다. Packet payload·HTTP body를 그대로 보여 주는 packet capture가 아니다. VPC·subnet·ENI 수집 범위와 log destination을 먼저 확인한다. Flow Logs
| 필드·상태 | 읽는 방법 |
|---|---|
| interface-id | 어떤 ENI에서 관찰했는가 |
| srcaddr·dstaddr·port·protocol | 해당 관찰 지점의 흐름 좌표 |
| start·end | 집계된 관찰 시간 |
| packets·bytes | 관찰한 흐름의 규모 |
| ACCEPT·REJECT | 해당 네트워크 필터 경계의 허용·거부 |
| NODATA·SKIPDATA | 트래픽 없음 또는 일부 기록 생략 상태 |
ACCEPT는 애플리케이션이 요청을 처리했다는 뜻이 아니다. REJECT도 그 한 줄만으로 정확한 SG rule ID를 확정하는 근거는 아니다. NAT 등 중간 계층을 통과한 원래 주소를 조사하려면 지원되는 packet-level address 필드와 관찰 위치를 함께 해석한다. Flow log records
Flow Logs에는 수집되지 않는 트래픽 종류가 있고 전달 지연·기록 누락 가능성도 있다. Amazon DNS로 향한 질의는 DNS 로그로 별도 확인한다. 기록이 없을 때는 “요청이 없었다”와 “수집 범위·전달·제한 때문에 안 보인다”를 구분한다. Flow log 제한
6. HTTP와 container 로그를 원천별로 연결한다
| 원천 | 주된 질문 | 확인할 값 |
|---|---|---|
| ALB access log | LB가 받았고 target에 전달했는가 | elb·target status, target 주소, 처리 시간 |
| WAF web ACL log | 어떤 rule·action이 요청을 처리했는가 | terminating rule, action, request 맥락 |
| CloudFront log | edge에서 어떤 결과가 나왔는가 | status·result type·URI·edge·request 식별자 |
| Container·app log | 프로세스가 어떤 결과를 만들었는가 | task·pod·version·request ID·dependency 오류 |
ALB의 elb_status_code와 target_status_code를 구분한다. Target가 응답하지 않은 경우와 target가 오류를 반환한 경우의 조치가 달라진다. Request·target·response 처리 시간의 의미를 읽고 동일 요청의 app log와 맞춘다. ALB access logs
WAF는 web ACL 연결·logging 설정·filter가 맞아야 조사할 요청이 보인다. Count는 관찰이고 Block은 차단이다. HTTP 403이라는 이유만으로 WAF가 차단했다고 단정하지 않고 실제 action과 rule을 확인한다. WAF logging
CloudFront standard log와 real-time log는 수집·전달 특성이 다르다. 로그 설정·필드·전달 시간을 확인한 뒤 cache 결과와 origin 오류를 나눈다. CloudFront logs
ECS의 awslogs driver는 container의 stdout·stderr 등을 CloudWatch Logs로 보내는 구성이다. Log group·stream·실행 권한·task definition과 app의 실제 출력 위치를 확인한다. Container가 실행 중인데 로그가 없다는 현상만으로 처리 성공이나 요청 부재를 판단하지 않는다. ECS logs
7. Cache 문제와 네트워크 문제를 분리한다
Origin에서 새 파일이 보이는데 edge에서는 이전 파일이 보이면 DNS·연결 장애만 조사하지 않는다. Behavior path pattern, cache key, TTL, 응답 헤더, origin request policy와 invalidation 상태를 확인한다.
Cache miss가 늘었다면 무작위 query string이나 불필요한 header가 key를 늘렸는지 본다. 특정 사용자에게 잘못된 응답이 전달되면 사용자별 응답의 재사용 경계가 틀렸는지 먼저 확인한다. 14의 cache 정책을 바꾼 뒤 정확성·hit rate·origin 부하를 함께 검증한다. 단순 invalidation은 잘못된 cache key 자체를 수정하지 않는다.
8. CloudWatch network monitoring은 관찰 범위로 고른다
| 서비스 | 관찰 방법·범위 | 구성 시작점 |
|---|---|---|
| Network Flow Monitor | 지원 workload의 TCP 연결 성능 통계 | 필요한 agent·scope·monitor |
| Internet Monitor | AWS 앱과 인터넷 사용자 사이 성능·가용성 | 지원 resource·traffic 범위 |
| Network Synthetic Monitor | AWS와 온프레미스 목적지의 probe 측정 | source·destination·protocol·probe |
현재 문서의 Network Synthetic Monitor는 이전 Network Monitor 명칭 자료와 연결해 읽는다. Flow Monitor의 성능 통계를 VPC Flow Logs의 ACCEPT/REJECT 기록과 혼동하지 않는다. CloudWatch Network Monitoring
Monitor 생성 뒤에는 대상과 실제 측정값, packet loss·latency 기준선, health event·alarm의 수집 여부를 확인한다. 모든 인터넷 사용자를 동일하게 관찰한다고 가정하지 말고 선택한 resource·지역·트래픽 범위를 명시한다.
9. 완성된 운영 적용 — 사내에서만 private API가 timeout
- 사내 client와 VPC 안의 정상 client에서 같은 hostname·port를 비교한다.
- 사내 DNS가 올바른 inbound Resolver endpoint로 전달하는지 본다.
- DNS 응답의 private IP가 기대한 서비스인지 확인한다.
- VPN·DX·TGW·subnet의 요청·응답 route를 대조한다.
- Flow Logs와 중간 firewall 로그로 차단 범위를 좁힌다.
- ALB·container 로그가 있으면 요청 도달 이후 실패를 조사한다.
- 발견한 최소 구성 문제를 수정하고 사내 client에서 실제 TLS·API 응답을 확인한다.
- 같은 경로의 probe와 사용자 오류 추세가 회복했는지 확인한다.
시험에서는 로그와 도구를 실패 계층에 맞게 선택한다. 운영에서는 구성상 도달 가능성, 실제 네트워크 연결, 사용자 기능의 성공을 별도 증거로 확인한다. 범위: Domain 5 Task 5.3.
계획과 연결
-
ID:
15-network-troubleshooting-and-evidence -
의존:
02-collection-alarms-dashboards-notifications,13-vpc-connectivity-protection-and-cost,14-dns-routing-and-content-delivery -
결정 축: 이름 해석부터 route·stateful/stateless filter·middlebox·target·application까지 hop을 따라가며 각 계층의 로그와 모니터링 결과를 해석한다.
-
범위: VPC configuration, transit gateway·NAT gateway, VPC Flow Logs, ELB access logs, WAF web ACL logs, CloudFront logs, container logs, CloudFront cache issues, hybrid·private connectivity, CloudWatch network monitoring services.
-
시험 매핑: Domain 5, Task 5.3.