NCP 공공 클라우드 - On-Premise AI 서버와 Cloud DB 연동

[NCP 공공 클라우드] IPsec 장비 호환 문제 해결: 베스천 호스트 터널링으로 On-Premise AI 서버와 Cloud DB 연동하기

IPsec 장비 호환 문제 해결: 베스천 호스트와 SSH 터널링으로 On-Premise AI 서버와 Cloud DB 안전하게 연동하기

안녕하세요! 오늘은 네이버 클라우드 플랫폼(NCP) 공공기관용(Public/Gov) 환경을 구축하면서 겪었던 **'네트워크 장비 호환성 문제'**와 이를 타개하기 위한 '우회 연결 아키텍처(Bastion Host + SSH Tunneling)' 구축 경험을 공유하고자 합니다.

현재 AI 프로젝트를 진행하면서, 저희 회사의 온프레미스(사내) GPU 서버와 NCP 클라우드 내부에 격리된(Private) Cloud DB for MySQL을 안전하게 연동해야 하는 미션이 있었습니다.

결론부터 말씀드리면, 예산과 장비 호환성 문제로 즉각적인 VPN 도입이 어려워 **보안을 완벽하게 유지하면서도 외부망에서 내부망으로 다이렉트 터널을 뚫는 임시 우회로(SSH 로컬 포트 포워딩)**를 구축했습니다. 혹시 저와 비슷한 상황에 부닥치신 데브옵스, 백엔드 개발자분들께 이 글이 실질적인 도움이 되길 바랍니다.

직면한 문제: IPsec VPN 장비의 호환성 한계

가장 정석적이고 안전한 방법은 저희 회사 사내망과 NCP 클라우드망을 IPsec VPN으로 연결하는 것입니다. 이를 위해 세팅을 준비하고 있었습니다.

하지만 여기서 예상치 못한 벽에 부딪혔습니다. NCP 공공기관용 클라우드에서 공식적으로 지원하는 IPsec VPN 장비 기종이 'AXGATE'와 'SECUI'로 제한되어 있었기 때문입니다. 불행히도 저희 회사의 방화벽/라우터 장비는 'ASUS' 제품이었고, NCP 측과 연동 테스트를 해보았지만 프로토콜 규격 문제로 터널링이 맺어지지 않았습니다.

대안 모색: 베스천 호스트(Bastion Host)를 활용한 SSH 포트 포워딩

당장 프로젝트는 진행되어야 하는데, 고가의 보안 장비를 즉시 구매하거나 렌탈할 예산은 아직 승인되지 않은 상황이었습니다. (추후 예산이 확보되면 정식 장비를 도입할 예정입니다.)

따라서 **"어떻게 하면 외부망(사내 GPU 서버)에서 철저히 격리된 내부망(NCP Cloud DB)에 안전하게 접근할 수 있을까?"**를 고민하다가 다음의 아키텍처를 설계했습니다.

쉽게 이해하기 (초등학생도 이해하는 비유!) 은행(Cloud DB)에 돈을 넣으러 가야 하는데, 정문(VPN) 규격에 맞는 전용 장갑차(AXGATE 장비)가 없어서 못 들어가는 상황입니다. 그래서 은행 앞마당에 임시 초소(베스천 호스트)를 세웠습니다. 이 초소는 오직 '우리 회사 직원(IP 화이트리스트)'만 들어갈 수 있습니다. 초소에 들어가면 외부 해커가 절대 볼 수 없는 튼튼한 '비밀 지하 터널(SSH 포트 포워딩)'을 통해 내부 금고까지 바로 연결되도록 뚫어 놓은 것입니다!

아키텍처 및 해결 과정

1. 전체 아키텍처 구성도

1. 사내 AI GPU 서버: autossh 백그라운드 서비스를 통해 베스천 호스트로 끊임없는 접속을 시도 및 유지
2. NCP 베스천 호스트 (Bastion Host): 터널의 도착지이자 출입구. 도착한 트래픽을 내부 DB로 전달
3. NCP Cloud DB for MySQL: 외부와 단절된 Private Subnet에 위치 (베스천에서 넘어온 터널링 트래픽 수신)

2. 베스천 호스트(Bastion Host) 서버 생성

먼저 NCP 환경에 접속 통로가 될 서버를 한 대 생성했습니다.

• OS: ubuntu-24.04-base (가장 안정적이고 최신인 우분투 환경)
• 서버 스펙: s2-g3a (vCPU 2EA, Memory 8GB) (터널링 트래픽을 충분히 감당할 수 있는 스펙)
• 공인 IP: 할당 완료 (175.45.220.199)

** (실제 구축된 베스천 호스트의 상세 정보입니다. 공인 IP와 내부 IP가 모두 할당된 것을 볼 수 있습니다.)

3. 강력한 보안 설정: ACG (IP 화이트리스트) ★ (매우 중요)

아무리 터널링이 암호화된다 하더라도 출입구 자체의 보안은 타협할 수 없습니다. NCP의 ACG(Access Control Group - 방화벽 기능)를 설정하여 '우리 회사 사내망 IP'만 베스천 호스트에 접근할 수 있도록 화이트리스트(Whitelist) 방식으로 차단했습니다.

• 접근 소스(Target): [회사_사내_공인_IP]/32 (예: 123.45.67.89/32)
• 허용 포트: 22 (SSH 접속 및 터널링용 포트)

이렇게 설정하면, 전 세계 어떤 해커가 접근하더라도 우리 회사 IP가 아니면 해당 서버에 핑조차 보낼 수 없습니다.

4. 핵심 구현: SSH 로컬 포트 포워딩 (Tunneling) 자동화 구성

단순히 개발자 PC 터미널에 명령어 한 줄을 쳐서 터널을 여는 것은 실무 환경(Production)에서 적합하지 않습니다. 서버가 재부팅되거나 네트워크가 잠시 끊겨도 알아서 터널이 복구되도록 autossh 패키지와 Linux systemd 서비스를 사용하여 프로덕션 레벨로 구성해야 합니다.

아래의 모든 작업은 **사내 AI GPU 서버(온프레미스 우분투 장비)**에서 수행합니다.

단계 4-1: 사내 AI 서버에 autossh 설치

우선 끊김 없는 터널링을 유지해 주는 autossh 패키지를 설치합니다.

# 사내 AI 서버 터미널에서 실행합니다.
sudo apt-get update
sudo apt-get install autossh -y

단계 4-2: SSH 키 생성 및 패스워드 없는 자동 접속 설정

자동으로 접속이 복구되고 유지되려면 비밀번호를 손으로 입력하는 과정이 없어야 합니다. 이를 위해 SSH 인증키(비대칭 키)를 구성합니다.

# 1. 사내 AI 서버에서 SSH 키 생성 (엔터만 쳐서 기본값으로 생성, 비밀번호 설정 X)
ssh-keygen -t rsa -b 4096

# 2. 생성된 공개키를 베스천 호스트로 전송 (이때만 베스천 서버의 비밀번호 1회 입력 필요)
# username: 베스천 호스트 계정 (예: root 또는 ubuntu)
ssh-copy-id -i ~/.ssh/id_rsa.pub root@175.45.220.199

단계 4-3: 백그라운드 서비스(systemd) 등록 (실무 필수)

서버가 재시작되어도 항상 터널링이 백그라운드에서 유지되도록 Linux의 서비스 관리자에 등록합니다. 지정된 경로에 파일을 생성하고 아래 풀 코드를 작성합니다.

• 생성할 파일 위치: /etc/systemd/system/db-tunnel.service

# /etc/systemd/system/db-tunnel.service 의 전체 코드
[Unit]
Description=AutoSSH tunnel to NCP Bastion Host for Cloud DB
After=network-online.target
Wants=network-online.target

[Service]
# 사내 서버에서 autossh를 실행할 사용자 계정 (root 또는 일반 사용자 계정명)
User=root
# autossh 자체 모니터링 포트 비활성화 (0으로 두면 기본 ssh KeepAlive 활용)
Environment="AUTOSSH_PORT=0"
Environment="AUTOSSH_GATETIME=0"

# 터널링 핵심 명령어 설명:
# -M 0: autossh 자체 모니터링 끄기
# -N: 쉘(명령어 창)을 실행하지 않고 포트 포워딩 터널만 유지
# -q: 조용히 실행 (불필요한 로그 생략)
# -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3": 30초마다 생존 핑을 보내고 3번 실패 시 재연결
# -L 3306:[NCP_DB_내부IP]:3306 -> 내 사내 서버의 3306포트를 베스천을 거쳐 DB의 3306포트로 매핑
ExecStart=/usr/bin/autossh -M 0 -N -q \
    -o "ServerAliveInterval 30" \
    -o "ServerAliveCountMax 3" \
    -o "ExitOnForwardFailure yes" \
    -L 3306:10.0.0.X:3306 root@175.45.220.199
    # ★주의: 10.0.0.X 부분을 실제 NCP Cloud DB의 Private IP로 반드시 변경하세요.
    # ★주의: root@175.45.220.199 부분은 베스천 호스트 접속 계정과 공인 IP입니다.

Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

단계 4-4: 서비스 실행 및 자동 시작 등록

파일 작성이 끝났으면 시스템 데몬을 새로고침하고 서비스를 시작합니다.

# 데몬 재로드 (새로 만든 시스템 파일 인식)
sudo systemctl daemon-reload

# 부팅 시 터널링 자동 시작 등록
sudo systemctl enable db-tunnel

# 서비스 지금 즉시 시작
sudo systemctl start db-tunnel

# 서비스 상태 확인 (초록색으로 active (running)이 뜨면 완벽하게 성공입니다!)
sudo systemctl status db-tunnel

5. 완벽한 보안과 연결: Spring Boot 백엔드 서버 설정 적용

SSH 터널링의 가장 큰 장점은 사내망(인터넷 구간)을 통과하는 트래픽이 SSH 프로토콜에 의해 강력하게 암호화(철제 금고) 된다는 점입니다. 해커가 중간에서 패킷을 가로채도 절대 평문 데이터를 볼 수 없습니다.

터널링이 사내 서버의 3306 포트에 뚫려있으므로, 사내 서버에서 동작하는 애플리케이션(예: Spring Boot)은 마치 '자기 자신의 PC에 DB가 설치되어 있는 것처럼' 설정하면 됩니다.

저희 회사 AI 서버에 배포된 스프링 부트 애플리케이션의 설정 파일은 아래와 같이 수정했습니다.

• 수정할 파일 위치: src/main/resources/application.yml (또는 application.properties)

# src/main/resources/application.yml (전체 풀 코드 예시)
spring:
  datasource:
    # 핵심: Host 주소가 베스천 공인 IP가 아닌 '127.0.0.1 (localhost)' 입니다!
    # 터널이 사내 서버의 로컬 포트로 뚫려 있기 때문입니다.
    url: jdbc:mysql://127.0.0.1:3306/ai_project_db?characterEncoding=UTF-8&serverTimezone=Asia/Seoul
    username: your_db_username
    password: your_db_password
    driver-class-name: com.mysql.cj.jdbc.Driver

  jpa:
    hibernate:
      ddl-auto: validate
    show-sql: true
    properties:
      hibernate:
        format_sql: true

DBeaver 같은 DB 클라이언트 툴로 접속하실 때도 Host를 127.0.0.1로, Port를 3306으로 잡으시면 안전하고 빠르게 NCP 내부망 DB와 통신할 수 있습니다.

향후 계획 (Next Step)

현재 이 방식은 당장의 프로젝트 진행을 위한 훌륭한 '우회 기동'입니다. SSH 프로토콜 자체의 강력한 종단 간 암호화(End-to-End Encryption)와 ACG(화이트리스트 IP 차단)라는 이중 보안 체계 덕분에 공공 프로젝트에서도 무리 없이 사용할 수 있는 매우 안전한 방식입니다.

하지만 터널링 유지를 위한 관리 포인트(systemd 등)가 하나 늘어났다는 아쉬움이 있으므로, 근본적인 아키텍처 개선을 위해 향후 다음과 같은 단계를 밟을 예정입니다.

1. 예산 확보: 프로젝트 1차 마일스톤 달성 후, 인프라 보안 예산 기안.
2. 호환 장비 도입: NCP 공식 지원 기종인 AXGATE 또는 SECUI 방화벽 장비 구매 혹은 렌탈.
3. 정식 IPsec VPN 마이그레이션: 현재의 SSH 터널링 서비스를 내리고, 라우터 단에서 맺어지는 Site-to-Site VPN으로 전환하여 사내망과 클라우드망을 하나의 안전한 사설 네트워크처럼 연동할 계획입니다.

마무리하며

클라우드, 특히 공공(Gov) 클라우드를 다루다 보면 보안 규정과 장비 호환성 때문에 이론대로 되지 않는 경우가 허다합니다. 그럴 때 포기하지 않고 인프라 지식을 총동원하여 'SSH 로컬 포트 포워딩'과 systemd를 결합한 자동화된 실용적 우회로를 만들어내는 것이 데브옵스와 백엔드 개발자의 진정한 묘미가 아닐까 싶습니다.

장비 문제로 고생하시는 분들께 이 글이 한 줄기 빛이 되길 바라며, 인프라 세팅이나 Spring Boot 설정과 관련하여 궁금한 점은 언제든 댓글로 남겨주시면 아는 선에서 최대한 자세히 답변드리겠습니다! 감사합니다.