infra
Platform

모듈 맵

[Network] wget/curl로 외부 연동 방화벽 차단 여부 판별법

0 / 35 완료

펼치기
0 / 35 완료0%

Networking · 20 / 35

[Network] wget/curl로 외부 연동 방화벽 차단 여부 판별법

서버에서 외부 인터넷으로 나가는 아웃바운드 통신을 점검합니다

🚨INCIDENT ALERT
HIGH

서버는 외부 API를 호출해야 하는데 운영망에서는 모든 요청이 타임아웃됩니다. 인바운드 방화벽은 열려 있었지만 아웃바운드 정책과 프록시 설정은 아무도 확인하지 않았습니다.

서버 통신은 들어오는 길만큼 나가는 길도 중요합니다. curl과 wget으로 출구를 증명해야 합니다.

아웃바운드 통신 점검 (wget / curl)

서버가 외부 인터넷에 연결되지 않으면 패키지 설치, 업데이트, 외부 API 호출이 모두 실패합니다. 이 챕터에서는 아웃바운드 통신의 개념을 이해하고, curlwget으로 직접 점검하는 방법을 익힙니다.


1. 인바운드 vs 아웃바운드 방향 이해

이번 챕터에서 배울 것
  • 1인바운드(Inbound)와 아웃바운드(Outbound) 트래픽 방향의 차이
  • 2curl 주요 옵션으로 HTTP/HTTPS 아웃바운드 통신 점검
  • 3wget을 이용한 파일 다운로드 및 curl과의 용도 비교
  • 4방화벽 DROP 시 타임아웃 증상과 즉각적 Connection Refused의 차이
  • 5사내 프록시 설정 확인 및 yum/apt 패키지 설치 실패 단계별 진단
  • 6폐쇄망(Air-Gapped) 환경에서의 오프라인 패키지 설치 접근법
실습 환경 준비
DNS 이름 해석 확인
nslookup google.com
HTTPS 아웃바운드 빠른 점검
curl -o /dev/null -s -w "%{http_code}" --connect-timeout 5 https://example.com
프록시 환경 변수 확인
env | grep -i proxy
💡개념

트래픽 방향: 인바운드(Inbound) vs 아웃바운드(Outbound)

배포 서버에서 외부 결제 API 호출이 안 됩니다. 포트도 열었고 DNS도 됩니다. 방화벽 설정을 확인하는데, 인바운드 규칙만 잔뜩 있고 아웃바운드를 막고 있는지 확인조차 안 해봤습니다. 인바운드와 아웃바운드의 방향 개념을 명확히 이해하지 못하면 방화벽 진단에서 절반은 놓치게 됩니다.

트래픽 방향: 인바운드(Inbound) vs 아웃바운드(Outbound)

네트워크 통신은 방향을 기준으로 두 가지로 나뉩니다.

구분방향대표 예시
인바운드 (Inbound)외부 → 서버사용자가 웹 브라우저로 서버에 접속
아웃바운드 (Outbound)서버 → 외부서버가 yum/apt로 패키지 다운로드
[인바운드 예시]
클라이언트(브라우저) ──→ 방화벽 ──→ 웹 서버(:80)
                      인바운드 허용 필요

[아웃바운드 예시]
웹 서버 ──→ 방화벽 ──→ yum 미러 서버(80/443)
         아웃바운드 허용 필요

왜 구분이 중요한가?

방화벽 정책은 방향별로 독립적으로 설정됩니다. 인바운드 80 포트가 열려 있어도, 아웃바운드 443이 막혀 있으면 서버에서 외부 HTTPS 요청은 불가능합니다.

보안 강화를 위해 아웃바운드를 기본 차단(deny)하고 필요한 IP/포트만 허용하는 화이트리스트 방식을 많이 사용합니다.

폐쇄망(Air-Gapped Network)

금융, 공공, 국방 환경에서는 서버가 인터넷과 완전히 단절된 폐쇄망에 배포됩니다. 이 경우:

  • yum install nginx → 미러 서버 접근 불가 → 실패
  • curl https://api.example.com → 타임아웃
  • 내부 패키지 저장소(로컬 mirror)나 오프라인 설치 패키지를 별도 준비해야 합니다

2. curl로 아웃바운드 통신 점검

💡개념

curl 주요 옵션과 아웃바운드 점검 패턴

외부 API가 안 된다고 할 때 "curl로 직접 쳐봐" 라는 말을 듣습니다. 그런데 curl <url> 외에 어떤 옵션을 어떻게 써야 응답 코드만 보는지, 타임아웃을 설정하는지, 헤더를 붙이는지 모릅니다. 아웃바운드 점검에 자주 쓰이는 옵션을 익혀두면 장애 상황에서 즉시 꺼낼 수 있습니다.

curl 주요 옵션과 아웃바운드 점검 패턴

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
🔍실행 후 확인할 것
  • 핵심 출력명령 결과에서 성공/실패를 가르는 값을 먼저 확인합니다
  • 대상 식별IP, 포트, 인터페이스, 프로세스명처럼 다음 조치를 결정하는 필드를 봅니다
  • 다음 분기결과가 기대와 다르면 어느 계층을 이어서 점검할지 정합니다

아웃바운드 점검 시 해석 포인트 — 결과 유형별로 원인과 조치가 달라집니다.

# 성공 케이스 — 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 사용법과 curl과의 차이

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. 실습: 아웃바운드 통신 단계별 점검

1단계: DNS 이름 해석 확인

아웃바운드 통신 실패의 첫 번째 원인은 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 점검
2단계: 80/443 아웃바운드 포트 통신 확인

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 실패)
3단계: 프록시 설정 확인 및 적용

사내망에서는 인터넷 접근이 프록시 서버를 통해서만 허용되는 경우가 많습니다. 이 경우 프록시 설정 없이는 직접 아웃바운드가 차단됩니다.

로컬 터미널
# 환경 변수로 프록시 설정 확인
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
4단계: yum/apt install 실패 시 종합 점검

패키지 설치 실패는 아웃바운드 문제의 가장 흔한 증상입니다. 단계별로 좁혀나가는 방법을 익힙니다.

로컬 터미널
# [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 ...

만약 ncConnection timed out을 뱉는다면 사내 보안실 방화벽 정책 상 외부 도메인 api.payment.com:443 으로 나가는 아웃바운드 화이트리스트 정책이 누락된 것이 명백한 원인입니다.

외부 결제 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 ...

만약 ncConnection timed out을 뱉는다면 사내 보안실 방화벽 정책 상 외부 도메인 api.payment.com:443 으로 나가는 아웃바운드 화이트리스트 정책이 누락된 것이 명백한 원인입니다.

외부 결제 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 ...

만약 ncConnection 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 인증서를 정식 등록 후 제거하세요.


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 "=== 점검 완료 ==="

실무에서 자주 마주치는 시나리오

  1. 클라우드(AWS/GCP) 신규 인스턴스: Security Group의 아웃바운드 규칙이 기본 전체 허용이지만, 보안 강화 환경에서는 제한되어 있을 수 있습니다.

  2. 온프레미스 데이터센터: 방화벽 정책이 기본 차단이며, 필요한 아웃바운드 포트를 별도 신청해야 합니다.

  3. 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로 대기 시간을 줄여 빠른 점검 가능
  • 폐쇄망에서는 로컬 패키지 미러와 오프라인 설치 방법을 미리 준비

지식 확인

퀴즈 — 5문제

Q1

신규 서버에 배포한 애플리케이션이 외부 결제 API(`api.payment.com:443`)를 호출할 때 타임아웃이 발생합니다. 서버에서 `curl -v https://api.payment.com` 을 실행했을 때도 응답 없이 멈춥니다. 가장 가능성 높은 원인과 확인 방법은?

Q2

`curl -O https://example.com/file.zip` 명령에서 `-O` 옵션의 역할은?

Q3

폐쇄망 환경에서 `curl https://example.com` 실행 시 가장 흔히 나타나는 증상은?

Q4

yum install 실패 시 아웃바운드 점검 순서로 올바른 것은?

Q5

`wget`과 `curl`의 차이로 올바른 설명은?

0 / 5 답변

🧪 실습으로 확인하기

포트는 열렸다는데 왜 안 되지? — ss/netstat/telnet으로 TCP 진단

초급

"포트 8080 열었는데요?"와 "왜 안 돼요?" 사이의 간극을 메우는 실습. ss로 바인딩 상태를 확인하고, telnet/nc으로 원격 연결을 테스트하고, iptables 방화벽을 진단하고, 바인딩 주소(0.0.0.0 vs 127.0.0.1)까지 수정하는 4단계 TCP 포트 진단 플로우를 완성한다.

35📋 4단계💻 직접 환경
실습 시작하기 →

이것도 배워보세요

networking중급 · 35
[Network] CentOS/Ubuntu 서버 방화벽(firewalld / ufw) 포트 열기
Networking 트랙 계속
docker입문 · 30
[Docker] 백엔드 개발자에게 Docker와 컨테이너 가상화가 필수인 이유
Docker 트랙 시작점