프록시·NAT·네트워크 계층 기초 정리

1. 문제 상황

• 운영 환경: 상담 솔루션을 도메인(예: sangdam.com)으로 호출 → 정상 동작.
• STG 환경: 설정값에 도메인 대신 솔루션 서버의 IP(예: 13.x)가 박혀 있음. 이 IP로 직접 접속 시 상담 화면이 안 뜸.
• STG는 테스트용 WiFi를 거치며, 이 WiFi에는 프록시가 걸려 있음. 문제의 출발점

 "패킷이 어디를 어떻게 지나서 왜 막혔는지"

 

2.  개념 1 : 네트워크는 "봉투 여러 겹"

 

패킷 

패킷은 레이어. 각각의 장비가 장비별로 다른 정보들을 파악

• 인터넷으로 오가는 데이터 한 덩어리로 실제 내용물을 여러 겹 봉투로 싼 형태.
• 안쪽일수록 실제 내용, 바깥쪽일수록 배달용 정보.

계층이름	담는 정보	편지	장비
L7	HTTP	실제 요청 내용 (GET, 주소, 본문)	어플리케이션
L4	TCP	포트 번호 (:8888, :17777)	OS 커널
L3	IP	출발지·도착지 IP 주소	라우터 / OS 커널
L2	이더넷	MAC 주소	스위치 / NIC

• 바깥 봉투일수록 아래 계층(L2), 안쪽 알맹이일수록 위 계층(L7)
• 장비마다 봉투를 어디까지 뜯어보는지가 다름.

 

3. 개념 2 : 서버 안에서 벌어지는 일 (NIC·커널·앱)

받을 때(해체, 아래→위)

• NIC가 L2 프레임을 받아 "이 MAC이 내 것인가?" 확인 → 맞으면 L2 봉투를 벗기고 L3로 올림.
• →  커널 IP가 "이 도착지 IP가 내 것인가?" 확인 → 맞으면 L3 벗기고 L4로.
• →  커널 TCP가 포트를 보고 "이 포트(:17777)를 듣고 있는 프로세스가 누구지?" → 해당 소켓으로 L4를 벗긴 바이트 스트림을 전달.
• →  그 바이트를 최종적으로 받는 건 그 포트를 listen 중인 애플리케이션 프로세스. 여기서 앱이 바이트를 HTTP 문법으로 파싱해 GET·URL·헤더를 읽는다(L7).

보낼 때(포장, 위→아래):

• 앱이 HTTP 텍스트를 만든다(L7)
• → OS 커널의 TCP가 앞에 포트 헤더를 붙인다(L4)
• → IP가 출발지/도착지 IP 헤더를 붙인다(L3)
• → NIC/드라이버가 MAC 프레임으로 감싼다(L2)
• → 전기·전파 신호로 나간다. 

 

[개념정리]

• NIC (네트워크 카드/랜카드)
  • NIC = Network Interface Card, 랜카드/네트워크 카드
  • 기계를 네트워크에 물리적으로 연결하는 하드웨어 하는 일은 두 방향 변환.
  • 밖에서 오는 전기·광·전파 신호 ↔ 0/1 비트, 그리고 비트 ↔ L2 프레임. 즉 서버로 들어오는 모든 패킷이 통과하는 물리적 정문이고, 봉투를 벗기는 첫 단계
• 커널 (L2 → L3 → L4) 
  • 운영체제의 핵심부.
  • 네트워크 카드·CPU·메모리 같은 하드웨어를 직접 다루고, 모든 프로그램이 공통으로 쓰는 기능(네트워크 송수신, 파일 읽기)을 대신 처리하는 부분
  • "내 MAC인가 → 내 IP인가 → 어느 포트의 소켓인가"를 차례로 확인하며 겉봉투를 벗김. 모든 프로그램이 공통으로 쓰는 부분.
• 애플리케이션 (L7)
  • 우리가 실행하는 개별 프로그램. 상담 서비스 프로세스, 웹서버, 브라우저 등. HTTP 내용(L7)을 실제로 이해하고 처리하는 주체.
  • 커널이 넘겨준 알맹이 바이트를 HTTP로 해석해 GET /chat 같은 내용을 읽음.

 

4. 개념 3 : NAT와 프록시

NAT (주소 바꿔치기)

집·회사의 여러 기기가 인터넷에 나갈 때 공인 IP 하나를 공유하게 만드는 기술.

• 밖으로 나가는 패킷의 출발지 사설 IP를 공인 IP로 바꿔치기하는 것이 SNAT.
• 이 작업은 사설망과 인터넷의 경계에 있는 라우터/게이트웨이(집 공유기, 회사 방화벽, 클라우드의 NAT Gateway 등)가 진행함 

[참고 개념]  

• 라우터
  • " 네트워크 장비 " but 내부에 CPU, 메모리, 운영체제(OS)를 갖춘 일종의 소형 컴퓨터(네트워크장비). 
  • '경로 설정'에 초점. 데이터 패킷 포워딩 및 라우팅 (OSI 3계층 작동)
• 게이트웨이
  • '다른 네트워크로 나아가는 관문'과 '프로토콜 번역'에 초점
  • 프로토콜 변환 및 다른 네트워크로의 통로 제공 (OSI 5계층 이상 작동)

프록시 (심부름꾼)

내가 목적지에 직접 가지 않고, 대신 심부름꾼(프록시)에게 "이 주소로 대신 다녀와줘"라고 맡기는 방식.

• 프록시는 요청을 받아 자기 이름으로 목적지에 다시 접속함.
• 그래서 목적지 서버가 보는 접속자는 나(원래 단말)가 아니라 프록시임.
• WiFi 프록시 설정 = "인터넷 요청을 목적지로 직접 보내지 말고 프록시로 보내라"고 단말에 알려주는 것임.

 

5. 개념 4 : HTTP vs HTTPS — 프록시가 내용을 보느냐

• HTTP:
  • 요청 문장(GET http://13.x:17777/...)이 프록시에 그대로 보임.
  • 프록시가 내용을 읽고 주소 형식을 고쳐 서버로 전달함.
• HTTPS:
  • 단말이 프록시에 "터널만 뚫어줘(CONNECT 13.x:17777)"라고 요청함.
  • 프록시는 통로만 열고, 이후 내용은 암호화됨. 프록시는 목적지만 알고 내용은 못 봄.

이 차이 때문에 "IP로만 접속"할 때 HTTPS면 인증서가 도메인 기준이라 IP와 안 맞아 실패하는 경우도 생김.

 

 

6. 문제 상황 : 패킷의 여정

① 테스터가 요청 생성 목적지를 프록시:8888로 지정.

• 진짜 목적지인 서버(13.x:17777)는 IP 칸이 아니라 요청 내용(L7) 안에 문자열(7번)로 들어감.
• 출발지 IP·포트는 단말이 정하는 게 아니라 OS가 자동으로 채움
  • 출발지 IP: 그 단말이 그 네트워크에서 가진 주소(10.0.0.5). 나중에 게이트웨이가 SNAT로 32.x로 바꿈.
  • 출발지 포트(임의 포트): OS가 매 연결마다 안 쓰는 번호 하나를 자동으로 뽑는다(보통 49152~65535, ephemeral port). 목적지 포트(8888)는 고정이지만 출발지 포트는 자동인 이유는, 응답이 돌아왔을 때 "이 응답이 내 어느 연결/탭 것인지"를 이 번호로 구분하기 때문

② 게이트웨이가 SNAT 밖으로 내보내며 출발지를 10.0.0.5 → 32.x로 바꿈.

• 이 시점 패킷: 출발지 32.x → 도착지 42.x(프록시), 도착 포트 :8888.
• L4 도착지가 42.x로 바뀌는 건 아님.
  • IP(42.x)는 L3, 포트(8888)는 L4임
  • L4 칸엔 포트만 들어가고 IP는 안 들어감. 둘을 합쳐서 하나의 목적지 42.x:8888이 되는 것

③ 프록시가 대신 접속 프록시가 요청 내용을 읽어 목적지 13.x:17777을 뽑아냄.

• 그리고 프록시의 공인 IP (52.x)으로 서버에 새 연결을 만듦.
• 이 시점 패킷: 출발지 52.x → 도착지 13.x, 도착 포트 :17777.

④ 서버가 수신 서버 입장에서 접속 출처는 52.x (프록시의 공인 IP)

 

7. 왜 진짜 목적지가 "내용" 안에 들어가나

 

프록시를 쓰면

• 패킷의 목적지 칸에는 항상 프록시가 적히며, 
• 진짜 목적지(13.x:17777)는 IP 칸이 아니라 HTTP 요청 문장 안에 들어감.
• 프록시는 이 문장을 직접 읽어서 목적지를 알아냄.

GET http://13.x:17777/chat HTTP/1.1

 

• 프록시(어플리케이션) 가 그 연결의 종단(끝점) 이기 때문에 봉투를 L7까지 다 뜯어 HTTP 문장으로 해석
• 반대로 중간의 라우터는 L3(IP)까지만, 방화벽은 L4(IP+포트)까지만 봄.
• 그래서 이들은 요청 안의 URL을 알 수 없음. 연결의 끝점인 애플리케이션(프록시·서버)만 L7을 읽음.

 

9. 원인과 해결

• 서버가 보는 접속 출처 = 프록시 42.x. (테스터도 32.x도 아님.)
• 따라서 서버 방화벽(보안그룹)에 42.x의 17777 포트 허용이 필요함. 이걸 열지 않으면 접속이 막힘.
• 추가 점검 항목:
  • 프록시가 17777 같은 비표준 포트로의 연결을 허용하는지(프록시 자체가 막으면 서버 방화벽과 무관하게 실패함).
  • HTTPS라면 서버 인증서가 도메인 기준이라 IP 직접 접속 시 검증 실패로 화면이 안 뜨는지.
• 확정 방법: 서버 접속 로그에서 실제 출처가 42.x로 찍히는지 먼저 확인. 안 찍히면 프록시 단계에서 막힌 것이므로 방화벽이 아니라 프록시를 점검해야 함.