금융권 프로젝트에 투입됐더니 개발 서버에서 apt update가 아예 안 됩니다. 인터넷 연결이 차단된 폐쇄망 환경이기 때문입니다. 패키지 하나 설치하려 해도 프록시 서버를 거쳐야 하고, 어떤 서버는 특정 포트만 열려있습니다. 망 분리 아키텍처의 구조를 이해하지 못하면 이 환경에서 기본 작업조차 막혀서 손도 못 댑니다.

확대

망 분리의 필요성

보안이 중요한 시스템은 인터넷과의 연결을 차단하여 외부 공격 표면을 최소화합니다.

망 분리 수준:

1. 논리적 분리 (소프트웨어 기반)
   - VLAN, 방화벽, ACL로 트래픽 제어
   - 물리 인프라 공유, 설정 오류 시 데이터 유출 가능
   - 구현 비용 낮음

2. 물리적 분리 (Air-Gap)
   - 완전히 다른 물리 네트워크 장비 사용
   - 케이블 자체가 연결되지 않음
   - 최고 수준 보안 (군사, 원자력, 금융 핵심 시스템)

3단계 망 분리 아키텍처

실제 엔터프라이즈 환경에서 흔히 볼 수 있는 구성입니다.

확대

DMZ (비무장 지대)

DMZ(DeMilitarized Zone)는 외부 인터넷과 내부 폐쇄망 사이에 위치한 중간 지대입니다.

DMZ의 역할:

• 외부에서 접근 가능한 서비스 호스팅 (웹, 메일, DNS)
• 내부망과 외부망 사이의 완충 역할
• Squid Proxy를 통한 제한적 인터넷 접근 통로 제공

DMZ 보안 원칙:

외부 방화벽: 인터넷 → DMZ 허용 (필요한 포트만)
내부 방화벽: DMZ → 내부망 차단 (원칙), 특정 트래픽만 허용

Bastion Host

Bastion Host(요새 호스트)는 외부에서 내부망으로의 유일한 SSH 진입점입니다.

접속 경로: 외부 엔지니어 → (SSH 22번) → Bastion Host (DMZ) → (SSH) → 내부 서버 (폐쇄망)

Bastion Host 특징:

• 모든 접근 로그 기록
• MFA 필수 적용
• 최소한의 소프트웨어만 설치
• 강화 OS 설정 (CIS Benchmark)

Squid Proxy가 필요한 이유

폐쇄망 서버는 인터넷 직접 연결이 불가능하지만, OS 보안 패치와 패키지 업데이트는 꾸준히 해야 합니다. Squid Proxy는 DMZ에서 제한된 도메인으로만 트래픽을 중계합니다.

확대

Squid Proxy 동작 원리

HTTP 프록시 흐름:

클라이언트 → GET http://archive.ubuntu.com/ubuntu/... HTTP/1.1
             Host: archive.ubuntu.com
             [Proxy 요청 형식: 전체 URL 포함]

Squid → ACL 검사 → 허용됨
Squid → archive.ubuntu.com에 직접 요청
Squid → 응답 캐시 저장 (선택)
Squid → 클라이언트에 응답 전달

Squid 주요 설정 지시어:

Squid 캐시의 장점

패키지 파일을 캐시하면 같은 파일을 여러 서버가 요청할 때 외부 트래픽을 줄일 수 있습니다.

첫 번째 서버의 요청:
서버A → Squid → 인터넷 (package.deb 다운로드) → Squid 캐시 저장

두 번째 서버의 요청:
서버B → Squid → 캐시 히트! → 인터넷 요청 없이 즉시 응답

폐쇄망 서버에서 pip install pandas 한 줄. 인터넷이 완전히 막힌 서버인데도 잠시 뒤 Successfully installed pandas가 뜹니다. 이 짧은 사이에 내부 서버 → 프록시 → 외부 미러 세 주체 사이에서 요청 전달 → ACL·인증 확인 → 이름 해석 → 대리 요청 → 캐시·응답 → 내부 전달이 순서대로 일어납니다. 이 흐름을 알면 "왜 timeout이지", "왜 403이지", "왜 503이지"를 각각 다른 단계의 문제로 좁힐 수 있습니다. 폐쇄망에서 패키지가 받아지는 것은 "인터넷이 조금 열려서"가 아니라 아래 6단계의 결과입니다.

[내부 서버]  pip install pandas    (http_proxy·https_proxy=http://dmz-proxy:3128)
   │
   ① 프록시로 요청 전달        (직접 egress로 안 나가고 절대 URL / CONNECT를 프록시에)
   │
   ② 프록시가 ACL·인증 확인     (허용 도메인 목록 dstdomain · 필요시 프록시 인증)
   │
   ③ 프록시가 목적지 이름 해석   (프록시의 DNS로 files.pythonhosted.org → IP)
   │
   ④ 외부 미러·업스트림에 대리 요청 (프록시가 자신의 egress로 TCP·TLS 연결)
   │
   ⑤ 응답 수신 → 캐시 저장(선택)  (최초 TCP_MISS → 캐시 저장 → 재요청 시 TCP_HIT)
   │
   ⑥ 내부 서버로 응답 전달       (프록시 → 내부, 패키지 바이트 도착)
   ▼
[내부 서버]  Successfully installed pandas

각 단계에서 무슨 일이 일어나고, 막히면 어떤 증상인가:

즉 "폐쇄망에서 패키지가 받아졌다"는 세 주체가 각자 역할을 다했다는 뜻입니다 — 내부 서버가 프록시로 보냈고(①), 프록시가 허용·이름해석을 통과했고(②③), 프록시의 egress가 외부에 닿았습니다(④). 막힐 때는 access.log의 결과 코드로 층을 가르는 것이 진단의 핵심입니다 — 403은 ACL(②), 503·HIER_NONE은 이름 해석(③), timeout은 egress(④)나 프록시 미설정(①)입니다. 그래서 이름 해석·egress 문제는 클라이언트가 아니라 프록시에서 getent hosts·curl로 확인해야 합니다.

DNS도 기본 라우팅도 없는 폐쇄망 서버에 프록시 한 줄만 꽂으면 외부가 뚫립니다. 이 "마법"의 정체를 알아야 장애 당일에 엉뚱한 곳을 뒤지지 않습니다.

• 클라이언트가 넘기는 것은 이름입니다: HTTP는 요청 라인에 절대 URL(GET http://host/path)을, HTTPS는 CONNECT host:443을 그대로 보냅니다. 둘 다 IP가 아니라 도메인 이름입니다.
• 해석과 연결은 프록시 몫: Squid가 그 이름을 DNS로 풀고, 목적지로 TCP를 열고, HTTPS면 TLS는 건드리지 않은 채 바이트만 왕복시키는 blind 터널이 됩니다. 그래서 클라이언트엔 DNS·egress가 0이어도 되고, 대신 DMZ 프록시가 DNS와 아웃바운드를 갖춰야 합니다.
• split-horizon DNS 엣지: 프록시가 사내 DNS를 바라보면 외부 도메인이 내부 IP로 잡혀 엉뚱한 곳에 연결될 수 있습니다. "허용했는데 안 된다"의 상당수는 ACL이 아니라 이 이름 해석 문제입니다.
• http_access는 첫 일치에서 끝납니다: 규칙은 위에서 아래로 평가되고 처음 매칭되는 줄에서 판정이 확정됩니다. 새 allow 규칙을 파일 맨 아래(http_access deny all 뒤)에 붙이면 앞의 deny all이 먼저 잡아 영영 열리지 않습니다. ACL은 membership이 아니라 순서로 동작합니다.
• HTTPS 터널의 한계: SSL Bump 없이는 Squid가 CONNECT의 host만 볼 뿐 SNI·URL·본문은 못 봅니다. dstdomain ACL도 CONNECT의 host를 기준으로만 걸립니다.