서버는 외부 API를 호출해야 하는데 운영망에서는 모든 요청이 타임아웃됩니다. 인바운드 방화벽은 열려 있었지만 아웃바운드 정책과 프록시 설정은 아무도 확인하지 않았습니다.
서버 통신은 들어오는 길만큼 나가는 길도 중요합니다. curl과 wget으로 출구를 증명해야 합니다.
아웃바운드 통신 점검 (wget / curl)
서버가 외부 인터넷에 연결되지 않으면 패키지 설치, 업데이트, 외부 API 호출이 모두 실패합니다.
이 챕터에서는 아웃바운드 통신의 개념을 이해하고, curl과 wget으로 직접 점검하는 방법을 익힙니다.
1. 인바운드 vs 아웃바운드 방향 이해
- 1인바운드(Inbound)와 아웃바운드(Outbound) 트래픽 방향의 차이를 설명할 수 있다
- 2curl 주요 옵션으로 HTTP/HTTPS 아웃바운드 통신을 점검할 수 있다
- 3wget으로 파일을 다운로드하고 curl과의 용도를 비교할 수 있다
- 4방화벽 DROP 시 타임아웃 증상과 즉각적 Connection Refused의 차이를 구분할 수 있다
- 5사내 프록시 설정을 확인하고 yum/apt 패키지 설치 실패를 단계별로 진단할 수 있다
- 6폐쇄망(Air-Gapped) 환경에서 오프라인 패키지 설치 방법을 적용할 수 있다
nslookup google.comcurl -o /dev/null -s -w "%{http_code}" --connect-timeout 5 https://example.comenv | grep -i proxy트래픽 방향: 인바운드(Inbound) vs 아웃바운드(Outbound)
배포 서버에서 외부 결제 API 호출이 안 됩니다. 포트도 열었고 DNS도 됩니다. 방화벽 설정을 확인하는데, 인바운드 규칙만 잔뜩 있고 아웃바운드를 막고 있는지 확인조차 안 해봤습니다. 인바운드와 아웃바운드의 방향 개념을 명확히 이해하지 못하면 방화벽 진단에서 절반은 놓치게 됩니다.
네트워크 통신은 방향을 기준으로 두 가지로 나뉩니다.
| 구분 | 방향 | 대표 예시 |
|---|---|---|
| 인바운드 (Inbound) | 외부 → 서버 | 사용자가 웹 브라우저로 서버에 접속 |
| 아웃바운드 (Outbound) | 서버 → 외부 | 서버가 yum/apt로 패키지 다운로드 |
확대
왜 구분이 중요한가?
방화벽 정책은 방향별로 독립적으로 설정됩니다. 인바운드 80 포트가 열려 있어도, 아웃바운드 443이 막혀 있으면 서버에서 외부 HTTPS 요청은 불가능합니다.
보안 강화를 위해 아웃바운드를 기본 차단(deny)하고 필요한 IP/포트만 허용하는 화이트리스트 방식을 많이 사용합니다.
폐쇄망(Air-Gapped Network)
금융, 공공, 국방 환경에서는 서버가 인터넷과 완전히 단절된 폐쇄망에 배포됩니다. 이 경우:
yum install nginx→ 미러 서버 접근 불가 → 실패curl https://api.example.com→ 타임아웃- 내부 패키지 저장소(로컬 mirror)나 오프라인 설치 패키지를 별도 준비해야 합니다
나가는 연결이 어디서 막히는가 — 아웃바운드 패킷의 여정과 timeout 위치 특정
아웃바운드가 안 될 때 "방화벽이 막았다"고 뭉뚱그리면 고칠 수 없습니다. 나가는 연결은 DNS 해석 → 로컬 아웃바운드 방화벽 → 경로 중간 장비 → 목적지 인바운드 → 응답이라는 여러 관문을 지나고, 각 관문은 실패 증상이 다릅니다. 이 여정을 알면 timeout이 어느 방화벽에서 났는지 짚어낼 수 있습니다.
[앱] connect() → api.payment.com:443
│
① DNS 이름 해석: 도메인 → IP (안 되면 여기서 즉시 실패)
│
② 로컬 아웃바운드 방화벽(egress) 평가
│ iptables OUTPUT · firewalld · 보안그룹 아웃바운드 규칙
│ 차단 시 SYN이 나가지 못하거나 조용히 폐기 → timeout
│
③ 게이트웨이 / NAT / 사내 방화벽·프록시
│ 경로 중간 장비가 나가는 연결을 막을 수 있음
│
④ 목적지 방화벽(인바운드) 도달
│ 상대 서버의 443 인바운드가 열려 있어야 함
│
⑤ 목적지 서비스 응답 → 되돌아오는 경로로 수신
▼
[모두 통과 시] 연결 성립 (200 OK)
각 단계에서 무슨 일이 일어나고, 막히면 어떤 증상·어느 방화벽인가:
| 단계 | 하는 일 | 여기서 막히면 |
|---|---|---|
| ① DNS 해석 | 도메인을 IP로 변환해야 연결을 시작할 수 있음 | curl: (6) Could not resolve host가 즉시 반환(타임아웃 아님) → resolv.conf·53/UDP 차단 확인 |
| ② 로컬 egress | 서버 자신의 아웃바운드 규칙을 통과해야 SYN이 나감 | curl -v가 IP 연결 시도(Trying) 줄에서 멈춰 timeout / nc -zv -w3도 timeout → 로컬 방화벽·보안그룹 아웃바운드 |
| ③ 경로 중간 | 게이트웨이·사내 방화벽·프록시 구간을 지남 | 로컬은 통과인데 중간에서 DROP → traceroute -T -p 443으로 어느 홉에서 멈추는지 / 프록시 필수 망이면 직접 연결만 timeout |
| ④ 목적지 인바운드 | 상대 서버의 목적 포트가 열려 있어야 도달 | 여기서 거부면 대개 Connection refused(timeout 아님) → 상대 포트 미개방·서비스 다운(아웃바운드 차단과 구분) |
| ⑤ 응답 수신 | 목적지 응답이 되돌아오는 경로로 들어옴 | 비대칭 경로·응답 차단이면 요청은 갔는데 응답만 안 옴(드묾) → 경로·conntrack 확인 |
즉 timeout이 나면 **"어느 관문에서 죽었나"**를 증상으로 가릅니다. DNS 실패는 즉시 6번 에러라 구분되고, 로컬 egress 차단은 curl -v가 Trying 줄에서 멈추며 nc -zv도 timeout입니다. Connection refused는 목적지 포트 문제지 아웃바운드 차단이 아닙니다. traceroute -T -p 443으로 어느 홉까지 가는지 보면 로컬(②)인지 경로 중간(③)인지 목적지(④)인지 갈립니다. 핵심은 "무응답 timeout = egress 의심, 즉시 refused = 목적지 포트"를 먼저 가르는 것입니다.
2. curl로 아웃바운드 통신 점검
curl 주요 옵션과 아웃바운드 점검 패턴
외부 API가 안 된다고 할 때 "curl로 직접 쳐봐" 라는 말을 듣습니다. 그런데 curl <url> 외에 어떤 옵션을 어떻게 써야 응답 코드만 보는지, 타임아웃을 설정하는지, 헤더를 붙이는지 모릅니다. 아웃바운드 점검에 자주 쓰이는 옵션을 익혀두면 장애 상황에서 즉시 꺼낼 수 있습니다.
확대
curl은 HTTP뿐 아니라 FTP, SMTP 등 다양한 프로토콜을 지원하는
범용 전송 도구입니다. 아웃바운드 점검에 자주 쓰이는 옵션을 정리합니다.
# 실습 디렉토리 준비
mkdir -p /tmp/networking/part4/exam_20 && cd /tmp/networking/part4/exam_20
# 기본 GET 요청 — HTML 본문 출력
curl https://example.com
# 파일 다운로드 — 원격 파일명 그대로 저장
curl -O https://repo.example.com/package-1.0.tar.gz
# 파일 다운로드 — 저장 파일명 지정
curl -o mypackage.tar.gz https://repo.example.com/package-1.0.tar.gz
# HTTP 헤더만 확인 (HEAD 요청)
curl -I https://example.com
# 응답 코드만 확인 (스크립트에서 유용)
curl -o /dev/null -s -w "%{http_code}\n" https://example.com
# 연결 타임아웃 5초, 최대 응답 대기 10초
curl --connect-timeout 5 --max-time 10 https://example.com
# 프록시를 통해 요청
curl -x http://proxy.company.com:3128 https://example.com
# SSL 인증서 검증 무시 (폐쇄망 내부 CA 환경)
curl -k https://internal.example.com
# 상세한 연결 과정 출력 (디버깅)
curl -v https://example.com
- curl 실패 시 에러 메시지를 먼저 확인 — "(6) Could not resolve host"이면 DNS 문제, "(28) timed out"이면 방화벽 DROP, "(7) Connection refused"이면 상대 서버 포트 미오픈
- %{http_code} 출력 기준: 200~399는 성공, 000은 연결 자체 실패(타임아웃/DNS 오류), 5xx는 서버 도달했으나 서버 내부 오류
- DNS 해석 성공 + nc 타임아웃 → 아웃바운드 방화벽 DROP; DNS 해석 성공 + nc 즉각 거부 → 상대 서버에 해당 포트 미오픈; DNS 해석 실패 → /etc/resolv.conf 또는 방화벽의 53/UDP 차단 확인
아웃바운드 점검 시 해석 포인트 — 결과 유형별로 원인과 조치가 달라집니다.
# 성공 케이스 — HTML 또는 파일 내용이 출력됨
<!DOCTYPE html>...
# DNS 실패
curl: (6) Could not resolve host: example.com
→ /etc/resolv.conf 또는 DNS 서버 점검 필요
# 연결 타임아웃 (방화벽 DROP)
curl: (28) Connection timed out after 30001 milliseconds
→ 아웃바운드 방화벽에서 패킷을 차단 중
# 연결 거부 (포트 닫힘 or 프로세스 없음)
curl: (7) Failed to connect to example.com port 443: Connection refused
→ 상대 서버에서 해당 포트가 열려 있지 않음
3. wget으로 파일 다운로드
wget 사용법과 curl과의 차이
서버에서 파일을 다운로드해야 하는데 curl로 해야 하는지 wget으로 해야 하는지 모릅니다. 그리고 어떤 서버에는 curl이 없고 wget만 있는 경우도 있습니다. 두 도구의 차이를 알면 상황에 맞는 도구를 바로 선택할 수 있습니다.
확대
wget은 파일 다운로드에 특화된 도구입니다.
재시도, 재귀 다운로드, 백그라운드 실행 등 다운로드에 특화된 기능을 제공합니다.
# 기본 다운로드 — 현재 디렉터리에 파일명으로 저장
wget http://repo.example.com/package.rpm
# 저장 파일명 지정
wget -O custom-name.rpm http://repo.example.com/package.rpm
# 백그라운드 다운로드 (로그는 wget-log에 저장)
wget -b http://repo.example.com/large-file.tar.gz
# 실패 시 재시도 횟수 지정 (기본 20회)
wget --tries=3 http://repo.example.com/package.rpm
# 타임아웃 설정 (초)
wget --timeout=10 http://repo.example.com/package.rpm
# 프록시 사용
wget -e "http_proxy=http://proxy.company.com:3128" http://repo.example.com/file
# 아웃바운드 점검용 — 응답 헤더만 확인
wget --spider http://example.com
# SSL 인증서 검증 무시
wget --no-check-certificate https://internal.example.com/file
curl vs wget 선택 기준 — 두 도구의 차이를 알면 상황에 맞게 선택할 수 있습니다.
| 상황 | 추천 도구 |
|---|---|
| REST API 호출, 헤더 조작, POST 요청 | curl |
| 단순 파일 다운로드, 재시도 자동화 | wget |
| 스크립트에서 HTTP 응답 코드 확인 | curl |
| 대용량 파일 백그라운드 다운로드 | wget |
| FTP/SFTP/SCP 전송 | curl |
4. 실습: 아웃바운드 통신 단계별 점검
아웃바운드 통신 실패의 첫 번째 원인은 DNS 해석 실패입니다. 도메인 이름이 IP로 변환되지 않으면 아무것도 할 수 없습니다.
# DNS 해석 테스트
nslookup google.com
dig google.com
# 직접 IP로 연결 테스트 (DNS 우회)
curl -v --connect-timeout 5 https://8.8.8.8
# /etc/resolv.conf 확인
cat /etc/resolv.conf
# nameserver 8.8.8.8 이 있어야 외부 DNS 해석 가능
# 폐쇄망이라면 내부 DNS 서버 IP가 설정되어 있을 것
# nameserver 192.168.1.53 ← 내부 DNS
결과 해석 — 출력 메시지로 방화벽 차단 여부를 판단합니다.
# DNS 정상
nslookup google.com
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: google.com
Address: 142.250.196.110 ← IP 반환 = DNS 정상
# DNS 실패
;; connection timed out; no servers could be reached
→ nameserver에 도달 불가 → resolv.conf 점검
DNS가 정상이라면 실제 80(HTTP), 443(HTTPS) 포트로 나가는 아웃바운드 통신이 허용되어 있는지 확인합니다.
# 443 포트 아웃바운드 통신 점검
curl -v --connect-timeout 5 https://example.com
# 80 포트 아웃바운드 통신 점검
curl -v --connect-timeout 5 http://example.com
# nc로 포트 통신만 확인 (응답 내용 불필요 시)
nc -zv -w 3 example.com 443
nc -zv -w 3 example.com 80
# 결과 예시 (성공)
# Connection to example.com 443 port [tcp/https] succeeded!
# 결과 예시 (타임아웃 — 방화벽 DROP)
# nc: connect to example.com port 443 (tcp) timed out: Operation now in progress
타임아웃 시간 단축 팁
기본 curl은 타임아웃이 30초 이상입니다.
--connect-timeout 5로 짧게 설정하면 점검 시간을 단축할 수 있습니다.
# 빠른 아웃바운드 점검 원라이너
curl -o /dev/null -s -w "%{http_code}" --connect-timeout 5 https://example.com
# 200 → 성공, 000 → 연결 실패(타임아웃 or DNS 실패)
사내망에서는 인터넷 접근이 프록시 서버를 통해서만 허용되는 경우가 많습니다. 이 경우 프록시 설정 없이는 직접 아웃바운드가 차단됩니다.
# 환경 변수로 프록시 설정 확인
env | grep -i proxy
# http_proxy=http://proxy.company.com:3128
# https_proxy=http://proxy.company.com:3128
# 프록시 설정이 없다면 직접 지정해서 테스트
curl -x http://proxy.company.com:3128 https://example.com
# yum 프록시 설정 (/etc/yum.conf)
grep proxy /etc/yum.conf
# proxy=http://proxy.company.com:3128
# apt 프록시 설정 (/etc/apt/apt.conf.d/proxy.conf)
cat /etc/apt/apt.conf.d/proxy.conf
# Acquire::http::Proxy "http://proxy.company.com:3128";
# Acquire::https::Proxy "http://proxy.company.com:3128";
# 시스템 전체 프록시 설정 (/etc/environment)
cat /etc/environment
프록시 설정 예시 (영구 적용) — 환경변수로 프록시를 설정하면 모든 명령어에 자동 적용됩니다.
이 명령은 시스템 설정 파일을 변경합니다. 기존 파일 백업과 적용 후 검증 방법을 준비하지 않으면 재부팅이나 서비스 재시작 때 장애가 반복될 수 있습니다.
# /etc/profile.d/proxy.sh 파일 생성
cat > /etc/profile.d/proxy.sh << 'EOF'
export http_proxy=http://proxy.company.com:3128
export https_proxy=http://proxy.company.com:3128
export no_proxy=localhost,127.0.0.1,192.168.0.0/16,.company.com
EOF
# 적용
source /etc/profile.d/proxy.sh
패키지 설치 실패는 아웃바운드 문제의 가장 흔한 증상입니다. 단계별로 좁혀나가는 방법을 익힙니다.
# [STEP 1] yum install 실패 증상 확인
yum install -y nginx
# 오류 예시:
# Could not retrieve mirrorlist http://mirrorlist.centos.org/...
# Error: Cannot retrieve repository metadata
# [STEP 2] DNS 해석 확인
nslookup mirrorlist.centos.org
# 실패 → /etc/resolv.conf 수정
# 성공 → 다음 단계로
# [STEP 3] 80/443 아웃바운드 직접 점검
curl -v --connect-timeout 5 http://mirrorlist.centos.org
# 타임아웃 → 아웃바운드 방화벽 차단 → 방화벽 정책 신청
# 응답 → 다음 단계로
# [STEP 4] yum 프록시 설정 확인
grep -i proxy /etc/yum.conf /etc/yum.repos.d/*.repo 2>/dev/null
# [STEP 5] yum 디버그 모드로 상세 오류 확인
yum install -y nginx -v 2>&1 | head -50
# [STEP 6] 폐쇄망 환경이라면 로컬 저장소 사용
# /etc/yum.repos.d/local.repo 파일을 내부 미러로 설정
5. 장애 사례 분석
외부 결제 API 연동 장애와 443 방화벽 오픈 검증
실무 아키텍처 환경에서 신규 서버를 구축하고 외부 결제 게이트웨이(PG) API인 api.payment.com:443 서버와 연동하는 상황을 상상해 보십시오.
어플리케이션 로그에 Connection Timeout 에러가 떨어지면 SRE는 아래 순서로 외부 아웃바운드 포트가 오픈되어 있는지 즉각 격리 점검해야 합니다.
# 1. 443 결제 포트 아웃바운드 통신 상태 확인 (가장 확실함)
$ nc -zv api.payment.com 443
Connection to api.payment.com 443 port [tcp/https] succeeded!
# 2. curl로 L7 SSL/TLS 핸드셰이크 수준까지 최종 검증
$ curl --connect-timeout 5 -I https://api.payment.com
HTTP/2 200 OK ...
만약 nc가 Connection timed out을 뱉는다면 사내 보안실 방화벽 정책 상 외부 도메인 api.payment.com:443 으로 나가는 아웃바운드 화이트리스트 정책이 누락된 것이 명백한 원인입니다.
증상 — 아래는 방화벽 DROP 시 나타나는 전형적인 타임아웃 패턴입니다.
curl https://api.external.com/data
# 커서만 깜박이고 30초 이상 아무 응답 없음
# 결국:
# curl: (28) Connection timed out after 30001 milliseconds
원인 분석
방화벽이 패킷을 DROP(폐기) 하고 있습니다. REJECT였다면 즉시 "Connection refused"가 반환됩니다. DROP은 패킷을 조용히 버리기 때문에 클라이언트는 응답을 기다리다 타임아웃됩니다.
즉, 서버 → 방화벽 → ✗ DROP에서 패킷이 소멸하고, 응답이 없어 클라이언트는 타임아웃까지 대기하게 됩니다.
해결 방법 — 타임아웃을 줄여 빠르게 확인하고, 담당자에게 아웃바운드 허용을 요청합니다.
# 1. 타임아웃을 짧게 설정해 빠르게 확인
curl --connect-timeout 3 https://api.external.com/data
# 2. 네트워크 방화벽 정책 담당자에게 아웃바운드 허용 요청
# - 출발지: 서버 IP
# - 목적지: api.external.com (IP 확인 후)
# - 포트: 443/TCP
# - 방향: 아웃바운드
# 3. traceroute로 어디서 막히는지 확인
traceroute -T -p 443 api.external.com
교훈: 타임아웃은 방화벽 DROP의 전형적인 증상입니다. 즉각적인 응답(Connection refused, Connection reset)과 구분하세요.
증상 — 내부 CA 인증서가 시스템에 등록되지 않아 SSL 검증 실패가 발생합니다.
curl https://internal-repo.company.com/packages/nginx.rpm
# curl: (60) SSL certificate problem: unable to get local issuer certificate
# More details here: https://curl.se/docs/sslcerts.html
원인 분석
회사 내부 CA(Certificate Authority)가 발급한 인증서를 사용하는 서버에 접근할 때, 시스템에 해당 CA 인증서가 등록되어 있지 않으면 발생합니다.
curl → HTTPS 연결 시도 → 서버 인증서 검증 →
CA 체인 확인 → 알 수 없는 CA → SSL 오류
해결 방법 — 임시 -k 우회 후 CA 인증서를 시스템에 정식 등록합니다.
# 임시 해결 — SSL 검증 무시 (-k 또는 --insecure)
curl -k https://internal-repo.company.com/packages/nginx.rpm
# 영구 해결 — 내부 CA 인증서 시스템에 등록
# CentOS/RHEL
cp company-ca.crt /etc/pki/ca-trust/source/anchors/
update-ca-trust
# Ubuntu/Debian
cp company-ca.crt /usr/local/share/ca-certificates/
update-ca-certificates
# 등록 후 -k 없이 정상 동작 확인
curl https://internal-repo.company.com/packages/nginx.rpm
주의: -k 옵션은 임시 테스트에만 사용하고,
프로덕션 스크립트에서는 CA 인증서를 정식 등록 후 제거하세요.
심화 — '도메인은 허용했는데' 가끔 막히는 아웃바운드
심화: FQDN egress와 DNS 회전 — 간헐적 아웃바운드 차단의 정체
방화벽에 api.payment.com을 분명히 허용받았는데도 열에 한두 번씩 타임아웃이 난다면, 항상 되거나 항상 안 되는 DROP/REJECT로는 설명되지 않습니다. '도메인 허용'이 실제로 어떤 규칙으로 바뀌는지 알아야 이 간헐 장애의 정체가 보입니다.
- 방화벽은 결국 IP로 막습니다: 많은 egress 방화벽·보안그룹은 도메인을 규칙에 그대로 넣지 못하고, 도메인을 한 번 resolve해 얻은 IP(들)를 허용 목록에 넣습니다. 즉 도메인 자체가 아니라 '그 순간의 IP 집합'을 허용한 것입니다.
- 외부 API의 IP는 회전합니다: 결제·클라우드 API는 대개 CDN·로드밸런서 뒤에 있어 DNS가 여러 IP를 라운드로빈으로 주고, TTL이 짧아(수십 초~수 분) 시간에 따라 반환 IP가 바뀝니다. 방화벽이 캐시한 IP 집합과 앱이 지금 접속하려는 IP가 어긋나는 순간, 그 연결만 조용히 막힙니다.
- 그래서 증상이 '간헐적'입니다: 앱의 DNS 캐시와 방화벽의 IP 스냅샷이 서로 다른 타이밍에 갱신되므로, 어떤 요청은 허용된 IP로, 어떤 요청은 목록에 없는 IP로 나갑니다 — 재시도하면 되기도 합니다. 항상 실패하는 DROP과 뚜렷이 구분되는 신호입니다.
- FQDN 필터에도 함정이 있습니다: 도메인 기반 필터를 지원하는 프록시·NGFW라도, 앱과 방화벽이 서로 다른 리졸버를 쓰거나 앱이
/etc/hosts·오래된 DNS 캐시로 IP를 고정하면, 방화벽이 최신 IP를 허용해도 앱은 목록 밖 IP로 나가 막힙니다.
정리하면, 아웃바운드가 '가끔' 막힐 때는 DROP이 아니라 IP 회전을 의심하세요. 앱과 방화벽이 같은 DNS 응답(같은 IP 집합·같은 TTL)을 보게 맞추거나, IP 범위(CIDR)·명시적 FQDN 정책으로 회전 전체를 포괄해야 근본 해결됩니다.
상황: api.payment.com을 아웃바운드 화이트리스트에 등록해 승인받았고 평소엔 잘 됩니다. 그런데 트래픽이 몰리는 시간대에 결제 호출이 간헐적으로 Connection timed out. 같은 요청을 재시도하면 대개 성공하고, curl로 수십 번 반복하면 그중 몇 번만 멈춥니다.
원인: 방화벽이 도메인을 한 번 resolve해 얻은 IP 몇 개만 허용해 뒀는데, 결제사가 CDN/LB 뒤에 있어 DNS가 짧은 TTL로 여러 IP를 회전시킵니다. 앱이 새로 얻은 IP가 방화벽 허용 목록에 없으면 그 연결만 조용히 DROP돼 타임아웃되고, 허용 목록에 있는 IP로 다시 나가면 성공합니다 — 그래서 '간헐적'입니다.
진단: 실패가 반복되는 동안 목적지 IP를 대조합니다. dig +short api.payment.com을 여러 번 돌려 반환 IP 집합과 TTL을 확인하고, 실패한 커넥션의 대상 IP(ss -tnp state syn-sent로 SYN-SENT에 멈춘 연결, 또는 tcpdump로 SYN만 나가고 응답 없는 목적지)를 방화벽 허용 목록과 비교합니다. 허용 목록에 없는 IP에서만 실패하면 IP 회전이 원인으로 확정됩니다.
해결: 방화벽 정책을 개별 IP가 아니라 결제사가 공지한 IP 범위(CIDR) 전체나 FQDN 기반 규칙으로 바꿔 회전하는 IP를 모두 포괄합니다. FQDN 필터를 쓰면 앱과 방화벽이 같은 리졸버를 보도록 맞추고, 앱이 오래된 DNS 캐시나 /etc/hosts로 IP를 고정하지 않게 합니다. 임시로는 재시도에 짧은 백오프를 넣어 다른 IP로 재접속하게 하되, 근본 해결은 회전 IP 전체를 허용하는 것입니다.
6. 실무 현장 관점
신규 서버 셋업 시 체크리스트
서버를 처음 구성할 때 아웃바운드 통신 여부를 반드시 확인해야 합니다.
#!/bin/bash
# 아웃바운드 통신 기본 점검 스크립트
echo "=== 아웃바운드 통신 점검 ==="
# 1. DNS 점검
echo -n "[DNS] "
nslookup google.com > /dev/null 2>&1 && echo "OK" || echo "FAIL"
# 2. HTTP 아웃바운드
echo -n "[HTTP:80] "
curl -o /dev/null -s --connect-timeout 5 http://example.com && echo "OK" || echo "FAIL"
# 3. HTTPS 아웃바운드
echo -n "[HTTPS:443] "
curl -o /dev/null -s --connect-timeout 5 https://example.com && echo "OK" || echo "FAIL"
echo "=== 점검 완료 ==="
실무에서 자주 마주치는 시나리오
-
클라우드(AWS/GCP) 신규 인스턴스: Security Group의 아웃바운드 규칙이 기본 전체 허용이지만, 보안 강화 환경에서는 제한되어 있을 수 있습니다.
-
온프레미스 데이터센터: 방화벽 정책이 기본 차단이며, 필요한 아웃바운드 포트를 별도 신청해야 합니다.
-
Docker/Kubernetes 환경: 컨테이너에서 외부 통신이 필요하면 NetworkPolicy와 노드의 아웃바운드 정책 모두 확인해야 합니다.
장애 대응 시 커뮤니케이션 팁
아웃바운드 방화벽 오픈 요청 시 담당 팀에 제공해야 할 정보:
- 출발지: 서버 IP 또는 IP 대역
- 목적지: 도메인 또는 IP (IP가 변동되는 경우 도메인 기반 정책 요청)
- 포트/프로토콜: 443/TCP, 80/TCP 등
- 용도: 어떤 서비스를 위한 통신인지 명시
- 임시/영구: 테스트용인지 영구 정책이 필요한지
7. 아웃바운드 점검 자동화 스크립트
실무에서는 여러 서버의 아웃바운드 통신을 한꺼번에 점검해야 하는 상황이 자주 있습니다. 아래 스크립트를 활용하면 빠르게 점검할 수 있습니다.
#!/bin/bash
# /opt/scripts/outbound-check.sh
# 아웃바운드 통신 종합 점검 스크립트
LOG_FILE="/var/log/outbound-check.log"
TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')
TIMEOUT=5
# 점검 대상 외부 엔드포인트
ENDPOINTS=(
"https://example.com:HTTPS_외부"
"http://example.com:HTTP_외부"
"https://registry-1.docker.io:Docker_Hub"
"https://pypi.org:PyPI_패키지"
"https://registry.npmjs.org:NPM_패키지"
)
echo "[$TIMESTAMP] ===== 아웃바운드 점검 시작 =====" | tee -a "$LOG_FILE"
# DNS 점검
echo -n "[$TIMESTAMP] [DNS] example.com: " | tee -a "$LOG_FILE"
if nslookup example.com > /dev/null 2>&1; then
echo "OK" | tee -a "$LOG_FILE"
else
echo "FAIL — /etc/resolv.conf 확인 필요" | tee -a "$LOG_FILE"
fi
# HTTP/HTTPS 엔드포인트 점검
for ep in "${ENDPOINTS[@]}"; do
URL=$(echo "$ep" | cut -d: -f1,2) # https://... 부분
DESC=$(echo "$ep" | cut -d: -f3)
HTTP_CODE=$(curl -o /dev/null -s -w "%{http_code}" \
--connect-timeout "$TIMEOUT" \
--max-time "$((TIMEOUT * 2))" \
-k "$URL" 2>/dev/null)
if [[ "$HTTP_CODE" =~ ^[2-3][0-9][0-9]$ ]]; then
echo "[$TIMESTAMP] OK [$DESC] $URL (HTTP $HTTP_CODE)" | tee -a "$LOG_FILE"
elif [[ "$HTTP_CODE" == "000" ]]; then
echo "[$TIMESTAMP] FAIL [$DESC] $URL (연결 실패/타임아웃)" | tee -a "$LOG_FILE"
else
echo "[$TIMESTAMP] WARN [$DESC] $URL (HTTP $HTTP_CODE)" | tee -a "$LOG_FILE"
fi
done
echo "[$TIMESTAMP] ===== 점검 완료 =====" | tee -a "$LOG_FILE"
스크립트 실행 — 저장한 스크립트에 실행 권한을 주고 실행합니다.
chmod +x /opt/scripts/outbound-check.sh
/opt/scripts/outbound-check.sh
# 출력 예시:
# [2024-01-15 10:00:00] ===== 아웃바운드 점검 시작 =====
# [2024-01-15 10:00:00] [DNS] example.com: OK
# [2024-01-15 10:00:00] OK [HTTPS_외부] https://example.com (HTTP 200)
# [2024-01-15 10:00:00] OK [HTTP_외부] http://example.com (HTTP 200)
# [2024-01-15 10:00:05] FAIL [Docker_Hub] https://registry-1.docker.io (연결 실패/타임아웃)
8. 핵심 명령어 요약
| 목적 | 명령어 |
|---|---|
| 빠른 아웃바운드 HTTP 점검 | curl -o /dev/null -s -w "%{http_code}" --connect-timeout 5 http://example.com |
| HTTPS 연결 및 응답 확인 | curl -v --connect-timeout 5 https://example.com |
| 파일 다운로드 (curl) | curl -O https://example.com/file.tar.gz |
| 파일 다운로드 (wget) | wget https://example.com/file.tar.gz |
| 프록시를 통한 요청 | curl -x http://proxy:3128 https://example.com |
| SSL 검증 무시 (임시) | curl -k https://internal.example.com |
| 포트 아웃바운드 점검 | nc -zv -w 3 example.com 443 |
| DNS 해석 확인 | nslookup example.com |
정리
- 인바운드: 외부 → 서버 방향, 아웃바운드: 서버 → 외부 방향
- 아웃바운드 점검 순서: DNS → 포트(80/443) → 프록시 설정
- 무한 대기 후 타임아웃 = 방화벽 DROP 의 전형적인 증상
curl --connect-timeout 5로 대기 시간을 줄여 빠른 점검 가능- 폐쇄망에서는 로컬 패키지 미러와 오프라인 설치 방법을 미리 준비
관련 모듈로 더 깊이:
- 방화벽 정책 설계와 접근 제어 리스트(ACL) 구성 실무 — 아웃바운드 차단의 근거가 되는 방화벽 ACL 정책 설계
- DNS 동작 과정과 A, CNAME, TXT 레코드 분석 — 아웃바운드 점검의 첫 단계인 DNS 이름 해석 원리
- 인터넷이 차단된 서버를 외부와 연결하는 Proxy 구성 실무 — 폐쇄망에서 프록시·미러로 외부 연동을 우회하는 법
다음 모듈에서는 클라우드/온프레미스 방화벽 ACL 정책 설계와 Stateful vs Stateless 방화벽의 실무 차이를 다룹니다.