VyOS로 제로 트러스트 보안 네트워크 만들기
1차 프로젝트 | 2026.01.05 – 2026.01.28
VyOS 기반의 고가용성 및 제로 트러스트 보안 네트워크 구축
프로젝트 개요
![[FOR_PROJECT1-1776263888058.webp]]

| 항목 | 내용 |
|---|---|
| 기간 | 2026년 1월 5일 ~ 1월 28일 (약 3주) |
| 팀원 | 정요한(PL), 김관희(PM), 김희수, 김진아, 신승훈 |
| 환경 | VMware Workstation Pro 17, GNS3, VyOS 1.3.5, Rocky Linux 9.7 |
| 핵심 키워드 | Zero Trust, VyOS, WireGuard VPN, VRRP/HSRP, NAT, Bastion Host, Syslog |
소규모 연구소의 네트워크 및 사내 보안을 구축하는 시나리오를 가정했습니다. 단순한 방화벽 설치에 그치지 않고, 제로 트러스트(Zero Trust) 보안 모델 — “아무것도 기본으로 신뢰하지 않는다” — 을 실제 네트워크 정책에 구현하는 것이 목표였습니다.
구현 목표
- 3-Tier Zone 분리 — User / Server / MGMT 영역을 논리적으로 격리
- White-list 방화벽 — 기본 차단, 허용 목록에 있는 트래픽만 통과
- 게이트웨이 이중화 — VRRP/HSRP로 라우터 장애 시에도 통신 유지
- WireGuard VPN — 지사 간 암호화 전용 통신망 구축
- Bastion Host + OOB — 관리 트래픽의 물리적·논리적 격리
- 중앙 집중형 관제 — Syslog + Cockpit + NMS(SNMP)로 통합 모니터링
전체 구성 — 중앙 + 4개 Edge
이 프로젝트는 5명이 각자 하나의 Edge를 맡고, 중앙 라우터로 모두 연결하는 분산 구조였습니다.
[ 중앙 라우터 (VyOS) ]
├── Edge A : DMZ + TRUST Zone, WireGuard VPN
├── Edge B : USER / SERVER / MGMT Zone 분리, HSRP 이중화
├── Edge C : Server Zone (Web/DB/NAS/GPU), VyOS 방화벽
└── Edge D : 연구소 내부망, MariaDB 이중화, Bastion Host
중앙 라우터는 각 Edge의 사설망(192.168.x.x)을 외부 프로젝트 망(10.x.x.x)으로 연결하는 게이트웨이 역할을 하면서, WireGuard VPN 허브이자 메일 릴레이 경유지이기도 했습니다.
네트워크 설계 — Zone 기반 보안 분리
Zone 기반 분리란 네트워크를 역할별로 나누어, Zone 간 통신을 명시적으로 허용된 것만 허용하는 설계 방식입니다. 제로 트러스트 모델의 핵심 원칙입니다.
공통 Zone 구조
| Zone | 역할 | 접근 원칙 |
|---|---|---|
| TRUST (User) | 내부 사용자 PC | 서비스 Zone 접근 허용, MGMT 접근 차단 |
| DMZ | 외부 공개 서비스 (Web, DNS) | 외부 → 특정 포트만 허용, 내부망 직접 접근 차단 |
| SERVER | DB, Mail, NAS, AI 서버 | User에서 서비스 포트만 접근 허용 |
| MGMT | Syslog, NMS, 관리 PC | 관리자 IP 대역만 접근 허용 |
White-list 방화벽 정책
기본 동작: DROP — 명시적으로 허용된 트래픽만 통과
모든 방화벽 정책의 기본값을 default-action drop으로 설정했습니다. 허용이 필요한 서비스만 규칙을 추가하는 방식(White-list)으로 운영합니다.
PROTECT-SERVER : 웹(80, 443), 메일(25, 110, 143), DB(3306) 포트만 인바운드 허용
PROTECT-MGMT : Syslog(514), 관리 트래픽만 선별 허용
PROTECT-USER : 내부 사용자가 서버에 SSH 직접 접근하는 것을 제한
OUTSIDE-IN : 외부에서 DMZ 진입 시 서비스 목적 포트만 허용, 나머지 전면 차단
NAT 구성 — 내부 IP 은폐
NAT(Network Address Translation) 은 내부 사설 IP 주소를 외부로 노출하지 않고 통신할 수 있게 해주는 기술입니다. 내부 서버의 실제 주소를 숨겨 외부 공격으로부터 보호하는 역할도 합니다.
SNAT (Source NAT / Masquerade)
내부 사설 IP(192.168.x.x)를 외부 대표 IP(10.x.x.x)로 변환하여 인터넷에 접근합니다. User / Server / MGMT 각 Zone의 내부 IP가 외부로 노출되지 않도록 모든 아웃바운드 트래픽에 Masquerade를 적용했습니다.
DNAT (Destination NAT / 포트 포워딩)
외부에서 내부 서버의 특정 서비스에만 접근할 수 있도록 포트를 선별적으로 개방했습니다. 메일 포트(25, 143, 389), SSH(22, Bastion만 허용), DNS(53) 등 필요한 포트만 내부 서버로 라우팅합니다.
게이트웨이 이중화 — VRRP / HSRP
VRRP(Virtual Router Redundancy Protocol) 와 HSRP(Hot Standby Router Protocol) 는 라우터 두 대를 묶어 가상 IP 하나를 공유하는 이중화 기술입니다. Active 라우터가 다운되면 Standby 라우터가 자동으로 가상 IP를 인계받아 통신이 중단되지 않습니다.
- Edge B: HSRP — R1(Active, Priority 110) + R2(Standby, Priority 90),
preempt활성화로 복구 시 주 라우터로 자동 복귀 - Edge C (VyOS): VRRP — 각 Zone별 가상 게이트웨이 구성
- 중앙 서버: Keepalived VRRP — DNS/LDAP 서버 Primary-Standby 구성, VIP 자동 승계
WireGuard VPN — 지사 간 암호화 통신
WireGuard는 기존 VPN 프로토콜(IPsec, OpenVPN)보다 훨씬 가볍고 빠른 최신 VPN 프로토콜입니다. 커널 레벨에서 동작하고 코드 기반 자체가 작아 오버헤드가 매우 낮습니다.
중앙 라우터(VyOS)에 WireGuard 허브를 구성하고, 각 Edge(지사)가 Public Key 기반 상호 인증으로 피어링을 맺었습니다.
중앙 라우터 (172.16.10.2/24)
├── Peer: Edge C (TO_JINA) — allowed-ips 192.168.6.0/26
└── Peer: Edge B (TO_HEESU) — allowed-ips 192.168.7.0/24
Split Tunneling: allowed-ips 설정으로 원격지 네트워크 대역으로 향하는 트래픽만 VPN 터널을 통해 전송하고, 나머지 인터넷 트래픽은 터널을 우회합니다. 불필요한 트래픽이 VPN을 거치지 않아 성능이 향상됩니다.
중앙 관리 서버 — 통합 인프라 서비스
DNS + LDAP + NTP + STANDBY
중앙 서버(192.168.20.0/24)에서 전체 Edge를 위한 공통 인프라 서비스를 제공했습니다.
| 서비스 | IP | 역할 |
|---|---|---|
| DNS (BIND) | 192.168.20.2 | 도메인 이름 해석, MX 레코드로 메일 라우팅 정의 |
| LDAP (OpenLDAP) | 192.168.20.2 | 중앙 집중형 사용자 계정 인증 — 모든 Edge 메일 계정 통합 관리 |
| NTP (chrony) | 192.168.20.2 | 전체 서버 시간 동기화 — 로그 타임스탬프 정확성 보장 |
| MAIL-RELAY (Postfix) | 192.168.20.3 | 각 Edge 메일 서버 간 중계 — 경로 단일화 |
| STANDBY (Keepalived) | 192.168.20.4 | DNS/LDAP 데이터 실시간 동기화, Primary 장애 시 VIP 자동 승계 |
왜 LDAP을 중앙에 뒀는가? 각 Edge마다 메일 계정을 개별 등록하면 계정 정보가 분산되어 관리 부담이 커집니다. LDAP 하나에서 모든 Edge의 사용자 계정을 통합 관리하면 계정 추가·삭제·수정이 한 곳에서 가능하고 데이터 일관성도 유지됩니다.
**왜 NTP가 중요한희 담당. 보안 구역을 DMZ와 TRUST로 나누어 내부 사용자와 공개 서비스를 격리했습니다.
- DMZ-ADMIN (Bastion Host): DMZ 내부 서버 관리를 위한 Jump Server — DMZ 접근은 이 서버를 통해서만 가능
- DMZ-DNS: 외부 공개 DNS 서버 (BIND)
- DMZ-WEB: Apache 기반 웹 서버 — Edge A 소개 홈페이지
- win-proPC: TRUST Zone 내부 사용자 PC — 외부 인터넷 차단, DMZ 통신은 허용
Cisco 라우터에 DNAT(포트 포워딩)를 적용하여 외부에서 DMZ 서버 특정 서비스만 접근 가능하게 하고, SNAT로 내부 IP를 보호했습니다.
Edge B — 3-Zone 분리 + HSRP 이중화
신승훈 담당. USER / SERVER / MGMT 세 Zone을 서브넷으로 분리하고 Cisco 라우터 2대(R1, R2)로 HSRP 이중화를 구성했습니다.
ACL 구성:
USER_IN: 사용자의 서버 접근을 서비스 단위로 제한, 백업 서버 직접 접근 차단MGMT_IN: 관리자 IP 대역(192.168.13.32/28)만 관리망 접근 허용OUTSIDE_IN: 외부에서 SMTP(25)만 허용, 나머지 전면 차단
모니터링은 Grafana + Rocky Cockpit으로 Bastion Host 자원과 내부 네트워크 접근 정보를 시각화했습니다.
Edge C — VyOS 기반 서버 Zone
김진아 담당. VyOS를 게이트웨이로 사용하여 Server / MGMT / User Zone을 분리하고 White-list 방화벽을 적용했습니다.
서버 구성:
| 서버 | IP | 내용 |
|---|---|---|
| Web (Apache + PHP) | 192.168.6.69/26 | 인프라 관제 대시보드 (Lab C Charlie 관제 센터) |
| DB (MariaDB + Adminer) | 192.168.6.66/26 | ACL로 Web 서버와 관리자 PC만 3306 포트 허용 |
| NAS (소프트웨어 RAID 1) | 192.168.6.65/26 | Tiny File Manager — 브라우저 기반 파일 관리, 미러링으로 디스크 결함 대비 |
| GPU (Jupyter Notebook) | 192.168.6.67/26 | 원격 접속 환경 구성, VyOS 방화벽 1차 + Jupyter Password 2차 이중 보안 |
| Syslog + Cockpit | 192.168.6.129/26 | 전체 서버 로그 중앙 수집, 단일 화면 모니터링 |
| CCTV (공공 API 연동) | 192.168.6.132/26 | 도로공사 CCTV API — 실시간 영상 스트림을 관제 대시보드에 통합 |
서비스 연계 시나리오: 연구원이 대시보드에서 NAS에 데이터를 업로드 → GPU 서버 Jupyter에서 AI 모델 학습 → 학습 결과가 DB에 자동 기록. 모든 데이터는 RAID 1 디스크에 이중 저장.
Edge D — 연구소 내부망 + MariaDB 이중화
김희수수 담당. 클라이언트 PC / DB / 기능 서버 / DMZ / 모니터링 Zone을 분리하고 VyOS 방화벽으로 제어했습니다.
- MariaDB Master-Slave 이중화: Binary Log 기반 복제로 Primary 장애 시 데이터 손실 방지
- Bastion Host: 외부에서 내부 서버 SSH 직접 접근 차단, Bastion만 외부 SSH 허용
- 방화벽 INSIDE-OUT: 내부 서버의 외부 통신을 최소화 — 메일 서버(192.168.7.67)만 외부와 통신 허용
- 로그인/회원가입 웹 페이지, 실험 기록 사이트(내부 직원 전용) 구축
보안 아키텍처 요약
Bastion Host & OOB (Out-of-Band)
Bastion Host는 외부에서 내부 인프라에 접근하는 유일한 경유 서버입니다. 모든 Edge에서 이 원칙을 일관되게 적용했습니다.
OOB(Out-of-Band) 관리망은 서비스 트래픽과 물리적·논리적으로 분리된 관리 전용 네트워크입니다. 서비스망이 다운되어도 관리망을 통해 장비에 접근하고 복구할 수 있습니다.
통합 관제 — Syslog + Cockpit + SNMP
- Syslog (rsyslog): 모든 서버의 시스템 로그를 중앙 Syslog 서버(
192.168.6.129/192.168.13.37)로 실시간 전송 - Cockpit: 웹 기반 시스템 관리 도구 — CPU, 메모리, 네트워크 트래픽을 단일 대시보드에서 모니터링
- NMS (SNMP): 라우터에 SNMP Read-only 권한 설정, NMS 서버에서 장비 상태 중앙 조회
핵심 설계 결정 근거
왜 VyOS인가?
VyOS는 오픈소스 네트워크 운영체제로, CLI 기반 설정이 Cisco IOS와 유사하면서도 리눅스 기반이라 자유도가 높습니다. 방화벽, NAT, VPN, 라우팅을 단일 OS에서 모두 처리할 수 있어 소규모 보안 네트워크 구축에 적합합니다. 상용 장비 없이도 엔터프라이즈 수준의 기능을 구현할 수 있다는 점도 선택 이유였습니다.
왜 WireGuard인가? (IPsec / OpenVPN 대신)
IPsec은 설정이 복잡하고, OpenVPN은 TLS 오버헤드가 큽니다. WireGuard는 커널 레벨에서 동작하고 코드베이스가 작아 성능과 보안 감사 면에서 모두 유리합니다. VPN을 경유한 SSH 터미널 작업에서도 지연이 거의 없는 쾌적한 관리 환경을 제공했습니다.
왜 LDAP으로 중앙 인증을 구성했는가?
5개 Edge가 각자 메일 서버를 운영하는 구조에서, 사용자 계정을 각 Edge마다 개별 등록하면 계정 수만큼 관리 포인트가 늘어납니다. LDAP 중앙 디렉터리 하나로 통합하면 계정 관리가 단순해지고, 사용자가 어느 Edge에서든 동일한 자격증명으로 인증받을 수 있습니다.
왜 NAS에 소프트웨어 RAID 1을 구성했는가?
하드웨어 RAID 컨트롤러 없이도 Linux mdadm으로 RAID 1(미러링)을 구성하면 디스크 한 개가 고장나도 데이터가 보존됩니다. 연구 데이터처럼 재생산이 어려운 중요 데이터를 다루는 환경에서 비용 없이 구현할 수 있는 가장 기본적인 데이터 보호 수단입니다.
기술 스택 요약
| 분류 | 기술 | 버전 / 세부사항 |
|---|---|---|
| 게이트웨이 OS | VyOS | 1.3.5 (각 Edge 중앙 라우터) |
| 라우터 OS (Edge B) | Cisco IOS | HSRP, ACL, Static Routing, NAT |
| 하이퍼바이저 | VMware Workstation Pro 17 | 가상 환경 전체 |
| 서버 OS | Rocky Linux 9.7 | 모든 서버 VM |
| VPN | WireGuard | 지사 간 Site-to-Site, Split Tunneling |
| 방화벽 정책 | VyOS firewall / Cisco ACL | White-list, default-action drop |
| 웹 서버 | Apache 2.4 + PHP 8.0 | 인프라 관제 대시보드, 서비스 웹사이트 |
| DB | MariaDB 10.5 | Master-Slave 이중화 (Edge D), Adminer 웹 관리 |
| 메일 | Postfix (SMTP) + Dovecot (POP3/IMAP) | 각 Edge 메일 서버 + 중앙 릴레이 |
| DNS | BIND (named) | 중앙 + 각 Edge 로컬 DNS, MX 레코드 |
| 인증 | OpenLDAP | 중앙 집중형 사용자 계정 관리 |
| 시간 동기화 | chrony (NTP) | 전체 서버 시간 동기화 |
| 스토리지 | 소프트웨어 RAID 1 (mdadm) + Tiny File Manager | NAS 서버 |
| AI 환경 | Jupyter Notebook (Anaconda) | GPU 서버, 원격 접속 |
| 모니터링 | Syslog(rsyslog) + Cockpit + SNMP(NMS) | 중앙 집중형 통합 관제 |
| 고가용성 | VRRP (VyOS/Keepalived) / HSRP (Cisco) | 게이트웨이 이중화, DNS-LDAP Standby |
회고 — Project Story
왜 만들었나
부트캠프에서 처음으로 팀 단위로 진행한 프로젝트였습니다. 네트워크를 배우기 시작한 지 얼마 안 된 시점에 “실제 보안 네트워크를 설계하고 구현해라"는 과제가 주어졌습니다.
처음 든 질문은 “사용자들이 더 편리하게 업무를 수행하면서도 안전하게 보호받으려면 네트워크를 어떻게 설계해야 하는가"였습니다. 그 질문을 중심에 놓고 Zone 분리, 방화벽 정책, VPN, 이중화를 하나씩 쌓아 올렸습니다.
어떻게 만들었나
첫 번째 고생은 VLAN 설계의 반복 수정이었습니다. Edge B에서 VLAN 기반 서브넷 분리를 처음 시도했을 때, VLAN과 라우팅, NAT, 방화벽 정책이 동시에 맞물리면서 ARP 미완성과 통신 단절이 반복됐습니다. 결국 VLAN 중심 설계를 포기하고 방화벽 정책 중심 트래픽 제어로 전환했는데, 이 결정 자체가 중요한 공학적 판단이었습니다.
두 번째 고생은 지사 간 메일 연동이었습니다. 5개 Edge의 메일 서버가 서로 다른 사설망에 있는 상태에서 중앙 릴레이와 LDAP을 거쳐 메일이 정상 배달되려면, DNS MX 레코드 / LDAP 계정 동기화 / NAT 포트 포워딩 / 방화벽 허용 규칙이 모두 맞아야 했습니다. 각 계층을 하나씩 뜯어보며 원인을 찾아가는 과정에서 네트워크 디버깅 감각이 생겼습니다.
세 번째 고생은 처음 해보는 것들이었습니다. 웹 페이지 제작, Jupyter 원격 접속 설정, CCTV API 연동, SNMP NMS 구성 — 수업에서 배우지 않은 것들을 직접 찾아가며 구현했습니다. 계획과 달라진 부분도 있었고 GNS3의 기술적 제약으로 구현하지 못한 기능도 있었지만, 그 과정에서 “어떻게 모르는 것을 찾아내고 적용하는가"를 배웠습니다.
뭘 배웠나
네트워크 보안은 기술의 나열이 아닙니다. 방화벽 규칙 하나, ACL 한 줄의 위치와 순서가 전체 통신 흐름을 바꿉니다. 설정이 맞는데 왜 안 되는지를 추적하려면 트래픽이 어떤 경로로 흐르는지 머릿속에 그릴 수 있어야 합니다.
그리고 팀 프로젝트에서는 소통이 기술만큼 중요합니다. 5명이 각자의 Edge를 작업하면서 전체 구조를 이해하지 못하면 연동 지점에서 반드시 문제가 생겼습니다. 기술적 역량뿐 아니라 자신의 구성을 다른 사람이 이해할 수 있게 설명하는 능력이 프로젝트 완성도를 좌우했습니다.
이 프로젝트를 통해 제 강점과 약점이 명확해졌고, 그것이 2차 프로젝트에서 무엇을 더 깊이 파야 하는지를 알게 해준 중요한 기준점이 됐습니다.