"보안그룹 열었는데 접속이 안 돼요." "L7 LB에서 /api만 라우팅이 안 됩니다." "인증서 체인이 끊겨서 모바일에서만 SSL 에러가 나요." "DNS 바꿨는데 일부 사용자는 옛 서버로 가요." 네트워크·보안 장애는 계층(L3/L4/L7)과 용어를 모르면 어디부터 봐야 할지조차 막막합니다. 이 사전은 네트워크·보안 용어를 빠르게 해독해 장애의 계층과 방향을 잡게 합니다. 깊은 실습은 Networking 트랙으로 연결합니다.
- 1방화벽·NAT·CIDR·서브넷으로 네트워크 접근 제어를 읽을 수 있다
- 2L4/L7 로드밸런서·헬스체크·스티키세션을 구분할 수 있다
- 3TLS/인증서 체인·키스토어로 SSL 문제를 진단할 수 있다
- 4DNS·CDN·WAF로 트래픽 경로와 웹 보안을 이해할 수 있다
접근 제어 — 방화벽·NAT·주소
확대
위 그림처럼 "접속이 안 돼요"는 DNS 계층부터 HTTP 계층까지 순서대로 좁혀야 합니다. curl -v 한 번으로 어느 계층에서 멈추는지 확인하고, 그에 맞는 도구로 원인을 파악합니다.
누가 어디로 통할 수 있는가
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| Inbound / Outbound | 들어오는 / 나가는 트래픽 | 방향별 규칙 → 인바운드/아웃바운드 포트 접속 장애 실전 디버깅 | ★★ |
| Firewall Rule / ACL / Allowlist / Denylist | 방화벽 규칙 / 접근목록 / 허용·차단 | 화이트리스트 권장 → 방화벽 정책 설계와 접근 제어 리스트(ACL) 구성 실무 | ★★ |
| NAT / SNAT / DNAT / PAT | 주소 변환(출발지/목적지/포트) | 폐쇄망 통신 → NAT 변환과 포트 포워딩(Port Forwarding) 작동 원리 | ★★ |
| CIDR / Subnet / VPC / VLAN | 주소 범위 / 서브넷 / 가상망 | /24=254호스트 → 서브넷 마스크 계산과 IP 대역 설계 실무 | ★★ |
| Route Table / Gateway | 경로표 / 출구 | 라우팅 → 라우팅 테이블(Route Table) 조회와 게이트웨이 추가/삭제 | ★★ |
| Proxy / Forward·Reverse Proxy | 대리 / 정·역방향 | 역프록시=앞단 | ★★ |
핵심: "보안그룹 열었는데 안 돼요"는 Inbound뿐 아니라 NACL·라우팅·OS 방화벽까지 계층별로 점검해야 합니다(인바운드/아웃바운드 포트 접속 장애 실전 디버깅). 사설대역(10/172.16-31/192.168)과 CIDR 계산은 서브넷 마스크 계산과 IP 대역 설계 실무.
로드밸런서 · 연결
트래픽을 나누고 유지하는 용어
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| Load Balancer / L4 / L7 | 부하 분산 / 전송계층 / 응용계층 | L7=HTTP 인식 → HAProxy 기반 L4/L7 로드밸런싱과 헬스 체크 설정 | ★★ |
| Health Check | 인스턴스 생존 확인 | 죽은 인스턴스 제외 | ★★★ |
| Sticky Session / Session Affinity | 같은 사용자=같은 서버 | 무상태면 불필요 → 12-Factor App | ★★ |
| Round Robin / Least Connection | 순환 / 최소연결 분산 알고리즘 | 분산 방식 | ★ |
| Keep-Alive / Connection Reset | 연결 재사용 / 연결 끊김 | 성능·장애 신호 | ★★ |
| TCP Handshake / TLS Handshake | TCP 3-way / TLS 협상 | 연결 수립 단계 → OSI 7계층과 TCP/IP 4계층 모델 실무적 관점 분석 | ★★ |
핵심: 헬스체크가 없으면 죽은 인스턴스로도 트래픽이 가 502가 납니다. 스티키 세션은 무상태 설계(12-Factor App)면 불필요해집니다.
TLS · 인증서
확대
위 그림처럼 Root CA → Intermediate CA → 서버 인증서 체인이 완전해야 모든 클라이언트가 검증에 성공합니다. Intermediate 인증서가 누락되면 일부 브라우저는 캐시로 통과하지만 모바일·엄격한 클라이언트는 SSL 에러가 납니다.
암호화와 신뢰의 사슬
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| SSL / TLS | 전송 암호화(TLS가 현행) | https → HTTPS/TLS 작동 원리와 curl SSL 에러 장애 디버깅 | ★★★ |
| Certificate / Private·Public Key | 인증서 / 개인·공개키 | 키 유출 주의 | ★★ |
| CSR / CA / Root·Intermediate CA / Chain Certificate | 발급요청 / 인증기관 / 체인 | 체인 끊기면 검증 실패 | ★★ |
| Truststore / Keystore | 신뢰 인증서 / 내 키·인증서 저장소 | 자바 SSL → SSL/TLS 인증서 형식 변환과 갱신 절차 | ★★ |
| mTLS | 양방향 인증서 검증 | 서비스 간 보안 | ★ |
핵심 함정: "일부 환경에서만 SSL 에러"는 보통 Intermediate 인증서 미설치(체인 끊김)입니다. 브라우저는 일부 캐싱돼 통과하지만 모바일/타 클라이언트는 검증 실패합니다. 서버에 체인 인증서를 함께 설치하세요(SSL/TLS 인증서 형식 변환과 갱신 절차).
DNS · CDN · 웹 보안
확대
위 그림처럼 트래픽은 클라이언트 → DNS → CDN/WAF → L7 로드밸런서 → WAS 순으로 흐르며, L7은 /api와 /static 경로를 구분해 WAS와 CDN으로 라우팅합니다. WAF는 이 경로에서 SQL Injection·XSS를 차단합니다.
이름 해석과 가장자리 보호
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| DNS / A·CNAME·MX·TXT Record / TTL | 이름→IP / 레코드종류 / 캐시수명 | 전환 전 TTL↓ → DNS 동작 과정과 A, CNAME, TXT 레코드 분석 | ★★ |
| DNS Propagation | DNS 변경 전파(TTL 의존) | 즉시 안 바뀜 | ★★ |
| CDN / Cache / Cache Purge | 콘텐츠 전송망 / 캐시 / 캐시삭제 | 정적 가속 → 웹방화벽 403 분석과 CDN 캐시 관리 실무 | ★★ |
| WAF / WAAP / DDoS Protection / Bot Management | 웹방화벽 / 보호 / 디도스·봇 차단 | L7 공격 차단 | ★★ |
| X-Forwarded-For / X-Real-IP | 원 클라이언트 IP 전달 헤더 | 프록시 뒤 실제 IP | ★★ |
| Referer / Origin / User-Agent | 출처·요청자 헤더 | 보안·분석 | ★ |
핵심: DNS 전환은 TTL 때문에 즉시 안 바뀝니다 — 전환 며칠 전 TTL을 낮춰두는 게 정석(DNS 동작 과정과 A, CNAME, TXT 레코드 분석). 프록시/LB 뒤에선 실제 클라이언트 IP가 X-Forwarded-For에 들어옵니다(로그·차단 시 주의).
네트워크 장애 계층 가르기 — 직접 확인
"접속이 안 돼요"를 DNS→TCP→TLS→HTTP 계층 순으로 좁힙니다.
# curl -v는 DNS 해석 → TCP 연결 → TLS 핸드셰이크 → HTTP 응답을 순서대로 보여줌
curl -v https://api.example.com/ 2>&1 | head -30
# 인증서 체인만 확인
openssl s_client -connect api.example.com:443 -showcerts < /dev/null 2>/dev/null | grep -E "s:|i:"
* Could not resolve host → DNS 문제(레코드·전파)([[dns-fundamentals]])
* Connection timed out → 방화벽/보안그룹/라우팅(L3/L4)([[aws-security-group-debug]])
* SSL certificate problem → 인증서 체인 끊김(Intermediate 미설치)
< HTTP/1.1 502 Bad Gateway → LB는 됐는데 뒷단 WAS 죽음([[glossary-observability]])
curl -v https://api.example.com/ 2>&1 | head -30- curl -v 출력에서 어디서 멈추는지가 계층을 가른다: "resolve host"=DNS, "timed out"=방화벽/라우팅(L3/4), "SSL"=인증서, "HTTP 5xx"=뒷단 앱
- "resolve host" 실패면 DNS — 레코드 존재·TTL·전파 확인(DNS 동작 과정과 A, CNAME, TXT 레코드 분석). 일부 사용자만 옛 서버면 전파 진행 중
- "connection timed out"은 보통 방화벽/보안그룹 Inbound 또는 라우팅 — 포트가 열렸는지, NACL/OS방화벽까지(인바운드/아웃바운드 포트 접속 장애 실전 디버깅)
- "SSL certificate problem"이 일부 클라이언트(모바일)만이면 Intermediate 인증서 미설치(체인 끊김) → 체인 인증서 설치(SSL/TLS 인증서 형식 변환과 갱신 절차)
상황: 데스크톱 브라우저에선 멀쩡한데 모바일 앱·일부 클라이언트에서만 SSL 인증서 에러가 납니다.
원인: Intermediate(중간) 인증서 미설치로 체인이 끊긴 것입니다. 일부 브라우저는 중간 인증서를 캐시/보완해 통과시키지만, 그렇지 않은 클라이언트는 'Root까지의 신뢰 사슬'을 못 만들어 검증에 실패합니다.
진단:
openssl s_client -connect api.example.com:443 -showcerts < /dev/null 2>/dev/null | grep -E "s:|i:"
# 서버 인증서(s:)와 발급자(i:)만 보이고 Intermediate→Root 체인이 없으면 끊김
해결: 서버에 풀체인 인증서(서버 + Intermediate) 를 설치합니다(Nginx ssl_certificate에 fullchain.pem). Let's Encrypt는 fullchain.pem을 제공합니다. 설치 후 SSL Labs 등으로 체인 완성도를 검증합니다. 깊은 인증서 운영은 SSL/TLS 인증서 형식 변환과 갱신 절차. "일부 클라이언트만 SSL 실패"는 체인 문제를 1순위로 의심하세요.
심화 — 헬스체크 통과가 '정상'을 뜻하지 않는 순간들
심화: 프록시 한 겹 뒤에서 다시 정의되는 용어들
같은 용어도 프록시·CDN 한 겹 뒤에서는 뜻이 달라집니다. 이 재정의를 놓치면 차단·제한 같은 보안 장치가 통째로 무력화됩니다.
- CDN 뒤에서 '소스 IP'는 CDN의 IP입니다: 서버·방화벽이 보는 출발지는 사용자도 공격자도 아닌 CDN/프록시입니다. 여기에 IP 차단이나 rate limit을 걸면 전체 사용자를 한 명으로 묶어 다 같이 차단되거나, 반대로 아무도 제한되지 않습니다. 실제 IP는 X-Forwarded-For에 있지만 이 헤더는 클라이언트가 위조할 수 있으므로, 신뢰하는 프록시가 붙인 마지막 값만 믿어야 합니다 — "XFF 맨 앞 값을 그대로 차단 목록에 넣는" 구현은 공격자가 헤더 한 줄로 우회합니다(웹방화벽 403 분석과 CDN 캐시 관리 실무).
- 면접 한 단계 더 — "헬스체크가 통과하는데 왜 502가 나죠?": 헬스체크는 주기적 스냅샷일 뿐입니다. 체크와 체크 사이에 죽을 수 있고, /health 경로만 살아 있고 실제 API는 죽어 있을 수 있으며(가벼운 체크의 맹점), 연결 타임아웃 경합처럼 헬스체크로는 보이지 않는 실패도 있습니다. "통과=정상"이 아니라 "통과=그 시각·그 경로가 응답함"으로 좁혀 읽는 것이 정확한 독해입니다(HAProxy 기반 L4/L7 로드밸런싱과 헬스 체크 설정).
- TTL을 낮춰도 모두가 지키진 않습니다: 일부 리졸버와 앱 런타임(JVM의 DNS 캐시 등)은 TTL을 무시하고 오래 캐시합니다. DNS 전환 후 "일부 사용자만 옛 서버"가 며칠 갈 수 있으므로, 옛 서버는 전환 직후 내리지 말고 겹침 기간 동안 양쪽을 살려 두는 것이 정석입니다(DNS 동작 과정과 A, CNAME, TXT 레코드 분석).
상황: 피크 시간마다 502 비율이 슬금슬금 오릅니다. 헬스체크는 정상, 백엔드 에러 로그도 비어 있고, 재현하려고 하면 안 됩니다 — 전형적인 '잡히지 않는 간헐 502'입니다.
원인: LB의 idle timeout(60초)이 백엔드 WAS의 keep-alive timeout(5초)보다 길었습니다. 백엔드가 유휴 연결을 먼저 닫는데 LB는 그 연결이 살아 있다고 믿고 재사용합니다 — 막 닫힌 소켓에 요청을 실어 보내는 순간 Connection Reset이 나고, 사용자에겐 502로 보입니다. 연결 재사용이 활발한 피크일수록 경합 확률이 올라 '트래픽에 비례하는 간헐 502'가 됩니다.
진단: 502가 난 요청이 백엔드 액세스 로그에 아예 없는지(도달 전 실패) 확인하고, LB 로그의 업스트림 종료 사유(reset/close)를 본 뒤, 양쪽의 keep-alive/idle timeout 설정을 나란히 비교합니다. '백엔드 로그에 없는 502'가 결정적 증거입니다.
grep keepalive_timeout /etc/nginx/nginx.conf # 예: 5s — LB idle timeout(60s)보다 짧다
해결: 유휴 연결을 먼저 끊는 쪽이 뒤쪽(백엔드)이 되지 않도록, 백엔드의 keep-alive timeout을 LB idle timeout보다 길게(예: LB 60초면 백엔드 75초) 잡습니다. 멱등 요청은 LB 재시도로 이중 방어합니다. 교훈은 Keep-Alive가 성능 옵션이 아니라 두 장비 사이의 시간 약속이라는 것 — 한쪽만 아는 약속은 간헐 장애로 돌아옵니다. 502율과 reset 수는 지표로 상시 감시합니다(용어사전).
인프라/SRE에게 네트워크·보안 용어는 장애 트리아지의 좌표계입니다 — curl -v 한 번으로 DNS/TCP/TLS/HTTP 중 어느 계층인지 가르고(OSI 7계층과 TCP/IP 4계층 모델 실무적 관점 분석), 그에 맞는 도구(dig·openssl·ss)로 깊이 들어갑니다. 깊은 실습은 Networking 트랙에 있습니다. PM은 이 용어로 "접속이 안 돼요"라는 모호한 보고를 "DNS 전파 중 / 인증서 체인 / 보안그룹"으로 좁혀, 정확한 담당과 대응으로 연결합니다. 특히 도메인 전환·인증서 갱신은 일정에 TTL·체인 검증을 미리 넣어야 사고를 막습니다.
다음 용어사전에서는 컨테이너·쿠버네티스·클라우드 네이티브 용어를 정리합니다.
용어 식별 실습으로 굳히기: 용어 식별 — 네트워크 / 보안 — 증상을 보고 방화벽·L4/L7·TLS·DNS 용어를 가려내고 원인 위치를 구분합니다.