Record

대학 캠퍼스 인프라 구성 ( 네트워크, 서버 프로젝트 ) 본문

프로젝트

대학 캠퍼스 인프라 구성 ( 네트워크, 서버 프로젝트 )

now-record 2026. 1. 27. 16:36
반응형

 

열심히 학원을 다니면서 네트워크 관련 기술들을 이것저것 배우고 있다. 

 

네트워크와 서버 기초적인 것을 배웠고 , 팀을 이루어서 같이 프로젝트를 진행하게 되었다. 

 

팀원은 총 4명으로 PM, PL, 팀원 2로 구성되어있다. 이 작은 팀에 pm이고 pl이고 무슨 의미인가 싶지만 그래도 역할을 나눠서 진행하기로 했다. 

 

1. 프로젝트 개요 (Overview)

  • 주제: 온프레미스 기반 대학교 네트워크 망 구성 - 인터넷·인트라넷을 모두 지원하는 하이브리드 환경
  • 구조: 3개의 캠퍼스(인천, 부산, 광주)와 이를 통합 관리하는 1개의 중앙 서버로 구성
  • 핵심 컨셉: 각 캠퍼스는 인트라넷 기반으로 내부 서비스를 독립 운영하며, 중앙 서버에서 DNS 및 로그를 통합 관리하는 온프레미스 하이브리드 구조

2. 클라이언트 요구사항 분석 (Requirements)

실제 대학교 네트워크 담당자의 관점에서 핵심 요구사항을 도출

  • 사용자 편의: 학생 및 교직원의 원활한 웹서핑, 클라우드, 메일 사용 보장
  • 보안 강화: 캠퍼스 간 내부 메일 통신 제한 및 유해 사이트 차단
  • 비용 절감: 예산 절감을 위한 공인 IP 사용 개수 최소화

3. 적용 기술 및 솔루션 (Tech Stack)

  • 하이브리드 네트워크 구조: 인터넷과 인트라넷 환경 동시 지원

 

1. Split Horizon DNS

캠퍼스 간 내부 통신은 보장하되 외부 정보 노출은 차단하는 보안 환경 구축

  1. 클라이언트 → (지사) DNS 로 질의
  2. 그 후 클라이언트에게 해당하는 ip를 찾아옴
  3. 그 후 그 ip로 접속

 

  1. 현재 외부에서 인천의 웹사이트를 접속하기 위해선 192.168.18.2의 ip가 필요하다.
  2. 그렇게 하기 위해 10.18.0.10 → 192.168.18.2로 DNAT를 걸어둔 상황
  3. 여기서 관점이 외부와 내부로 나뉜다.
  4. 외부의 관점에서는 Incheon이라는 ip를 찾기 위해서 먼저 10.11.0.11(DNS→192.168.53.3으로 nat되있음)을 찾는다.
  5. 그러면 Incheon의 ip인 10.18.0.10을 찾고 다시 외부에 있는 client에게 들어간다.
  6. 그 후 다시 10.18.0.10으로 접속하면 incheon도메인으로 들어갈 수 있다.

하지만 문제는 내부에서 생긴다.

  1. 내부에서 ip를 찾기 위해 똑같이 dns서버에 갔다가 incheon의 ip인 10.18.0.10을 찾아온다.
  2. 그 후 incheon으로 접속하려고 하는데 우리가 외부처럼 기대하는 10.18.0.10 → 192.168.18.2를 기대한다.
  3. 하지만 실제 로직은 192.168.53.x대역대에서 10.18.0.10으로 가고 우리가 설정한 규칙은 외부 eth0번에서 들어올때 192.168.18.2로 가는것이지 지금 상황에서는 eth2번이나 내부의 ethernet으로 규칙을 설정해주지 않으면 요청은 10.18.0.10에서 멈추게 된다.
  4. 그렇기 때문에 내부에서 요청했을때 내부의 사설 ip인 192.168.18.2를 가져오거나 내부의 이더넷 eth2번에 nat를 걸어줘야한다.

Split horizon

2가지 방법중 내부의요청과 외부의 요청을 다르게 하는 것을 하기로 설정하기로 함

why 밖으로 나가는 라우터의 nat설정이 너무 많으면 라우터 관리가 어렵다고 생각했기 때문

split horizon의 경우 질의가 외부랑 내부일때 view를 만들어서 다른 ip를 주게 만듦

 

2. CentOS 기반 방화벽VyOS 투명 브릿지(L2)

  • 기존 네트워크 구조 변경 없이 보안 기능을 추가하고 공인 IP 사용 최소화

 

3. Vastion 설정 및 기능 

 

4. Monitoring server 구축  

  • 데이터 수집: 각 노드의 Node Exporter와 promethus를 통해 CPU, 메모리, 트래픽 정보 수집
  • 대시보드: Grafana를 통해 장애 징후를 사전 포착하고 리소스 사용량을 분석,
  • k6를 통해 트래픽 발생유도 후 분산처리 시행 

 

4. 느낀점 및 소감 

음 일단 1달이라는 시간이 굉장히 빠르게 갔다. 프로젝트 특성 상 걍 많이 아는사람이 PL이 되는데, 어쩌다보니 전공자 비스무리한 내가 맡아서 하게 되었다. 이것저것 하고 싶은건 많았지만, 팀원들 특성상 내 욕심을 부리기에는 프로젝트가 산으로 갈꺼 같아서 그냥 각 지사를 하나씩 맡기고 내가 중간에서 이슈가 생기면 트러블 슈팅을 하는 느낌으로 갔다. 

 

 

트러블슈팅 많이 되긴했다. 스트레스도 많이받고 ㅋㅋㅋㅋ

그래도 팀들중에 우리가 제일 화목?하지 않았나 싶다. 다행이도 프로젝트는 항상 많이 해왔으니 문서작업도 미리미리 시키고 일정도 데드라인 3일전에 끝내는걸로 딱 맞춰서 힘 떨어질때쯤 마무리 잘끝낸거같다.

 

좀 아쉬운점은 네트워크 설계라는거 자체를 처음해봐서 좀 어영부영한거? 사실 서버를 만들고 하는거는 큰의미가 없고 이서버가 죽지 않게 아니면 어떤 요청이와서 뭘 더해야하는지 이게 중요한거 같은데 그냥 이거 만들어봤어요 저거 해봤어요 약간 이렇게만 끝난거 같다. 

다음에 한다면 약간 빅데이터에 대한 DB 분산처리 , 대규모 트래픽에 의한 실시간 선착순 시스템 처리 이런것도 좀 만들어봐야겠다. 보니까 Redis랑 Kafka가 이런데 쓰이는데, 왜쓰이고 뭐가 좋고 왜 해야하고를 잘 파악해야할꺼같다.

 

끝내는 이플젝에서 왜 이구조를 택했어요 라고 하면 내가 할말이 있어야하니까... 

 

후에 정리한거 깃링크로 돌아오겠다.