김마늘의 테크 레시피

 지난 포스팅에서 이어집니다. 처음 보시는 분들은 지난 포스팅을 참고해 주시기 바랍니다.

 우선 구축이 완료된 모습입니다. 생각보다 좀 과한 규모가 되었습니다. 총 6대의 물리 서버와 방화벽/라우터 역할을 겸하는 미니 PC, L2 스위치와 관리자 전용 무선 Access Point를 제공하는 공유기까지... 많은 시간과 금액이 들었습니다. 그리고 생각보다 많은 시행착오를 격였습니다. 그 내용을 한번 공유해 보고자 합니다.

확장을 위해 고려했던 사항들

 인프라 확장 진행하면서 많은 것들을 고려했습니다. 하드웨어 스펙부터, 네트워크 설계, 보안, 운영 방식, 소음, 발열, 전력... 정말 작은 데이터 센터를 구축하는 느낌이었습니다. 다시 한번 클라우드 서비스를 하기 위해서 고려해야 할 사항이 얼마나 많은지 느꼈습니다. 그중 중점적으로 고려했던 사항들에 대해서 설명을 드려봐야 할 것 같습니다.

1. 서버 스펙

 앞선 포스팅에서도 언급했지만, '약 10 - 20개 규모의 중소규모 Kubernetes 클러스터를 통시에 운영할 수 있는 규모의 인프라 구축'을 목표로 하였고 그에 준하는 하드웨어 스펙이 필요했습니다. 소규모와 중규모 Kubernetes 클러스터의 서버 사양은 아래와 같이 계획했습니다.

 소규모 클러스터는 개발 및 테스트 용도로, 중규모 클러스터는 실제 서비스를 배포하고 운영하는 용도입니다. 소규모 클러스터를 4개, 중규모 클러스터를 3개 운영한다고 가정하면 총 128 vCPU/322GB RAM/2680GB Storage 리소스가 필요합니다. 그렇다면 10 - 20개 규모를 운영하려면? 아... 정말 엄청난 하드웨어 스펙이 필요하더군요. 어쩔 수 없이 비용과 스펙 사이에서 타협을 했습니다. 그래서 최종적으로 다음 항목들을 기준으로 서버를 구성했습니다.

• 기존에 가지고 있던 서버 2대를 6대까지 증설
• 각 서버의 RAM를 64GB로 업그레이드
• USB 이더넷 랜카드를 통해 Storage 전용 네트워크를 구성

 이렇게 하면 CPU는 총 48 코어 96 스레드로 보통 가상화 환경에서 생각하는 vCPU:CPU 압축비인 3:1 내지는 4:1 정도에서 144 - 192 vCPU를 사용할 수 있어 충분하다 판단했습니다. 문제는 메모리와 네트워크였습니다. 우선 메모리의 경우 가상화 환경이라 할지라도 1:1 비율로 사용하는 것이 일반적이며 64GB * 6EA를 해도 384GB밖에 나오지 않습니다. 중규모 클러스터 하나에 메모리 요구량이 72GB나 되었기 때문에 기껏해야 클러스터 5개 정도밖에는 구동할 수 없는 수준이었습니다. 서버를 증설하면 문제는 해결되겠지만, 역시 가장 큰 걸림돌은 예산이겠죠. 거기다가 공간도 문제이고, 네트워크와 스토리지의 한계도 무시할 수 없었습니다.

 서버당 네트워크 인터페이스를 2개 사용할 계획이었기 때문에 물리적으로 2개의 포트가 필요했고, 이미 6대의 서버를 사용하게 되면 12개의 포트, 거기다가 NAS가 사용할 포트와 업링크 등을 생각하면 홈 랩 수준에서는 너무 고사양의 스위치가 필요했습니다. 게다가 서버가 늘어나고 거기에 호스팅 되는 VM이 늘어날수록 스토리지에서 오는 병목도 무시할 수 없는 수준이 될 것이었습니다. 서버는 최대 1 Gbps로 구성된 스토리지 전용 네트워크를 사용하고, NAS는 관리용이 아닌 스토리지용으로 3개의 네트워크 인터페이스를 LACP로 구성한다 해도 그 한계는 명확했습니다.

 거기다 발열이나 전기료 같은 것도 생각해야 했기에 마냥 서버를 증설하는 것은 한계가 있고, 이 정도 수준도 홈 랩에서는 충분히 과한 수준이기에(사실 이전 회사에서는 이보다도 못한 서버에서도 서비스를 구현하기도 했고...) 더 이상 서버를 추가하기보다는 6대로 최대의 효율을 뽑아내는 쪽으로 방향을 정했습니다.

2. 네트워크 고도화

 네트워크 역시 이제는 조금 더 고도화가 필요했습니다. 앞선 포스팅에서의 기본적인 홈 랩 환경에서는 네트워크 최상단에 ipTIME 공유기를 사용하였습니다. 물론 작은 규모에서는 크게 문제가 없었고, 네트워크 분리를 위해서 VM을 통해 오픈소스 방화벽인 OPNsense를 활용하기도 했지만 규모가 확장되면서 네트워크 환경 역시도 변화가 필요했습니다.

 우선 방화벽 및 라우터 역할을 수행할 수 있는 최상단 장비가 필요했습니다. 이전 홈 랩 구축에 사용해 보았던 OPNsense를 VM이 아닌 물리 장비로 구축하여 방화벽과 라우터 역할을 수행하도록 하였습니다. 이미 가상머신으로 구성 및 간단한 운영을 해본 상태라 크게 어렵지 않았습니다. 물리 장비 선택과 OPNsense에 관한 자세한 내용은 아래 포스팅을 참고해 주시면 감사하겠습니다.

 OPNsense는 정말 강력한 기능을 가지고 있습니다. 이를 통해 일반적인 인터넷 서핑 및 업무를 위한 Wi-Fi용 무선 네트워크와 서버 및 인프라 관리를 위한 네트워크, 가상머신을 위한 네트워크와 스토리지 전용 네트워크, 또 서비스를 위한 네트워크 등 다양한 네트워크를 손쉽게 구성할 수 있었습니다.

 또한 늘어난 서버에 물리적인 네트워크 인터페이스 제공을 위해서 L2 스위치 역시 필요하게 되었습니다. 중점적으로 본 기능은 LACP와 VLAN, 그리고 편리한 사용자 인터페이스를 제공하느냐는 것이었습니다. 물론 네트워크 인터페이스는 최소 1 Gbps 이어야 했고, 16개 이상이 필요했습니다. 가격 역시 저렴하면 더 좋구요. 메이저급 밴더사의 제품은 너무 비쌌거든요. 그래서 찾아낸 제품이 바로 TP-Link사의 TL-SG2218입니다.

 기본적인 기능에 충실하면서도 저렴한 가격, 그리고 사용하기 쉬운 Web 형식의 사용자 인터페이스와 CLI 모두 지원하는 것이 매우 매력적으로 보였습니다.

 물리 장비로 구축한 방화벽 겸 라우터 역할을 하는 OPNsense와 꼭 필요한 기능을 제공하는 Managed L2 스위치를 통해서 물리적, 논리적 네트워크를 원하는 형태로 구현하였습니다. 네트워크 간 접근에는 필요한 구간에 필요한 단말만이 접근할 수 있도록 방화벽 규칙을 설정하여 최소한의 접근 제어와 보안을 구현해 냈습니다.

3. 스토리지 업그레이드

 Synology의 NAS에는 여러 가지 기능이 있는데 이 중 블록 스토리지를 제공하는 기능인 iSCSI가 제가 구축하려는 홈 랩에서는 매우 중요한 역할을 하였습니다. 서버가 늘어나서 이전보다 더 많은 수의 VM을 동시에 운영할 예정이기 때문에 기존 HDD기반의 NAS의 스토리지로는 한계가 있다고 판단하였습니다. 그래서 2.5인치 SATA SSD를 하나 더 구입하여 총 3개의 SSD를 RAID 5로 구성하고 이를 iSCSI를 통해 블록 스토리지로 제공하기로 하였습니다. 네트워크 대역폭을 위해 3개의 네트워크 인터페이스를 LACP로 구성하여 iSCSI를 서비스하는 용도로 사용하고, 나머지 하나는 관리를 위한 네트워크 인터페이스로 사용하기로 결정합니다.

 NAS 모델이 워낙 구형인 데다, 네트워크의 한계로 그다지 뛰어난 성능은 아니지만, 그래도 간단한 워크로드 정도는 구동할 수 있는 수준의 환경을 구성하였습니다.

실 구축에 어려웠던 점들

Everyone has a plan, 'till the get punched in the mouth.
누구나 그럴싸한 계획을 가지고 있다. 쳐 맞기 전까지는...
- 마이클 타이슨 -

 네 맞습니다. 저도 그랬습니다. 개념적인 설계는 완벽하다고 생각했습니다. 하지만... 실 구축에 많은 장애를 겪게 됩니다. 그중 가장 대표적인 게 바로 아래 USB 확장 이더넷 어뎁터의 MTU 설정 문제입니다.

 이 외에도 가상 네트워크와 물리 네트워크 간 VLAN 연동, NAS에 추가 네트워크 인터페이스 설치(재부팅 시 네트워크 설정이 날아가는 현상 때문에 포기), 내부 DNS/DHCP 세팅에 나타났던 여러 문제점들... 여러 가지 문제가 수없이 발생했습니다. 그럼에도 불구하고 현재는 제법 안정 적힌 환경을 구축하였고 많은 테스트와 서비스를 할 수 있는 인프라를 구축하였습니다.

그래도 얻은 게 많은 홈 랩 구축

 그럼에도 불구하고 홈 랩을 구축하면서 정말 많은 부분을 이해할 수 있었습니다. 장비 구입부터 시작하여, 네트워크 설계 및 구축, 트러블 슈팅을 통한 각 종 기술적인 이해도 향상, 그 외에 운영 방침 설정 및 실 운영에서 겪게 되는 여러 가지 시행착오들... 이런 경험들은 정말 값진 경험이라 할 수 있겠습니다.

 앞으로 이 홈 랩 인프라를 통해서 여러 가지를 테스트해보고 실제 서비스도 만들어볼 생각입니다. 물론 엔터프라이즈 급의 운영과는 확연한 차이가 있을 것이기에 이것이 곧바로 실전적인 경험은 아닐 수 있으나, 그럼에도 불구하고 많은 통찰을 얻을 수 있는 재미난 시도가 아닌가 생각합니다.

 아무래도 이번 홈 랩 구축기는 용두사미의 포스팅이 되는 거 같습니다. 이렇게 큰 주제보다는 작은 주제들에 대해서 좀 더 심도 있게 다뤄보는 쪽으로 방향을 설정할까 합니다. 부족한 포스팅 읽어 주셔서 감사합니다.

 지난 포스팅 OPNsense로 방화벽 구축하기 [2편]에서 이어집니다. 2편을 먼저 읽어보시길 추천드립니다.

 이전 포스팅에서 새로운 인터페이스를 생성하고 모든 트래픽을 허용하는 규칙을 통해 서로 다른 네트워크에 있는 호스트 간의 통신을 확인해 보았습니다. 이번 포스팅에서는 본격적인 방화벽 규칙 설정에 대해 다뤄보도록 하겠습니다.

In & Out

 방화벽 규칙을 생성할때 가장 많이 헷갈리는 요소가 바로 트래픽의 방향일 것입니다. 방화벽 규칙 리스트에 화살표 모양으로 표시되는 것으로 오른쪽(→) 화살표는 In을, 왼쪽(←) 화살표는 Out을 의미합니다.

 방화벽 규칙을 생성할때 Direction의 툴팁을 읽어보면 아래와 같습니다. 'IN'은 방화벽 인터페이스로 들어오는 트래픽을 의미하는 것이고, 'OUT'은 방화벽 인터페이스에서 나가는 것을 뜻한다고 하는데, 물론 아주 훌륭한 설명이고 사실 이게 핵심이긴 하지만 그럼에도 다소 애매한 면이 있습니다.

Direction of the traffic. Traffic IN is coming into the firewall interface, while traffic OUT is going out of the firewall interface. In visual terms: [Source] -> IN -> [Firewall] -> OUT -> [Destination]. The default policy is to filter inbound traffic, which means the policy applies to the interface on which the traffic is originally received by the firewall from the source. This is more efficient from a traffic processing perspective. In most cases, the default policy will be the most appropriate.

 특히, 방화벽 규칙 적용시 많이 혼동하는 부분이 바로 방화벽 내부에서의 트래픽 흐름입니다. 결론부터 말씀드리자면 이는 전혀 고려할 필요가 없습니다. 아마 이런 혼동이 오는 이유가 방화벽 장비와 그 인터페이스를 분리해서 생각하기 때문일 것입니다. 아래 그림을 보면서 이야기해 봅시다.

 만약 'Host 1'에서 'Host 2'로 통신을 한다고 가정해 봅시다. 그럼 보통 (1)'Host 1'에서 출발한 트래픽이 'LAN 1' 포트에 도착, (2)'LAN 1' 포트에서 'LAN 2' 포트로 트래픽 전달, (3)'LAN 2'포트에서 'Host 2'로 트래픽 전송이라는 방식으로 생각할 것입니다. 이 생각은 너무나도 타당합니다. 그렇다면 여기서 어떤 것이 'IN'이고 어떤 것이 'OUT'인 트래픽일까요? (1)은 'IN'이 확실한것 같습니다. 그리고 (3)은 'OUT'이 확실한것 같구요. (2)가 좀 애매하네요. 'LAN 1'에서 출발하니 'OUT'인 것 같기도 하고... 'LAN 2'에 도착하고 있으니 'IN'이 아닌가 싶기도 합니다.

 정답은 (2)는 생각하면 안된다는 것입니다. (2)는 방화벽 내부에서 흐르는 트래픽으로 'IN'도 'OUT'도 아닙니다. 고려의 대상이 아니라는 것이죠. 방화벽에서 'IN'과 'OUT'을 구분하는 기준은, 철저히 방화벽의 입장에서 바라 보았을때 트래픽이 어떻게 흐르냐는 것입니다.

 즉, 방화벽으로 향하는 트래픽은 모두 'IN'으로 인식하면 되고 방화벽 밖으로 빠져나가는 트래픽은 'OUT'으로 인식하면 된다는 것입니다. 방화벽 내부에서 움직이는 트래픽은 전혀 'IN', 'OUT'에 대해 고려할 필요가 없다는 것이죠. 이를 단순화하면 아래 그림과 같습니다.

 철저하게 방화벽으로 향하는 트래픽은 모두 'IN'으로 인식하고 방화벽에서 출발하는 트래픽은 모두 'OUT'으로 이해하면 된다는 것이죠. 이러한 개념에 대한 이해를 돕는 영상을 하나 추천드립니다.

인바운드는 'All deny', 아웃바운드는 'All pass'

 방화벽 규칙을 적용할때는 'IN' 즉, inbound(인바운드) 규칙을 생성하는 것이 가장 기본적이며 일반적인 접근법입니다. 그 이유는 인바운드 규칙을 통해 외부 네트워크에서 내부 네트워크로 들어오는 트래픽을 제어할 수 있기 때문입니다. 기본적으로 WAN 인터페이스나 새로 생성된 인터페이스의 경우에는 초기에 아무런 규칙(자동 설정 규칙 제외)이 설정되어 있지 않습니다. 그 이유는, 아무런 규칙이 설정되어 있지 않는 경우 방화벽은 기본적으로 인바운드 트래픽에 대해서는 'All deny' 정책이 적용되기 때문입니다.

 외부와의 경계가 되는 WAN 인터페이스의 경우 인바운드 트래픽에 대해서 'All deny' 정책이 기본이 되어야 하는 것은 당연하다고 할 수 있겠습니다. 반대로 'OUT' 즉, outbound(아웃바운드)의 경우에는 기본적으로 트래픽이 통과되도록 되어 있습니다. 역시 이러한 설정 때문에 WAN 인터페이스에 아무런 규칙이 없어도 내부의 호스트들이 외부 인터넷과 통신이 가능했던 것입니다.

기본적인 방화벽 규칙

 그럼 몇가지 기본적인 방화벽 규칙에 대해서 살펴보도록 하겠습니다. 이러한 규칙을 잘 조합하거나 응용하면 원하는 환경에 맞는 방화벽 규칙을 생성할 수 있을 것입니다.

1. 특정 네트워크로의 접근을 허용

 우리의 실습 환경에서 Internal 인터페이스에 할당된 네트워크인 192.168.11.0/24에서 LAN 네트워크인 192.168.1.0/24로 접근을 허용해 보겠습니다. 왼쪽 메뉴에서 Firewall > Rules > Internal로 이동합니다. 화면 오른쪽에 '+' 아이콘을 눌러 새로운 규칙을 생성합니다.

  Action은 Pass로 지정합니다. Interface는 해당 룰이 적용되는 인터페이스를 의미하며 현재 우리는 Internal 인터페이스에 이 룰을 적용시킬 것이므로 기본으로 설정되어 있는 Internal을 그대로 둡니다. Direction은 in으로 설정합니다. 혹시나 192.168.11.0/24 네트워크에서 192.168.1.0/24로의 접근이니까 192.168.11.0/24에서 나가는 트래픽이라고 생각해서 out으로 설정하면 안 됩니다. 다시 한번 강조하면, 방화벽 규칙은 철저하게 방화벽 입장에서 생각해야 한다는 것입니다. 방화벽 입장에서는 192.168.11.0/24 네트워크에서 출발한 트래픽이 들어오는 것이므로 in이 맞습니다. TCP/IP Version은 IPv4로, Protocol은 any로 둡니다.

 Source의 경우 드롭다운 메뉴를 보면 여러 가지 카테고리가 나옵니다. Network 카테고리에는 방화벽 인터페이스 이름이 나타나며, 각 인터페이스는 하나의 네트워크를 의미합니다. 각 인터페이스마다 net과 address가 존재하는 것을 볼 수 있는데 여기서 net은 해당 인터페이스에 할당된 네트워크 전체를 의미하며 address는 해당 인터페이스의 주소, 그러니까 Internal address의 경우 192.168.11.1을 의미합니다. 지금 설정하려는 방화벽 규칙은 192.168.11.0/24 네트워크에 속한 호스트들이 192.168.1.0/24 네트워크의 호스트와 통신을 해야 하므로 Internal net으로 설정해야 합니다. Destination의 경우 192.168.1.0/24 네트워크 즉, LAN net을 선택합니다.

 그리고 하단에 Save 버튼을 누르면 다시 이전 화면으로 돌아오면서 방금 설정한 규칙이 해당 인터페이스에 생성된 것을 확인할 수 있습니다. 그리고 화면 우측 상단에 Apply changes라는 버튼이 나타나는데 이는 방금 생성한 규칙을 실제로 적용하도록 하는 버튼으로 이것을 눌러주어야 규칙이 작동하기 시작합니다.

 이렇게 되면 Internal 네트워크에 속한 호스트들이 LAN 네트워크에 속한 호스트들과 통신을 할 수 있게 됩니다. 그리고 하나 더, 규칙이 많이 추가되면 해당 규칙이 어떤 용도였는지 혼란스러운 경우가 생길 수 있습니다. 따라서 규칙을 생성할 때 Description에 해당 규칙에 대한 설명을 적어 두는 것을 추천드립니다. OPNsense는 한글을 지원하므로 한글로 메모를 해둔다면 시간이 흘러도 해당 방화벽 규칙이 무엇을 위한 것이었는지 쉽게 파악할 수 있을 것입니다.

 규칙이 적용되면 위와 같이 192.168.1.0/24 네트워크의 게이트웨이 인터페이스(192.168.1.1), 그리고 Host-01(192.168.1.2)와도 통신이 잘 되는 것을 확인할 수 있습니다.

2. 특정 네트워크로의 접근을 차단

 차단 규칙의 설정은 앞선 접근 규칙의 설정에서 Action만 변경해 주면 됩니다. 기존 동작인 Pass에서 Block 또는 Reject 중 하나를 선택하면 됩니다. 두 선택지 모두 차단을 위한 규칙이지만 그 동작에는 약간의 차이가 존재합니다. Action의 툴팁을 살펴보면 아래와 같습니다.

Choose what to do with packets that match the criteria specified below. Hint: the difference between block and reject is that with reject, a packet (TCP RST or ICMP port unreachable for UDP) is returned to the sender, whereas with block the packet is dropped silently. In either case, the original packet is discarded.

 Block과 Reject에 대해서 비교를 해보면 아래와 같습니다.

 Block의 경우 완벽하지는 않지만(여러 우회 경로로 확인이 가능하기 때문) 서버의 존재를 숨길 수 있어서 보안적으로 유리한 점이 있습니다. 다만 어떤 요청을 하는 클라이언트가 그 응답에 대해서 타임아웃이 될 때까지 하염없이 기다리기 때문에 네트워크의 효율성 측면에서는 불리한 점이 있습니다.

 Reject의 경우 그 반대로, 즉각적인 오류 응답으로 네트워크의 효율성이 증가합니다. 단, 오류 응답이 있다는 것은 그곳에 무언가 응답의 주체가 있다는 뜻으로 해석될 수 있기 때문에 보안적인 측면에서는 다소 불리한 면이 있습니다.

3. 인터넷 연결은 허용하면서 Private Network 접근은 차단

 내부적으로 Private Network가 많이 존재한다고 가정해 보겠습니다(편의상 네트워크 A, B, C라고 칭함). 그리고 여기에 또 새로운 Private Network(네트워크 D라 칭함)가 생성되었다고 가정해 봅시다. 그런데 D 네트워크는 보안상 확실한 격리가 필요한 네트워크라서 기존 네트워크인 A, B, C와 서로 격리되어야 하며 그럼에도 불구하고 외부(인터넷)로는 빠져나갈 수 있어야 합니다.

 이런 경우에 방화벽 규칙을 적용한다고 해 보겠습니다. 우선 A 네트워크 인터페이스에 새로 생성된 네트워크 D로의 접근을 차단해야 하고, B와 C 네트워크 역시 이러한 규칙을 생성해야 합니다. D 네트워크는 인터넷에 대한 접근이 필요하므로 목적지를 0.0.0.0/0으로 하는 통과 규칙을 생성해야 하는데, 이렇게 되면 다른 Private Network에도 접근을 할 수 있게 됩니다. 만약 A, B, C 네트워크 역시 보안상 이유로 접근을 차단해야 한다면 D 네트워크의 규칙에도 각 네트워크에 대해서 접근 차단 규칙을 설정해야 합니다. 이 모든 것을 만족시키기 위해 단순 반복 작업인 네트워크 규칙 생성을 7번이나 수행해야 합니다. 거기다가, 네트워크가 10개, 20개로 늘어난다면? 이런 단순 반복 작업을 수동으로 수행해서는 답이 없습니다.

 Aliases와 Destination invert를 사용하면 이러한 문제를 해결할 수 있습니다. 우선 Firewall > Aliases 메뉴로 접근합니다. 여기 Private Network 주소에 대한 Alias를 생성합니다.

 위와 같이 Private Network에 대한 정보를 입력합니다. Type을 Network(s)로 하고 Content에 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16을 '콤마'로 구분하여 입력합니다. 그리고 저장한 후 다시 Firewall > Rules > Internal 메뉴로 이동하여 새로운 규칙을 생성합니다. 앞서 살펴본 '1. 특정 네트워크로의 접근을 허용'에서와 같이 Action은 Pass, Source는 해당 인터페이스의 net(Internal net)으로 설정합니다. 여기서 핵심은 Destination 설정입니다. 우선 Destination을 방금 Aliases에서 만든 PrivateNetwork로 합니다.

 그리고, Destination / Invert의 체크박스를 활성화합니다. 이렇게 되면 Destination에 대해서 반전이 일어납니다. 그럼 'Private Network를 목적지로 하는 패킷을 제외한 나머지' 패킷에 대해서만 Pass가 되고 나머지는 Block이 되게 됩니다. 이렇게 설정을 하게 되면 향후 다른 Private Network가 생성되어도 기본적으로 해당 네트워크에 대한 접근을 차단할 수 있게 됩니다. 그럼 앞서 예시로 들었던 새로운 번거로운 반복 작업을 피할 수 있게 됩니다.

4. 특정 호스트의 특정 포트 또는 서비스에 대한 접근을 허용

 방금 전 '3. 인터넷 연결은 허용하면서 Private Network 접근은 차단'에서 설정한 규칙으로 Host-02에서는 Host-01로 접근이 불가능합니다. 그러나 특정 호스트의 특정 포트나 서비스에 접근을 허용해야 한다면 어떻게 해야 할까요?

 이번에는 Host-02(192.168.11.2)에서 Host-01(192.168.1.2)의 웹 서비스에 접근해야 한다는 가정하에 방화벽 규칙을 생성해 보겠습니다. 다시 한번 Firewall > Rules > Internal로 이동합니다. 그리고 새로운 규칙을 생성해 줍니다. 역시 이번에도 Action은 Pass, Direction은 in, Source는 Internal net입니다. Protocol 설정부터 차이가 나는데 이번에는 http 연결이므로 TCP로 설정해 줍니다. 그리고 Destination은 Single host or Network를 선택합니다. 그러면 그 아래에 입력이 가능한 창이 활성화되는데 여기에 Host-01의 IP 주소인 192.168.1.2를 입력합니다. 그리고 Destination port range에 from과 to 모두 HTTP로 설정합니다.

 그리고 Save 한 후 Apply change를 잊지 말고 눌러주어 새로 생성된 방화벽 규칙이 잘 작동하도록 적용해 줍니다. 그리고 다시 curl 명령어와 웹 브라우저를 통해 Host-01의 웹 서비스에 접근이 가능한지 확인해 보면 아래와 같은 결과를 얻습니다.

 curl 명령어와 웹 브라우저는 문제없이 잘 작동하는 것을 확인할 수 있습니다. 하지만 ICMP 프로토콜을 사용하는 ping 명령어는 실패하는 것을 볼 수 있습니다. 이를 통해 특정 호스트에 대한 특정 포트나 서비스에 대한 접근을 허용하는 규칙도 알아보았습니다.

기본 규칙 정리

 지금까지 살펴본 규칙을 표로 정리하면 다음과 같습니다. 이를 기본으로 하여 여러 가지 규칙을 생성할 수 있을 것입니다.

 또한 방화벽에서 중요한 것은 규칙이 순서대로 적용된다는 것입니다. 인터페이스에 도착한 패킷은 첫 번째 방화벽 규칙부터 시작하여 차례로 검증을 하고 가장 먼저 매칭되는 규칙을 적용받게 됩니다. 따라서 규칙 적용 시 순서를 잘 고려해야 엉뚱하게 패킷이 드랍되거나 통과되는 것을 막을 수 있습니다.

 이번 OPNsense 시리즈 포스팅을 통해 OPNsense 설치부터 기본적인 사용법과 방화벽 규칙 적용하는 방법에 대해서 알아보았습니다. 이 외에도 OPNsense에는 DNS, DHCP, VPN과 같은 기능을 기본적으로 제공하며 BGP, HAproxy와 같은 다양한 기능들도 플러그인과 패키지로 제공하고 있습니다. 기회가 된다면 이러한 기능들도 꾸준히 포스팅해보려고 합니다.

 추가로 OPNsense 공식 문서와, 홈 랩 구성시 참고했던 Youtube 채널 링크를 남기고 포스팅을 마치겠습니다.

 앞선 포스팅 OPNsense로 방화벽 구축하기 [1편]에서 이어집니다. 1편을 먼저 읽어보시길 추천드립니다.

 지난 포스팅에서는 OPNsense를 사용하여 방화벽을 구축해 보았습니다. 이번 포스팅에서는 LAN 인터페이스의 초기 방화벽 규칙의 내용과, 새로운 인터페이스 생성과 방화벽 규칙을 적용하는 방법에 대해서 알아보겠습니다. 

LAN 인터페이스 방화벽 규칙 살펴보기

 OPNsense 최초 구축 시 생성되는 기본 LAN 인터페이스에 대해서 알아보겠습니다. 우선 좌측 내비게이션 메뉴에서 Interfaces를 클릭합니다. 그러면 [LAN]이라는 이름의 인터페이스를 볼 수 있습니다. 우선 이 인터페이스 정보를 한번 살펴보도록 하죠.

 우측 상단에 full help 토글을 활성화 하면 각 메뉴의 상세 설명을 확인할 수 있습니다. LAN 인터페이스는 생성될 때 기본적으로 IP주소를 192.168.1.1로 하고 있으며 Prefix는 24입니다. 앞선 포스팅에서 Host 1을 이 IP 대역에 위치시켜(192.168.1.2) 웹 UI를 통해 방화벽에 접속, 관리를 할 수 있는 기본이 되는 인터페이스입니다.

 본격적으로 방화벽 규칙을 살펴보도록 하겠습니다. 역시 왼쪽 내비게이션 메뉴에서 찾을 수 있습니다. Firewall > Rules > LAN으로 이동합니다. 그럼 아래와 같은 화면을 볼 수 있습니다.

 LAN 인터페이스의 경우에는 기본적으로 IPv4/IPv6 주소의 모든 소스에 대해서 모든 목적지로의 트래픽이 허용되어 있습니다. 이런 이유는 LAN 인터페이스가 기본이 되는 인터페이스인 데다가, Web UI 접속을 위한 인터페이스이기 때문이죠. 어쨌든, 화면에 표시된 IPv4 규칙을 살펴보면, 맨 왼쪽 녹색 삼각형은 현재 규칙이 활성화되어 있다는 뜻이고 왼쪽에서 오른쪽으로 향한 화살표는 방화벽으로 들어오는 방향의 트래픽에 대한 규칙이라는 뜻입니다. 그 외에 Port나 Destination에 '*' 표시는 'Any'의 의미로 모든 것을 의미한다고 이해하면 될 것 같습니다. 방화벽 규칙에 대한 편집은 오른쪽에 위치한 연필모양을 눌러주면 됩니다.

 그러면 위의 사진에서 보시는 바와 같이 구체적인 설정을 진행할 수 있는 인터페이스를 확인할 수 있습니다. 이는 대부분의 방화벽 설정과 거의 흡사하다고 보면 될것 같습니다.

새로운 인터페이스 할당

 다시 한번 우리가 처음에 생각했던 네트워크 토폴로지를 보면 OPNsense 방화벽에 또다른 단말인 Host2가 있습니다. 이 Host2는 완전히 다른 네트워크인 192.168.11.0/24에 위치해 있다고 해 봅시다. 그리고 OPNsense의 인터페이스가 해당 네트워크의 Gateway 역할을 수행하도록 해 봅시다.

 우선 OPNsense의 Web UI에서 해당 인터페이스를 할당하고, 활성화 하는 작업이 필요합니다. 왼쪽 내비게이션 메뉴에서 Interface > Assignments로 이동합니다. 그러면 아래와 같은 화면을 볼 수 있습니다. 현재 이 방화벽의 인터페이스 중 아직 할당되지 않은 유휴 인터페이스가 있다면 아래와 같이 선택하여 할당할 수 있습니다.

 앞서 방화벽을 생성할 때 추가로 생성한 네트워크 인터페이스인 vmx2를 방화벽에 할당하겠습니다. Description에 설명을 입력하면 해당 설명으로 Interface 이름을 지정할 수 있습니다. 이 포스팅에서는 Internal로 설정하겠습니다. Add 버튼을 눌러 인터페이스를 할당합니다.

 위와 같이 새로 할당된 인터페이스를 확인할 수 있습니다. 추가로 오른쪽에 휴지통을 누르면 해당 인터페이스의 할당을 해제할 수 있습니다. Save 버튼을 눌러 인터페이스 할당을 저장해 줍니다. 그러면 오른쪽 네비게이션의 Interface 메뉴에 [Internal] 인터페이스가 생성된 것을 볼 수 있습니다. 이를 클릭하여 인터페이스 설정을 해 봅시다.

 먼저 최상단의 Enable 체크박스를 클릭하여 활성화 시켜주면 해당 인터페이스가 활성화됩니다. 마치 Cisco 스위치에서 Port를 Up 하는 것과 같은 거라 보시면 되겠습니다. 이 인터페이스를 실수로 삭제하는 것을 막고 싶다면 아래 Lock 체크박스를 활성화해 줍니다. 그러면 앞서 보았던 Assiginments 화면의 인터페이스 목록 오른쪽에 보였던 휴지통 모양이 나타나지 않으면서 인터페이스를 삭제할 수 없게 됩니다.

 화면을 아래로 드래그하면 해당 인터페이스에 설정을 할 수 있습니다. 우선 상단의 Block private Networks는 말그대로 사설 네트워크 대역에 대한 접근을 막는 옵션으로, 현재 우리는 이 인터페이스를 사설 네트워크로 사용할 것이기 때문에 체크할 필요는 없습니다. 참고로 WAN 인터페이스의 경우 보안상의 이유로 사설 네트워크에서 접근하는 것을 막아두고 있습니다.

 아래에 보면 해당 인터페이스의 IP 주소 타입을 선택할 수 있는데 우리는 IPv4의 Static 형식을 사용하도록 하겠습니다. 그 아래에는 MAC 주소 설정이나 MTU 설정등이 있는데 이는 따로 특별한 값을 입력하지 않고 그냥 넘어가도록 하겠습니다. 더 아래쪽으로 화면을 드래그하면 수동으로 해당 인터페이스의 IP 주소를 설정할 수 있는 화면이 나옵니다.

 앞서 이야기한 것 처럼 192.168.11.0/24 대역의 네트워크를 사용할 것이며, 이 인터페이스의 주소는 해당 네트워크의 게이트웨이 주소가 될 것입니다. 우리는 앞선 LAN의 인터페이스 규칙과 동일하게 '1'번을 IP 주소로 사용하겠습니다. 192.168.11.1을 입력해 주고, Prefix를 24로 설정합니다. 그리고 Save를 클릭하여 설정을 저장해 줍니다. 그리고 우측 상단에 나타나는 Apply changes 버튼을 눌러서 저장한 설정을 적용해 줍니다.

 이제 Host1(192.168.1.2)에서 Internal 인터페이스로 Ping 테스트를 해 봅시다. 해당 인터페이스가 잘 응답하는 것을 통해, 인터페이스 할당이 잘 이루어 진것을 확인할 수 있습니다.

Host2를 위한 방화벽 규칙 설정하기

 우선 Host2의 IP 주소를 192.168.11.2로, Gateway를 192.168.11.1로 설정합니다. 그리고 터미널을 실행해서 192.168.11.1로 Ping 테스트를 해 보겠습니다.

 그런데 이상합니다. 분명 같은 네트워크에 놓여있는 단말인데 자신의 Gateway 주소로 Ping 테스트가 실패합니다. 사실 그 이유는 새로 할당한 Internal 인터페이스의 방화벽 규칙 설정에 있습니다. 다시 Host1로 돌아와서 OPNsense의 Web UI로 접속합니다. Firewall > Rules > Internal로 이동합니다.

 화면에서 볼 수 있듯, 사용자가 Pass 규칙을 따로 설정하지 않으면 해당 인터페이스로의 모든 트래픽에 대해서 차단을 수행합니다. 이는 방화벽의 기본적인 작동 방식으로 특별한 규칙을 설정하지 않으면 기본적으로 All deny로 설정되어 있으며 그래서 앞서 Host2에서의 Ping 테스트가 실패한 것입니다. 그럼 먼저 모든 트래픽을 통과하는 규칙을 만들어 봅시다. 오른쪽의 빨간색 '+'을 클릭합니다. 그러면 기본적으로 모든 출발지에 대해서 모든 목적지를 가진 방화벽으로 향하는 트래픽(in 트래픽)에 대해서 허용하는 규칙을 확인할 수 있습니다.

 우선 이 규칙을 적용하기 위해 아래로 드래그하여 Save 버튼을 클릭한 후 Apply changes 버튼을 통해 규칙을 적용합니다. 이제 다시 Host2로 돌아가 Ping 테스트를 수행해 봅시다. 자신의 게이트웨이인 192.168.11.1로 Ping을 날려봅니다. 또한 google.com으로 Ping 테스트를 수행해 봅시다.

 둘다 아주 잘 작동하는 것을 확인할 수 있습니다. 게이트웨이 인터페이스인 Internal 인터페이스의 방화벽 규칙은, 인터페이스가 처음 생성되면 아무것도 적용되어 있지 않아 모든 트래픽을 거부하는 상태입니다. 방금과 같은 모든 트래픽을 허용하는 규칙을 적용하게 되면 Gateway 뿐만 아니라 외부와의 통신도 잘 되는 것을 확인할 수 있습니다.

 그러나, 이렇게 방화벽 규칙을 사용하면 사실상 방화벽을 사용하는 의미가 전혀 없게 됩니다. 모든 트래픽을 아무런 조건 없이 허용하기 때문입니다. 따라서 다음 포스팅에는 조금 더 복잡한, 혹은 고급의 방화벽 규칙 설정에 대해서 포스팅 해 보도록 하겠습니다.

▼OPNsense로 방화벽 구축하기 [2편]

 국내에도 생각보다 많은 분들이 홈 랩을 구축하고, 운용하고 있는 것으로 알고 있습니다. 베어메탈 환경에 직접 리눅스로 서버 환경을 구축할 수도 있지만, Hypervisor를 사용한다면 가상화를 통한 조금 더 유연한 인프라 환경을 구현할 수 있습니다. 저도 여러 Hypervisor들 중에 가장 익숙한 ESXi를 활용하여 인프라 가상화 환경을 구축하고 있습니다.

홈 랩의 숙명 - 하드웨어 호환성

 VMware ESXi는 네트워크 인터페이스에 대한 호환성에 많이 인색한 편입니다. 오로지 Intel의 컨트롤러만을 사용하는 네트워크 인터페이스를 지원하기 때문에 ESXi를 하이퍼바이저로 선정한 사람들에게 숙명적으로 따라오는 것이 이 네트워크 인터페이스에 대한 고민입니다. 저 역시도 여기에서 자유롭지 못했습니다. 사용 중인 미니 PC네트워크 인터페이스의 개수가 1개에, 컨트롤러는 리얼텍 r8168입니다.

 자세한 하드웨에 사양은 위 포스팅에 상세하게 작성해 두었는데... 어쨌든, 리얼텍 r8168을 사용하기 위해서는 ESXi 커스텀 드라이버가 설치된 ISO가 필요했고, 이를 위해 열심히 구글링 한 결과 다른 사람들도 이런 고민이 이미 예전부터 있었다는 것을 알 수 있었습니다. 그중 몇 가지 방법들을 시도해서 겨우 ESXi 커스텀 ISO를 만들어낼 수 있었습니다. 혹시 ESXi 커스텀 이미지를 생성하실 분들은 아래 자료를 참고해 주시면 되겠습니다.(저도 여러 번의 시도 끝에 6.7 버전으로 ISO 이미지를 생성하는 데 성공했습니다.)

홈 랩 인프라 확장과 네트워크 분리의 필요성

 문제는 다음입니다. 홈 랩 인프라가 확장되면서 VM들의 서비스 네트워크와 스토리지용 네트워크 분리가 필요해졌습니다. 문제는 서버가 미니 PC라 확장성이 제한적이라는 점이었습니다. 이를 위해 여러가지 방법을 찾던 중 VMware 진영에서는 홈 랩 인프라 구축에 신선과도 같은 William Lam의 게시글이나 구익환 님의 블로그 등을 참고하여 그 가능성을 발견하였고, 역시나 안 되는 게 없구나 라는 생각으로 ipTIME U1G를 구매하고 테스트해봤습니다.

 flings라는 VMware 사용자 커뮤니티에서 ESXi 버전에 맞는 커뮤니티 드라이버를 다운로드하고 설치를 진행했습니다. 자세한 방법이나 명령어는 아래 사이트를 참조했습니다.

 다행히도 ESXi에서 USB 어뎁터를 잘 인식하여 VM들의 서비스 네트워크와 스토리지 네트워크를 분리할 수 있는 가능성이 열렸습니다. 다만... 생각지도 못한 문제에 부딪힙니다.

VLAN과 MTU의 환장의 조합

 아무래도 홈 랩 환경이다 보니 스토리지 전용 스위치를 사용하기에는 비용문제도 있어 1대의 스위치에서 VLAN을 통해 논리적으로 네트워크를 구분하여 사용하려 했습니다. NAS의 iSCSI 타겟과 ESXi의 소프트웨어 iSCSI 어뎁터 간의 인식은 문제가 없이 잘 진행되었는데 디스크를 VMFS 형식으로 포맷하려고 하면 꼭 타겟이 유실되면서 제대로 작동하지 않는 것이었습니다. 이때 물리적 연결에 사용한 네트워크 인터페이스가 앞서 말씀드린 ipTIME USB 이더넷 어뎁터인데 여기에 치명적인 문제가 있었습니다.

 바로 VLAN 태그에 대한 오프로딩 기능이 없다는 점이었습니다. 정확히는 네트워크 드라이버의 문제인지, 어뎁터의 문제인지는 모르겠으나 어쨌든 여기에서 문제가 생긴다는 것이었습니다. 보통의 경우 MTU를 1500으로 설정한 상태에서 ping 테스트를 하면 최대 1472바이트까지 전송이 가능합니다. 그 이유는 ICMP 헤더 8바이트와 IP 헤더 20 바이트 때문인데, 만약 중간 구간에 VLAN까지 있다면 추가로 4바이트가 더 필요합니다. 보통의 경우 하드웨어 레벨에서 이를 오프로딩 처리하기 때문에 VLAN에 속한 호스트의 MTU가 1500이어도 문제가 없지만 그렇지 못한 경우에는 문제가 발생하게 됩니다.

 그에 대한 트러블 슈팅에 관한 자세한 내용은 위 포스팅을 참고해 주세요. 어쨌든 이런 이유로 외장 USB NIC의 경우 MTU를 1450으로 설정하니 iSCSI 타겟 유실과 같은 문제가 발생하지 않고 정상 작동하는 것을 확인할 수 있었습니다.

성능 욕심과 USB NIC의 뻥카

 그러던 중, 점보 프레임을 사용해 보면 어떨까 하는 생각을 하게 됩니다. 하지만 여전히 VLAN 구간을 지나므로 VLAN 태그 오프로딩 기능이 없다는 점을 감안하여 MTU 사이즈를 안전한 8000 정도로 사용해 보기로 했습니다. NAS의 네트워크 구성, 스위치의 MTU 사이즈, 분산 스위치의 MTU를 조정하고 테스트를 수행했습니다.

 우선 VMware vSphere에서는 분산스위치의 MTU 사이즈를 조절하면 그의 업링크 인터페이스의 MTU 사이즈 역시 같은 값으로 동기화됩니다. 이를 통해 외장 USB NIC에는 MTU 최대 사이즈인 9000이 되도록 하고 iSCSI 어뎁터의 종단점인 VMkernel의 MTU를 8000으로 조정하기로 합니다. NAS 쪽도 MTU 사이즈를 8000으로 맞춥니다.

#esxcli 명령어를 통해 nic의 MTU 상태를 확인

[root@esxi01:~] esxcli network nic list

Name    PCI Device    Driver  Admin Status  Link Status  Speed  Duplex  MAC Address         MTU  Description
------  ------------  ------  ------------  -----------  -----  ------  -----------------  ----  -----------------------------------------------------------------------------------------
vmnic0  0000:01:00.0  r8168   Up            Up            1000  Full    b0:41:6f:09:28:dc  1500  Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
vusb0   Pseudo        uether  Up            Up            1000  Full    58:86:94:31:6c:41  9000  Realtek USB 101001000 LAN

 위 내용에서 장치의 이름이 vusb0인 것이 바로 외장 USB NIC입니다. MTU 사이즈가 9000으로 조정된 것을 확인할 수 있습니다. 또한, VMkernel 어뎁터의 MTU는 8000인 것을 확인할 수 있습니다. 당연하게도 NAS 쪽의 MTU도 8000으로 조정을 하였습니다.

 이렇게 하니 우선은 iSCSI 연결에는 문제가 없었습니다. 그런데 그다음이 문제였죠. 앞선 상황과 같이 계속 iSCSI 타겟이 유실되는 것이었습니다. 처음에는 VLAN 태그 오프로딩 문제인가 싶어 미세하게 MTU를 조정해 보았지만, 역시나 제대로 작동하지 않는 것을 확인할 수 있었습니다. 정말 혹시나 싶어서 ping -d -s를 통해 전송되는 최대 프레임의 크기를 측정해 보았습니다. 그랬더니 아래와 같은 결과를 얻을 수 있었습니다.

#데이터 크기를 8000으로 esxi 호스트에서 NAS로 ping 테스트
#실패

[root@esxi01:~] ping -d -s 8000 10.10.10.100

PING 192.168.20.254 (10.10.10.100): 8000 data bytes
sendto() failed (Message too long)
sendto() failed (Message too long)
sendto() failed (Message too long)

--- 10.10.10.100 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss


#데이터 크기를 1472로 하여 프레임 데이터 합계가 1500바이트가 되도록 테스트
#실패

[root@esxi01:~] ping -d -s 1472 10.10.10.100

PING 10.10.10.100 (10.10.10.100): 1472 data bytes

--- 10.10.10.100 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss


#데이터 크기를 1468로 하여 프레임 데이터 합계가 1496바이트가 되도록 테스트
#성공

[root@esxi01:~] ping -d -s 1468 10.10.10.100
PING 10.10.10.100 (10.10.10.100): 1468 data bytes
1476 bytes from 10.10.10.100: icmp_seq=0 ttl=64 time=0.691 ms
1476 bytes from 10.10.10.100: icmp_seq=1 ttl=64 time=0.733 ms
1476 bytes from 10.10.10.100: icmp_seq=2 ttl=64 time=0.767 ms

--- 10.10.10.100 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.691/0.730/0.767 ms

 혹시나 싶었던 의심이 확신이 되는 순간이었습니다. 명령어 조회를 통해, 또는 UI를 통해 설정했던 MTU값들이 그저 '뻥카'였던 겁니다. 표시만 그렇게 될 뿐, 실제 USB NIC의 MTU는 1500으로 고정이며 당연하게도 VLAN 태그 오프로딩 기능도 없으므로 실질적으로는 1496이 최대 MTU 사이즈인 것입니다. 이런 이유 때문에 MTU가 1450일 때는 아무런 문제 없이 잘 작동했던 것이구요. 역시 외장 USB NIC이 원인인지, 커뮤니티 드라이버가 원인인지 명확하지는 않지만, 그래도 여기에서 문제가 발생하는 것은 확실해졌습니다.

 다시 VMkernel과 NAS쪽의 MTU 사이즈를 1468로 낮추고 iSCSI 연결을 하니 문제 없이 잘 작동하는것을 확인할 수 있었습니다. 역시 공식적으로 지원하지 않는 하드웨어를 사용하는데에는 많은 어려움이 있군요.

 요 며칠 동안 MTU 때문에 많이 골치를 썩었습니다. 사실 요즘에야 PMTUD(Path MTU Discovery)나 MMS와 같은 기술덕에 이 부분을 크게 신경 쓰지 않는다고는 하는데, 이처럼 호환성이 담보되지 않는 특수한 경우에서는 여전히 문제가 될 소지가 있는 것 같습니다. 덕분에 많은 것을 배웠고 이해할 수 있는 소중한 경험이었습니다.

환경

• VMware vSphere 6.7U3 환경에 배포된 VM
• Ubuntu 22.04
• 포트 그룹에서 VLAN 사용

증상

• apt update, apt install 등 apt 관련 명령어 사용 시 작동 안되는 현상
  • [Waiting for headers] 문구와 함께 행 걸림
  • 물리적으로 서버의 외장 USB NIC을 업링크로 사용하는 분산 스위치의 포트 그룹에서는 행 걸림 현상 발생
• 웹 브라우저를 통한 인터넷은 문제 없이 잘 작동
  
  • 속도 테스트, 설치 파일 다운로드와 같은 동작은 문제 없이 작동
• DNS 문제 없음
  • nslookup, dig 모두 잘 작동

대조군 설정 및 테스트

• 대조군 VM의 apt 명령어 및 인터넷 사용 문제 없음
• 문제의 VM의 경우 인터넷 사용 되지만 속도가 다소 느림
  • 특히 다운로드 속도가 업로드 속도에 절반 가량으로 비대칭 현상도 나타남
• 문제의 VM의 네트워크 어뎁터를 서버 내장 NIC을 업링크로 사용하는 분산 스위치의 포트 그룹으로 옮기고 나서 apt update 실행하면 문제 없이 실행, 다시 이것을 외장 USB NIC을 업링크로 사용하는 분산 스위치의 포트 그룹으로 옮기고 나면 apt update는 잘 실행되나 apt install과 같은 것은 0% [Waiting for headers] 문구와 함께 행 걸림

원인(추정)

• 외장 USB NIC에 문제이거나, VMware Flings 커뮤니티에서 제공하는 USB 드라이버의 문제일 수 있음
• VLAN TAG로 인해 MTU가 1500바이트를 넘기는데 VM의 MTU 사이즈는 1500이라 발생하는 문제라 추정 함
  • 다만 웹 브라우저가 작동이 잘 되는것은? - 스터디 필요
  • USB NIC 드라이버는 소프트웨어적으로 구현되어 VLAN TAG 4 바이트에 대한 오프로드 기능이 없어 그럴 수 있다는 추정 - From Claude Sonet 3.5
• 실제로도 ping -s를 통해 테스트 아래와 같은 결과 확인 가능
  • 서버 내장 NIC을 업링크로 사용하는 분산 스위치 포트 그룹에 연결된 VM에서는 MTU 최대 사이즈인 1500까지 문제 없이 작동
  • 최대 1500 바이트까지 전송이 가능하며, 아마 상단에 VLAN TAG의 경우 하드웨어 레벨의 오프로드 기능을 통해 핸들링할 것으로 예상 됨
  • 외장 USB NIC의 경우 이보다 4 바이트 적은 ping -s 1468 까지 작동 하는것 확인
  • 4 바이트는 VLAN TAG의 크기로, USB NIC에서는 오프로드 기능이 작동하지 않는 것으로 보임

# 서버 내장 NIC을 업링크로 사용하는 분산 스위치의 포트 그룹에 연결된 VM
# 1472 바이트 + ICMP 헤더 8 바이트 + IP 헤더 20 바이트 = 1500 바이트

$ ping -s 1472 google.com

PING google.com (142.250.76.142) 1472(1500) bytes of data.
1480 bytes from kix07s06-in-f14.1e100.net (142.250.76.142): icmp_seq=1 ttl=116 time=28.8 ms
1480 bytes from kix07s06-in-f14.1e100.net (142.250.76.142): icmp_seq=2 ttl=116 time=29.2 ms

# 외장 USB NIC을 업링크로 사용하는 분산 스위치의 포트 그룹에 연결된 VM
# 1468 바이트 + ICMP 헤더 8 바이트 + IP 헤더 20 바이트 = 1496 바이트
# VLAN TAG를 위해 4바이트를 비운 상태에서 정상 작동

$ ping -s 1468 google.com

PING google.com (142.250.206.206) 1468(1496) bytes of data.
1476 bytes from kix07s07-in-f14.1e100.net (142.250.206.206): icmp_seq=1 ttl=117 time=35.8 ms
1476 bytes from kix07s07-in-f14.1e100.net (142.250.206.206): icmp_seq=1 ttl=117 time=36.1 ms

조치

Command를 통한 MTU 사이즈 조절

# 네트워크 인터페이스의 MTU를 1450으로 설정
sudo ip link set dev [인터페이스명] mtu 1450

Netplan 파일 수정

# 또는 netplan을 사용하는 경우 /etc/netplan/의 설정 파일에:
network:
  ethernets:
    [인터페이스명]:
      mtu: 1450

결론

• MTU 사이즈 불일치에 따른 통신 장애 상황과 그에따른 대처법 습득
• 하드웨어 수준의 오프로드 기능이 있음을 확인
• 소프트웨어 드라이버는 이런 기능을 지원하지 않을 수 있음을 확인
• VLAN 사용 시 세심한 주의 필요

추가 스터디 필요 내용

• MTU 사이즈 조정 전에도 웹 브라우저를 통한 통신에는 문제가 없었던 점 확인 필요
• MTU 사이즈 문제로 다운로드/업로드 속도 비대칭이 발생할 수 있는지 확인 필요

구축 배경

 홈 랩을 확장하면서 가정용 Wi-Fi 네트워크와 홉 랩 인프라용 네트워크 간의 분리 및 격리, 라우팅 및 접근 제어 그리고 그 외 서비스에 필요한 기능 구현이 필요했습니다. 그래서 네트워크 최상단에 방화벽과 라우터 역할을 할 수 있는 OPNsense를 직접 구축해 보기로 했습니다.

 이번 포스팅에서는 시리즈로 하드웨어 선정부터 설치, 구성과 방화벽 규칙 설정, 그리고 각종 서비스 설정까지 전반적인 내용에 대해서 다뤄보고자 합니다.

OPNsense란?

 OPNsense는 pfSense와 m0n0wall을 기반으로 개발이 시작되어 2015년 1월에 첫 공식 릴리즈가 이루어진 FreeBSD 기반의 오픈소스 방화벽 및 라우팅 플랫폼입니다. 발표된 지 딱 10년이 된 프로젝트로 Deciso B.V.에 의해 설립되었으며 지금까지 꾸준한 개발과 업데이트가 이루어지고 있습니다. 매주 보안 업데이트를 제공하고 있으며, 연간 2회의 주요 릴리즈 업데이트도 제공하고 있는 엔터프라이즈급 방화벽 소프트웨어입니다.

 웹 기반의 직관적인 사용자 인터페이스를 통해 복잡한 네트워크 설정을 비교적 쉽게 관리할 수 있으며, 다양한 기능들을 제공합니다. 방화벽의 기본이 되는 IDS/IPS와 같은 보안 기능과, 상태 기반 패킷 검사 기능을 제공하며 VPN(IPsec, OpenVPN, Wireguard), DNS, DHCP와 같은 네트워크 서비스 및 모니터링과 리포팅 기능, 각종 서드파티 플러그인 등 정말 다양한 기능을 제공합니다. 또한 오픈소스의 장점인 검증 가능한 소스 코드를 통해 높은 신뢰성도 보장하고 있습니다.

 개인적으로는 OPNsense만 잘 활용해도 중규모 수준의 엔터프라이즈 네트워크 환경의 경계 방어에는 문제가 없지 않을까 생각할 정도로 강력한 기능들을 제공합니다.

하드웨어 사양

 강력한 기능을 가진 OPNsense를 물리장비로 구현하기 위해서는 안정적인 하드웨어가 필요합니다. OPNsense의 공식 문서를 살펴보면 아래와 같이 필요한 하드웨어 사양을 확인할 수 있습니다.

Minimum

Reasonable

Recommended

Throughput

 또한, 문서에는 FreeBSD 하드웨어 목록 및 권장사항에서 이야기하는 Intel 네트워크 인터페이스를 추천하고 있었습니다. 위 표와 네트워크 인터페이스 추천을 바탕으로 아래 두 가지 기준에 맞는 하드웨어를 찾아보았습니다.

• Recommended 수준의 하드웨어 스펙
• 네트워크 인터페이스는 Intel로...

 역시 없는 게 없는 알리... 알리익스프레스에서 마침 알맞은 제품을 찾을 수 있었습니다. Topton Mini PC 제품으로 특이하게도 따로 제품 명이 있는 것이 아니라 '12세대 방화벽 라우터 인텔 N100 i226-V 팬리스 미니 PC...' 주저리주저리 길게 제품 스펙을 나열해 둔 것이 특징입니다. 뭐랄까... 디자인은 개나 줘버린 맛으로만 승부하는 막걸리 패키징 같은 느낌? 어쨌든 생긴 건 아래와 같습니다.

 제품 이름에서도 알 수 있지만 그 스펙을 살펴보면 우선 프로세서는 Intel의 N100 프로세서로 4 코어 4 스레드의 스펙을 가지고 있습니다. RAM과 SSD는 옵션으로 고를 수 있는데, 저는 8GB RAM과 128GB SSD 옵션을 선택하여 Recommended 스펙에 딱 맞추었습니다. 네트워크 인터페이스가 상당히 인상적인데 Intel의 i226-V 2.5G RJ45를 6개나 제공한다는 것입니다. 후기도 제법 있고 Youtube에도 영상이 좀 있는 것으로 보아 괜찮아 보여 구매를 결정했습니다. 처음 받았을 때는 기본적으로 pfSense가 설치되어 있는데 아무래도 좀 찜찜해서 완벽하게 삭제해 주고, OPNsense를 설치했습니다. 결론적으로 말씀드리면 지금까지 아무런 문제 없이 준수한 성능을 발휘하고 있습니다. 아무래도 제조사 측에서 산업용으로 분류하는 제품이라 그 내구성도 나쁘지 않을 것 같습니다.

OPNsense 설치를 위한 준비

 OPNsense를 설치하기 위해서 우선 부팅 USB를 만들어야 합니다. https://opnsense.org/download/에 접속하여 vga 형식의 image 파일을 다운로드합니다. 여러 가지 방식이 있는데 만약 VM에서 테스트를 해보고 싶으시다면 dvd 형식의 image를 다운로드하여도 됩니다. Windows를 사용하는 경우에는 Rufus를, MacOS를 사용하는 경우에는 balenaEtcher를 사용하여 부팅 USB를 만들 수 있습니다. MacOS의 경우에는 기억이 좀 가물가물한데, CLI 환경에서 명령어를 통해 만들었던 것 같기도 합니다.

 아래 내용은 셀프 구축한 방화벽의 하드웨어 장비 설치부터 OPNsense 배포, 그리고 간단한 설정에 대한 내용을 다룰 예정입니다. 단, 저는 이미 하드웨어로 설치를 마무리하였기 때문에, OPNsense 배포와 그 후 설정 과정은 가상환경에서 VM을 통해 보여드리도록 하겠습니다. 본 포스팅에서는 2025년 2월 현재 최신 버전인 OPNsense 25.1 Ultimate Unicorn 버전을 기준으로 합니다.

OPNsense 설치

1. 물리적 네트워크 토폴로지

 이번 포스팅에서 다룰 네트워크의 물리적 구성은 위와 같습니다. 특별할 것은 없지만, 이것이 기본이 되어 여러 네트워크 구성에 참고가 되었으면 합니다. 그리고 방화벽이나 라우터에 직접 호스트를 연결하는 경우는 극히 드물지만, 간단한 예시 환경인 것을 감안해 주시면 감사하겠습니다.

2. 네트워크 포트 연결

 우선 통신사 모뎀과 OPNsense 방화벽이 될 물리 장비의 포트를 케이블로 연결합니다. 이번 실습에서는 ETH 0를 사용하겠습니다. 나머지 포트는 Host 1과 Host 2에 연결해 줍니다. 가상 환경에서 이 포스팅 내용을 따라 하신다는 해당 가상 환경에 맞도록 위와 같이 설정해 주시면 되겠습니다.

3. USB 또는 IOS 이미지를 통한 부팅

 다음으로 할 작업은 USB를 미니 PC의 첫 번째 부팅 매체로 설정하는 것입니다. Topton Mini PC의 경우 전원을 넣고 F2 키를 누르면 BIOS로 진입합니다. 메뉴에서 부팅 순서를 찾아 USB가 첫 번째 부팅 순서를 가지도록 설정한 후 저장하고 재부팅합니다. 아마 가상환경이라면 부팅 이미지를 마운트 하면 자동으로 부팅이 될 것입니다.

4. OPNsense Install

OPNsense로 부팅을 하게 되면 위와 같은 화면이 잠깐 나왔다가 금방 다음 단계로 넘어갑니다. 스스로 하드웨어도 확인하고, 중간에 사용자가 직접 개입할 수 있는 구간도 있지만 우선은 완전히 부팅이 될 때까지 기다립니다. 그럼 아래와 같은 화면을 만나게 됩니다.

 위 화면에 출력된 내용을 자세히 살펴보겠습니다. 우선 2개의 인터페이스를 설정한 모습입니다. LAN으로 vmx0 인터페이스를, WAN으로 vmx1 인터페이스를 설정하고 있습니다. 그리고 현재 OPNsense가 라이브 모드로 실행되고 있다고 알려주고 있으며, 'root'로 로그인하면 그대로 라이브 모드로 사용을 하는 것이고, 'installer'로 로그인하면 설치를 시작할 수 있다고 합니다.

 기본적으로, OPNsense는 첫 번째 인터페이스를 LAN으로 설정하며 192.168.1.1을 이 인터페이스의 주소로 가지게 됩니다. 또한 WAN은 DHCP 모드로 설정되어 있어 만약 DHCP로 IP를 받은 인터페이스가 있다면 그 인터페이스가 WAN 인터페이스가 될 것입니다. 어쨌든, 기본 설정은 우리가 원하는 설정이 아닙니다. 거기다가 라이브 모드의 경우 기기가 재부팅되면 기존 설정들이 모두 사라지기 때문에 곤란하기도 하구요. SSD나 HDD에 영구적으로 설치를 위해 'installer'로 로그인을 합니다. 초기 비밀번호는 'opnsense'입니다.('root'의 경우에도 로그인 비밀번호는 'opnsense'로 동일합니다.)

 키보드 맵은 기본값을 사용하면 됩니다. 이 화면에서는 바로 Enter를 입력합니다.

 다음 화면은 파일 시스템 선택 및 다양한 설치 메뉴에 대한 내용입니다. 우리는 처음 설치이니 위 두 개 메뉴인 ZFS와 UFS 중 하나를 선택하고 설치하면 됩니다. 두 파일 시스템에 대한 설명은 간략하게 표로 정리해 보았습니다.

 하드웨어 사양이 충분하다면 ZFS를, 제한적이라면 UFS를 선택하는 쪽이 좋아 보입니다. 저는 ZFS를 선택해 보겠습니다.

 다음 화면은 RAID를 선택하는 것입니다. 우선은 SSD가 하나이므로 'stripe'를 선택하겠습니다. 필요에 따라 RAID를 선택하면 되겠습니다.

 하나의 디스크만이 있으므로 해당 디스크를 선택합니다. 스페이스바를 누르면 대괄호 안에 '*'가 생기는데 이것이 바로 디스크가 선택된 것입니다. Enter를 입력하여 다음 화면으로 넘어갑니다.

 설치를 진행하면 디스크의 기존 데이터가 삭제된다는 경고가 표시됩니다. 화살표키로 'YES'를 선택한 다음 Enter를 입력합니다.

 본격적인 설치가 진행됩니다. 자동으로 진행되므로 설치가 마무리될 때까지 잠깐 기다리도록 하겠습니다.

 설치가 완료되면 위와 같은 화면이 등장합니다. Root의 비밀번호를 변경하거나, 설치 절차를 마무리하고 재부팅을 할 수 있습니다. 우선 Root 비밀번호 변경을 진행해 보겠습니다.

 Root 비밀번호는 앞으로 CLI 환경, 또는 Web UI 환경에서도 사용되므로 미리 변경해 주는 것이 좋습니다. 지금 변경하지 않더라도, 다음에 Web UI 환경에서 설정을 통해 변경할 수도 있습니다. 변경된 비밀번호 확인하기 위해 다시 한번 입력해 주고 'Complete Install' 메뉴를 선택하고 Enter를 입력합니다. 이렇게 되면 재부팅을 하고 나면 설치 절차가 마무리됩니다.

5. 최초 인터페이스 설정

 재부팅이 완료되고 나면, 사용자 ID를 'root'로 하고 앞선 설치과정에서 설정했던 비밀번호로 로그인을 합니다.

 이제 본격적으로 인터페이스 설정에 들어갑니다. '1'을 입력하고 Enter를 입력합니다.

 '1) Assign interfaces' 모드에 들어가면 가장 먼저 LAGG 설정이 있는지 물어봅니다. OPNsense LAGG란 Link Aggregation, Bonding, Fault Tolerance 등을 위한 기능으로 네트워크를 조금 공부해 보신 분들이 라면 잘 아시리라 생각합니다. 쉽게 말해서 2개 이상의 인터페이스를 묶어서 하나의 인터페이스터럼 사용하는 기술입니다. 이번 실습에서는 이를 사용하지 않을 예정이므로 'n'을 입력합니다. 다음으로 VLAN 설정을 하게 되는데 역시 'n'을 입력하고 넘어갑니다. 그러면 현재 기기에 있는 네트워크 인터페이스 목록을 보여줍니다. 저의 경우 가상머신이라 'vmx0'과 같은 인터페이스 명을 가지고 있습니다. 실제 물리장비에서는 'igc2'와 같은 이름이 출력됩니다.

 저는 첫 번째 인터페이스인 'vmx0'을 통신사 모뎀과 연결된 인터페이스(물리 장비의 ETH 0 인터페이스)인 WAN 인터페이스로 사용하겠습니다. 실제로는 DHCP를 통해 공인 IP 주소를 받아오지만, 이번 포스팅에서는 가상 환경에 해당 대역대에는 DHCP 서비스를 하지 않고 있어 static으로 설정할 것입니다.

 다음은 LAN 인터페이스 설정입니다. 이름 그대로 로컬 네트워크로 사용할 인터페이스입니다. 이 인터페이스는 조금 중요한데, 최초 설정을 마무리하고 다른 설정들을 위해 해당 Web UI 접속을 위한 인터페이스이기 때문입니다. LAN 인터페이스로 'vmx1'을 입력하고 Enter를 입력하면 다른 인터페이스를 추가로 설정할 수 있습니다. 우선은 빈 값으로 Enter를 입력하여 넘어갑니다. Web UI를 통해 설정할 것이기 때문입니다. 마지막으로 지금까지의 설정대로 구성을 진행할 것인지를 물어보는데 'y'를 입력하고 Enter를 입력합니다.

이렇게 최초 인터페이스 설정이 마무리되었습니다. LAN 인터페이스에 기본 OPNsense의 default IP 주소인 192.168.1.1이 부여된 것을 확인할 수 있습니다.

6. Web UI를 활용한 OPNsense 설정

 마지막 단계로 Web UI를 활용하여 OPNsense 설정을 해보도록 하겠습니다. 그러기 위해서는 우선 앞선 네트워크 토폴로지에서 등장했던 'Host 1'을 준비해야 합니다. 저는 역시 VM을 사용하여 Ubuntu 22.04 Desktop으로 준비하였습니다.

 OPNsense의 LAN 인터페이스와 동일한 네트워크에 위치할 수 있도록 VM의 IP 주소를 192.168.1.2로 설정하였으며, Gateway는 192.168.1.1, DNS는 8.8.8.8로 설정하겠습니다. 그리고 웹 브라우저를 통해 192.168.1.1로 접속합니다.

 OPNsense는 기본적으로 사설 인증서를 내장하고 있어서, 웹 브라우저를 통해 접근하면 보안 경고가 발생됩니다. 이를 무시하고 접속하면 Web UI에 접근할 수 있습니다.

 앞선 CLI 환경에서 사용하던 사용자 이름(root)과 비밀번호를 사용하여 접속합니다.

 최초에 접속하면 이와 같이 Wizard가 실행됩니다. 이를 통해 설정을 진행할 수 있습니다.

 처음에는 이 방화벽의 Hostname과 Domain, 언어, DNS 등을 설정할 수 있습니다. 언어에는 한국어도 지원하므로 한국어를 설정하셔도 됩니다. 다만 번역이 아직 다소 부자연스러운 부분이 있습니다. 이번 포스팅에서는 기본값을 그대로 사용하도록 하겠습니다. DNS Server는 Primary와 Secondary를 설정할 수 있습니다. 아래 Override DNS 체크박스가 체크되어 있으면 WAN이 DHCP로 주소가 설정될 때, ISP에서 제공해 주는 DNS 서버로 설정을 덮어쓰게 됩니다. 따라서 저는 이 체크박스를 해제하고 8.8.8.8과 1.1.1.1을 지정해 주었습니다. 그 아래 Unbound DNS의 경우 설정을 건드리지 않고 넘어가겠습니다.

 다음으로 Timezone 설정입니다. 현재 위치한 지역의 Timezone으로 설정하고 다음 단계로 넘어갑니다.

 이번에는 WAN 인터페이스에 대한 설정입니다. 앞선 CLI 환경에서는 어떤 인터페이스를 WAN 인터페이스로 사용할지에 대한 설정이었다면, 이곳에서는 WAN 인터페이스의 IP 주소라던지, 다른 네트워크 요소들에 대한 설정을 할 수 있습니다. 만약 ISP로부터 공인 IP를 공급받거나, 혹은 내부적으로 사용 시에도 WAN 인터페이스가 연결된 네트워크에 DHCP 서비스가 작동 중이라면 이 설정을 DHCP로 그대로 두어도 상관없습니다. 실제 제가 구축한 홈 랩에도 최상단 방화벽의 WAN 포트는 DHCP로 작동하고 있습니다.

 본 포스팅에서는 OPNsense의 WAN 인터페이스가 연결된 네트워크에 DHCP 서비스가 없으므로, 이를 Static으로 설정하겠습니다.

 WAN interface의 IP 주소를 192.168.100.250으로 하고 Subnetmask를 255.255.255.0으로 설정합니다. 추가로 WAN이 속한 네트워크의 게이트웨이 주소를 Upstream Gateway 주소로 입력해 줍니다. 그럼 인터넷으로 전달되어야 할 트래픽들이 Gateway로 보내지게 됩니다.

 다음은 LAN 인터페이스 설정인데, 이것은 그대로 두고 넘어가도록 하겠습니다.

 마지막으로 Root 계정의 비밀번호를 설정합니다. 앞선 설치 과정에서 설정하였다면 그대로 넘어가도 좋고, 만약 설정하지 않았다면 보안상 여기에서 다른 복잡한 비밀번호로 설정하는 것을 권장드립니다. 저는 앞선 설치과정에서 설정하였기 때문에 여기에서는 다음 단계로 넘어가도록 하겠습니다.

 설정이 완료되면 위와 같은 화면이 나타납니다. 이제 대시보드로 접근해 보겠습니다.

 OPNsense의 대시보드입니다. 지난 24년 하반기 패치 때 실시간 트래픽 그래프, 원형 그래프 등이 업데이트되어 한눈에 여러 가지 정보를 확인할 수 있게 되었습니다. 우측 상단에 연필 모양을 클릭하여 대시보드의 위젯을 추가하거나 위치를 변경할 수도 있습니다.

 이것으로 OPNsense 설치에 관련한 첫 번째 포스팅을 마치려 합니다. 다음 편에서는 방화벽 Rule을 설정하여 서로 다른 네트워크 간의 통신을 차단하거나 허용하는 기본적인 방화벽 사용에 대한 내용과, 부가적인 기능들을 설정하는 방법에 대해서 알아보도록 하겠습니다.

▼ OPNsesne로 방화벽 추구하기 [2편]

 홈 랩을 구축하면서 경험했던 많은 내용들과 좌절을 안겨준 많은 여러 상황들, 그리고 이를 해결하기 위해 했던 여러 시행착오들을 통해 얻은 노하우를 기록하고 또 공유하기 위해 이 포스팅을 시작합니다. 아마 상당히 긴 시리즈의 포스팅이 될 것 같습니다. 먼저, 홈 랩이 왜 필요하게 되었는지와, 이를 설계하면서 고려했던 내용들에 대해서부터 이야기를 시작해 보도록 하겠습니다.

그래서 홈 랩이 왜 필요했는데?

 가장 큰 이유는, 경험이 필요했기 때문입니다. 저는 부끄럽게도 IT 전공자도 아니고, 또 국비지원 교육을 받은 양산형 인력이었습니다. 코로나 시기와 맞물려 개발자들이 양산되어 나오던 시기에 지방에서 개발자도 아닌 시스템 엔지니어 양성 과정을 수료하고 지방의 작은 회사에서 커리어를 시작했기 때문에 절대적인 경험이 부족했습니다.

 운이 좋아서 서울로 이직하긴 했지만 역시나 현장 경험이 그다지 없다 보니 항상 경험에 목말라 있었습니다. 이대로 가다가는 이도저도 아닌 연차만 쌓이는 엔지니어가 될 것 같아 사비를 들여서라도 무언가 해보고 싶었습니다. 그래서 기존이 있던 놀고 있던 NAS도 활용할 겸 홈 랩을 구축하게 되었습니다.

 물론 클라우드를 선택할 수도 있었지만, On-premise 환경을 택했습니다. 원래 VMware를 기반으로 한 업무를 해왔고 그래서 온프레미스 환경이 조금 더 익숙하기도 했으며, 클라우드의 완성된 서비스를 사용하기보다는 직접 구축하면서 더 많은 것들을 배울 수 있을 것이라 생각했습니다. 그렇다고 클라우드의 여러 다양한 서비스를 사용하는 게 마냥 쉽고 배울게 없다는 뜻은 아닙니다. 다만 Low-Level의 인프라부터 다루어 보면서 부족한 기초를 다지고 싶었습니다.

홈 랩을 통해 이루고자 하는 목표

 목표는 크게 두 개로 첫째는 '약 10 - 20개 정도의 중소규모 Kubernetes 클러스터를 동시에 운영할 수 있는 규모의 인프라 구축'이고 둘째는 'Self-Service 형식의 기본 기능을 갖춘 Kubernetes 서비스 제공'입니다. 결론부터 말씀드리자면 현재 첫 번째 목표는 대부분 이룬 상태입니다. 그래서 앞으로의 포스팅은 첫 번째 목표를 이룬 과정에 대해서 상세하게 기술하려고 합니다.

기존 보유 중이던 인프라

 개발자 친구들과 토이 프로젝트를 진행하면서 구축한 아주 작은 수준의 인프라를 가지고 있었습니다. 이를 통해 Kubernetes 클러스터를 제공하고 개발했던 애플리케이션을 배포, 서비스를 외부로 노출한 경험을 기반으로 하여 확장된 규모의 인프라를 구축하려고 했습니다. 우선 기존 인프라부터 이야기를 해 보겠습니다.

1. Server

 물리적인 서버 역할을 담당할 장치입니다. 중국의 Beelink사의 SER 5 MAX라는 Mini PC입니다. 인텔의 NUC와 매우 흡사한 폼팩터를 가지고 있습니다. 적당한 성능과 가격이 가장 큰 메리트였습니다. 물론 중국 제품이라는 데에 다소 불신도 있고 또 보안상 위협도 있을 수 있다는 점은 충분히 인지하고 있습니다. 하지만 예산이 가장 큰 걸림돌이었기 때문에 어쩔 수 없이 가성비 제품을 선택하게 되었습니다. 국내외 리뷰를 찾아보니 제법 인지도도 있는 것 같고 사용자들도 있는 것 같아 총 2대 구매를 결심했습니다.

 구매 시 가장 확인이 어려웠던 부분은 네트워크 인터페이스입니다. 하이퍼바이저로 VMware ESXi를 사용할 예정이었는데 VMware에서는 공식적으로 리얼텍 제품에 대한 드라이버를 제공하지 않고 있습니다. 아무래도 엔터프라이즈급 제품이 아니라는 이유가 크다는데 홈 랩을 구성하는 입장에서는 매우 아쉬운 부분입니다.

 사실 구매 전에 이를 확인했어야 하는데 확인하지 않은 제 실수도 있었구요. 열심히 구글링을 하여 여러 자료를 찾아보았는데 다행히 커스텀 드라이버를 통해 리얼텍의 네트워크 인터페이스를 사용하는 방법[자료 링크]을 찾을 수 있었습니다. 여러 시도를 해 보았으나 제대로 작동하는 것은 ESXi 6.7 버전이었습니다. 혹시라도 따라 해 보실 분들은 참고하시면 될 것 같습니다.

2. Network

 네트워크는 기존에 사용하던 ipTIME AX2004 BCM 공유기를 사용하기로 했습니다. 이 제품은 지금은 단종되었습니다. 공유기 치고는 고가에 구입했던 걸로 기억합니다. 현재는 ipTIME AX300 BCM이 그 후속으로 조금 더 저렴한 가격에 나와있습니다. 개인적으로 처음 홈 랩을 구축하는 분들이라면 ipTIME을 추천드립니다. 국내에는 이를 통해 홈 랩이나 홈 네트워크 구축한 사례가 많아 자료도 많고, 가격대가 좀 있는 제품은 그 기능도 준수해서 사용하게에 충분하다고 생각합니다.

 꼭 위 제품을 선택할 필요는 없지만, 그래도 제품을 고르실 때 VPN과 DDNS 기능이 있는지 살펴보는 것을 추천드립니다. 집 밖에서 원격으로 홈 랩 인프라를 제어해야 하는 상황에서 매우 유용하기 때문입니다. 저는 여기에 추가로 브로드컴 칩셋 사용 여부도 고려 사항으로 추가하는 것을 추천드립니다. 물론 다른 제조사의 칩셋을 사용하는 제품도 문제는 없지만, 그래도 브로드컴 칩셋의 성능과 신뢰도가 조금 더 뛰어나기 때문입니다.

 위 구조가 바로 초창기 구축했던 홈 랩 네트워크의 구조입니다. 특징적인 것은 ISP로부터 제공되는 공인 IP 주소를 통신사 모뎀의 Bridge Mode를 통해 공유기에 바로 제공할 수 있게 하였습니다. 이유는 앞서 말씀드린 VPN과 DDNS 때문인데, 이는 추후에 더 다루어 보도록 하겠습니다. 어쨌든, 이렇게 구축을 하게 되면 공유기의 WAN 포트 1개와 LAN 포트 4개를 모두 사용하게 됩니다.(여기서 인프라를 더 확장하기 위해서는 필수적으로 스위치가 필요해집니다.)

3. Storage

 VMware ESXi를 하이퍼바이저로 사용하면서 iSCSI 방식의 블록스토리지가 필요했습니다. 기존에 가지고 있었던 오래된 NAS가 있어서 이를 활용하기로 했습니다. 예전에 한창 사진에 취미가 있을 때 장만했던 장비인데, 당시에는 여러 스터디 자료나 Linux 배포판 이미지를 모아두거나 하는 용도로 사용하고 있었습니다.

 Disk Bay 5개와 1Gbps 네트워크 인터페이스 4개를 가지고 있는, 구매 당시에는 제법 괜찮은 스펙의 NAS였습니다. 4TB HDD도 3개를 장착하여 RAID 5 구성을 한 상태로 공유 스토리지로 사용하기에는 충분한 성능과 용량을 가지고 있습니다. NAS가 필수는 아니지만 ESXi의 기능을 제대로 사용하려면 공유 스토리지가 필요합니다. 물론 네트워크로 연결된 iSCSI, HDD라는 스펙적인 한계가 있지만 홈 랩 정도의 수준에서는 충분한 성능을 제공합니다.

 또한 Synology NAS는 다양한 기능을 제공합니다. 자체적으로 VM을 호스팅 할 수도 있으며, DDNS(Synoloby NAS가 있으면 공유기의 DDNS 기능은 없어도 됩니다.), DNS, 리버스 프록시, Let's Encrypt와 연동한 인증서 발급 및 자동 갱신, 인증서 종단점 역할 등 다양한 서비스를 제공합니다. 제대로 된 홈 랩을 구성하려면 구매를 고려해 볼 만한 장비가 아닌가 생각합니다.

 사실 위 정도의 장비만 갖추어도 홈 랩을 통해 많은것들을 테스트해볼 수 있습니다. 그러나 저는 여기서 조금 더 높은 수준의 서비스를 제공하는 인프라를 구성하고, 또 이를 사용자 셀프서비스 방식으로 고도화하기 위해 인프라를 확장하기로 마음먹습니다. 확장된 인프라에 대한 계획과 규모, 그리고 설계에 대해서는 다음 포스팅에서 다뤄 보도록 하겠습니다.

0. 들어가며

 지난 포스팅에 이어 바로 2편을 작성하지 않고, 먼저 Kubernetes Cluster 구축 방법에 대한 내용으로 포스팅을 진행했습니다. 이유는, 단일 Control Plane(이전에는 Master 노드라고 이야기 해였습니다. 'Master'가 주종관계를 나타내는 단어라 앞으로는 Control Plane으로 사용하기로 하겠습니다. 여기서 또 PC가...)으로 Kunbernetes 환경을 구성하는 방법을 알아야 그 다음에 2대 이상으로 이루어진 멀티 Control Plane 구성이 가능하기 때문입니다. 그리고... 사실 제가 바쁘기도 했고 또, Home Lab 환경에 큰 변화가 있었던 것도 그 이유 중에 하나입니다. (그래서, IP 주소도 변화가 있었습니다.) 최대한 내용이 이어질 수 있도록 포스팅을 진행 하도록 하겠습니다. 너른 양해 부탁드립니다.

1. 멀티 노드로 Kubernetes Control Plane 구성하기

 우선, 이전에 했던 포스팅을 한번 살펴 보셨으면 합니다.

 지난 포스팅에서는 HAProxy와 Keepalived를 통해 가상 IP 주소에 대한 HA 기능을 구현해 보았습니다. 이 가상 IP를 앞으로 구성하게 될 Kubernetes API Server의 End-Point로 활용할 것입니다. 그리고 한 가지 더 구성해야 할 것이 있는데 바로 멀티 Control Plane을 가진 Kubernetes Cluster입니다. 이는 아래 포스팅을 통해 확인할 수 있습니다.

 해당 포스팅도 1편부터 보시는걸 추천드리지만, 만약 VM으로 Ubuntu 설치가 어렵지 않으시다면 2편부터 보셔도 무방합니다. 링크된 포스팅의 중반부 '5) Kubeadm을 통한 Kubernetes 클러스터 구성'에 보시면 아래와 같은 명령어를 실행합니다.

sudo kubeadm init --apiserver-advertise-address=192.168.0.150
#sudo kubeadm init --apiserver-advertise-address=[Kubernetes Cluster의 Control Plane 노드의 IP 주소]

 단일 Control Plane으로 Kubernetes Cluster를 구성할 시에는 위와 같은 명령어를 사용하면 되지만, 멀티 Control Plane 노드를 통해 Cluster 형식으로 Kubernetes API Server를 구축할 때는 명령어가 달라집니다. 여러 대의 Control Plane 노드 중 하나에 아래와 같은 명령어를 사용하시면 됩니다.(이전 포스팅 기준으로, Kubernetes Master 01인 172.16.11.151번 IP를 가진 노드에서 해당 명령어를 실행해 주었습니다.)

sudo kubeadm init --control-plane-endpoint "172.16.11.150:6443" --upload-certs
#sudo kubeadm init --control-plane-endpoint "[가상 IP 주소:포트번호]" --upload-certs

 참고로, 이전 포스팅에서 가상 IP 주소를 172.16.11.150으로 사용하기로 했기 때문에, 위 명령어의 IP 주소가 172.16.11.150이 되었습니다. 구성하시는 환경에 맞도록 해당 IP 주소를 바꿔주면 됩니다. 포트번호는 Control Plane의 API 서버가 사용하는 번호를 사용했는데 다른 것으로 바꾸셔도 무방합니다. 그러면 아래와 비슷한 문구가 출력되는 것을 확인할 수 있습니다.

You can now join any number of control-plane node by running the following command on each as a root:
    kubeadm join 172.16.11.150:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
#위 명령어를 꼭 확인할 것! 해당 명령어를 다른 Control Plane 노드에 입력해 주어야 함.
#kubeadm join [가상 IP 주소:포트번호] --token [출력된 토큰 값] --discovery-token-ca-cert-hash sha256:[출력된 해시 값]

Please note that the certificate-key gives access to cluster sensitive data, keep it secret!
As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use kubeadm init phase upload-certs to reload certs afterward.

Then you can join any number of worker nodes by running the following on each as root:
    kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866

 위에서 보는 것과 같이, 멀티 노드로 Control Plane을 구성하게 되면 기존의 단일 노드로 Control Plane을 구성할 때와는 다른 명령어를 하나 확인할 수 있습니다. 바로 Control Plane으로 구성될 노드에 입력해야할 명령어입니다. 해당 명령어를 다른 노드에 입력하면 됩니다.

sudo kubeadm join 172.16.11.150:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
#Master 02와 Master 03에 위 명령어를 각각 입력해 줍니다. 이때 토큰 값과 해시 값은 다를 것이기 때문에 실제 화면에 출력된 값을 복사해서 입력해 줍니다.

 일반 사용자 계정이기 때문에, root 권한으로 명령어를 실행하기 위해 앞에 sudo를 붙여 주는 것을 잊지 않아야 합니다. 위 명령어를 각각 남아 있는 Control Plane 노드에 입력해주면 그 뒤 내용은 동일합니다. Worker 노드를 Join 시켜주면 클러스터 구성이 마무리됩니다.

2. API End-Point를 통해 Kubernetes Cluster 제어하기

 위와 같은 방식으로 Kubernetes Cluster 구성이 마무리되었으면 이제 외부에서 API 서버를 제어할 Console이 필요할 것입니다. 아래 그림과 같은 형식이 될 것인데요.

 이렇게 구성하는 것이 타당해 보입니다. 우선 가상 IP 주소를 통해 API Server를 조작하기 때문에 로드밸런서의 기능도 활용하게 되고, 직접적으로 Control Plane 노드에 접속하지 않기 때문에 보안상 이점도 가져갈 수 있습니다.

 콘솔은 kubectl이 설치된 Linux 계열의 호스트라면 어떤 것이든 상관이 없습니다. 이제 Control Plane에서 Kubernetes Cluster에 대한 Context만 가져오면 됩니다. Control Plane 노드에서 아래와 같은 내용을 조회합니다.

cat ~/.kube/config
#Kubernetes Cluster에 대한 Context를 조회 합니다.

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: [암호화된 값이 출력됨]
    server: https://172.16.11.150:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: [암호화된 값이 출력됨]
    client-key-data: [암호화된 값이 출력됨]

 이 부분에 대해서는 Kubernetes의 인증과 인가에 따로 다루는 포스팅을 게시하도록 하겠습니다. 현재는 우선 Kubernetes Cluster에 대한 모든 권한을 가진 admin 권한의 Context를 사용하는 방법을에 대해서 알려드립니다.

 위 명령어로 ~/.kube/config 파일의 위치를 확인했다면, 해당 경로에 위치한 config 파일의 내용을 복사하여 Console에 같은 위치로 같은 이름의 파일명을 통해 해당 내용을 붙여 넣어도 좋고, 아니면 파일 자체를 복사해도 됩니다. 그리고 Console에서 kubectl 명령어를 실행하면 구성된 Kubernetes Cluster를 제어할 수 있음을 확인할 수 있습니다.

3. 마무리

 두 편의 걸친 포스팅과, Kubernetes Cluster 구성에 관한 포스팅을 통해 Kubernetes API Server의 Cluster 구성과, HA, LB 기능에 대해 알아보았습니다. 물론 현업에서는 퍼블릭 클라우드에서 제공하는 Kubernetes 서비스와 같이 제품화된 서비스를 사용하는 경우가 많아 위와 같은 구성을 직접 할 경우는 적겠지만, 해당 내용을 통해 Kubernetes에 대한 이해가 한층 더 높아졌기를 바랍니다. 감사합니다.

 마지막으로, 관련 내용에 대한 Kubernetes 공식 문서 링크도 남겨 드립니다. 학습에 참고가 되길 바랍니다.