The Social Dork가 OPNsense 홈 방화벽을 구축하는 방법

ZimaBoard 2에서 OPNsense 홈 방화벽을 구축한 사례를 공유해 준 The Social Dork | 사이버 보안에 감사드립니다. 가상 머신이 라우팅과 방화벽 정책을 처리하고, 액세스 포인트가 Wi-Fi를 제공하며, Pi-hole이 연결된 클라이언트의 DNS를 필터링합니다. 전체 시연은 YouTube 원본 안내 영상에서 확인하세요.

읽기 전에 시청하세요: 약 10분 분량의 이 영상은 네트워크 게이트웨이와 무선 액세스 포인트를 분리하려는 경우 유용합니다. 크리에이터가 토폴로지를 설명하고 Zima Virtual Machine에서 OPNsense를 부팅한 다음 인터페이스와 DHCP를 설정하고, 무선 노트북과 DNS 필터링을 확인합니다.

영상에서 보여 주는 단계는 노트북이 새 방화벽을 통해 네트워크에 연결되고 선택한 DNS 필터를 사용하는 것입니다. 이 영상은 첫 번째 클라이언트 설정을 안내합니다. 취약한 IoT 기기에 대한 서두의 우려를 해결하려면 추가 네트워크 분리와 액세스 정책이 필요합니다. 기기를 새 SSID 하나에 연결하는 것만으로는 서로 격리되지 않습니다.

기존 게이트웨이가 계속 맡아야 할 역할을 결정하세요

토폴로지 설명에서는 올인원 라우터가 감출 수 있는 세 가지 역할, 즉 서비스 제공업체 연결, 라우팅되는 방화벽 경계, 무선 액세스를 구분합니다. 이더넷 연결을 새 방화벽에 연결할 수 있지만 DSL 또는 케이블 서비스를 사용하려면 적절한 모뎀이나 서비스 제공업체 장비가 여전히 필요합니다. 라우팅 기능을 교체해도 이러한 물리적 연결은 필요합니다.

크리에이터의 실제 구성에서는 기존 홈 라우터가 방화벽의 WAN 측에 연결되고 액세스 포인트는 LAN 측에 연결됩니다. 상위 게이트웨이도 네트워크 주소 변환을 수행하면 이중 NAT가 발생합니다. 처음 시험할 때는 괜찮을 수 있지만, 외부에서 접속하는 서비스와 문제 해결을 복잡하게 만들 수 있습니다. 브리지 또는 패스스루 모드를 사용할 수 있는지는 서비스 제공업체의 장비와 서비스에 따라 다르므로 운영 중인 연결을 변경하기 전에 확인하세요.

전환하기 전에 현재 인터넷 서비스 제공업체 측 설정을 기록해 두세요. 이더넷 연결 장면이 나오는 영상만으로는 ISP의 인증, VLAN 또는 모뎀 요구 사항을 알 수 없습니다. 새 경로를 클라이언트 한 대로 시험하는 동안 기존 게이트웨이 설정을 보관해 두세요. 이렇게 하면 상위 서비스 문제와 새 LAN의 설정 오류를 구분할 수 있습니다.

이중 NAT는 두 개의 라우팅 변환 경계를 뜻하며, 하위에 액세스 포인트가 있는 경우와는 다릅니다. 무선 기기가 라우팅도 계속 수행하면 경계와 DHCP 서비스가 하나 더 생길 수 있습니다. 케이스의 제품 라벨만 보고 역할을 판단하지 말고, 실제 작동 모드와 케이블 연결 위치를 확인하세요.

가상 인터페이스를 실제 WAN과 LAN 경계에 연결하세요

The Social Dork는 OPNsense 설치 이미지를 다운로드해 ZimaBoard 2의 Zima Virtual Machine에서 부팅합니다. 이는 가상화된 방화벽을 보여 주는 시연입니다. 호스트에서는 여전히 ZimaOS가 실행되므로, 게스트 내부의 OPNsense 설정뿐 아니라 호스트의 네트워크 구성도 설계에 포함됩니다.

비슷한 구성에서는 각 가상 인터페이스를 의도한 물리 포트 또는 격리된 호스트 네트워크에 명시적으로 연결하세요. 네트워크 포트가 두 개 있다고 해서 자동으로 연결되는 것은 아닙니다. WAN 측 경로를 일반 호스트 서비스와 분리하고, LAN 클라이언트 트래픽이 상위 연결에 도달하려면 반드시 방화벽을 통과하도록 하세요. 클라이언트가 VM을 우회하는 다른 경로를 사용하면 방화벽은 해당 트래픽에 정책을 적용할 수 없습니다.

선택한 이미지와 플랫폼에 맞는 최신 OPNsense 설치 안내와 가상 머신 안내를 사용하세요. 인터페이스를 변경하기 전에 호스트와 VM 콘솔에 접속하는 방법을 기록해 두세요. 호스트 재부팅, 저장 장치 문제 또는 VM 종료로 게이트웨이가 중단될 수 있으므로 가정의 인터넷 연결 상황을 고려해 유지보수 일정을 잡으세요.

인터페이스 계획을 명확히 하세요

1. 호스트의 물리 포트를 확인하고 상위 연결에 연결되는 케이블이 무엇인지 기록하세요.
2. 게스트의 WAN 측 인터페이스를 의도한 상위 네트워크에 연결하세요.
3. LAN 측 인터페이스를 별도의 하위 네트워크에 연결하세요.
4. 관리 경로와 일반 호스트 서비스가 WAN 측을 통해 의도치 않게 노출되지 않는지 확인하세요.
5. 다른 기기를 추가하기 전에 테스트 클라이언트 하나를 하위 네트워크에 연결하고 실제 기본 게이트웨이를 확인하세요.

게스트 내부의 인터페이스 이름이 물리 포트 옆에 표시된 이름과 일치하지 않을 수 있습니다. 하이퍼바이저의 네트워크 매핑과 게스트 콘솔을 사용해 두 이름의 대응 관계를 확인하세요. 가상 어댑터를 변경한 뒤에도 다시 확인하세요. 영상은 제작자의 머신에서 작동하는 구성을 보여주지만, 사용할 수 있는 모든 호스트 브리지나 어댑터 설정을 빠짐없이 다루지는 않습니다.

호스트에서 ZimaOS와 다른 서비스를 실행할 여유 용량을 남기면서 방화벽에 필요한 리소스를 할당하세요. 현재 OPNsense 가상화 가이드에는 최소 RAM 3 GB, 권장 가상 디스크 최소 용량 8 GB, 네트워크 호환성 관련 안내가 나와 있습니다. 이는 시작 조건일 뿐, 처리량을 보장하지는 않습니다. 로그, VPN, 트래픽 검사 기능 및 기타 워크로드에 따라 필요한 여유 리소스가 달라질 수 있습니다.

한 대의 머신을 공유할 때 따르는 운영상의 절충점입니다. 호스트를 업데이트하거나 재시작하면 게이트웨이 VM도 중단될 수 있습니다. 부팅 후 VM을 어떻게 시작할지, VM이 시작되지 않으면 어떻게 복구할지 정하세요. 네트워크 설정을 잘못해 웹 인터페이스에 접속할 수 없게 되었을 때는 안정적인 콘솔 연결 경로가 특히 유용합니다.

클라이언트 네트워크마다 DHCP 서비스를 하나씩 두세요

제작자는 서로 다른 업스트림 및 다운스트림 IPv4 네트워크를 사용합니다. 업스트림에는 192.168.0.x 주소를, 클라이언트 LAN에는 192.168.1.x 주소를 사용합니다. 이는 영상에 나온 예시입니다. 이미 사용 중일 수 있는 주소를 그대로 복사하지 말고, 자신의 네트워크에 맞는 서로 겹치지 않는 서브넷을 선택하세요.

액세스 포인트는 무선 연결을 제공하고, OPNsense는 다운스트림 클라이언트에 DHCP 임대 정보를 제공합니다. 이 가이드에서는 AP 모드와 기존 무선 라우터의 DHCP 서비스를 비활성화하는 방법을 설명합니다. 전용 AP 모드가 없는 장비는 DHCP만 비활성화한다고 해서 투명한 액세스 포인트로 작동하는 것이 보장되지는 않습니다. 제조업체의 LAN 간 연결 방식과 라우팅/NAT 요구 사항을 확인하세요. DHCP 풀과 충돌하지 않으면서 관리 주소에 접근할 수 있도록 하세요.

노트북 한 대에서 할당된 DHCP 임대 정보를 확인하세요. 의도한 LAN의 IP 주소, 기본 게이트웨이로 방화벽의 LAN 주소, 의도한 DNS 서버가 할당되어야 합니다. Wi-Fi 연결에 성공했다는 사실은 무선 연결이 작동한다는 것만 보여줍니다. IP 주소, 게이트웨이, DNS 리졸버를 보면 클라이언트가 실제로 새 네트워크 경로에 연결되었는지 알 수 있습니다.

고정 주소와 임대 풀을 따로 계획하세요

다음은 설명용 /24 LAN 계획이며, 제작자가 사용한 정확한 주소를 옮긴 것이 아닙니다. 기존 네트워크에 맞게 조정하세요. 인프라의 고정 주소는 동적으로 할당되는 풀 범위 밖에 예약하고, 업스트림 네트워크와 다운스트림 LAN은 서로 다른 네트워크로 설정하세요.

Pi-hole이 실제로 다른 서브넷이나 호스트 측 가상 네트워크에 있다면, 연결 가능한 실제 엔드포인트와 필요한 라우팅 및 정책을 사용하세요. 예시 주소만으로는 서비스가 LAN에 나타나지 않습니다. DHCP 항목은 클라이언트에 요청을 보낼 위치를 알려 줄 뿐, 경로를 설정하거나 서버를 시작하지는 않습니다.

DHCP를 변경한 후에는 서버 설정 페이지만 확인하지 말고 노트북의 임대 정보를 확인하세요. 할당된 주소, 서브넷 마스크, 게이트웨이, DNS 항목을 확인합니다. 클라이언트에 이전 임대 정보가 남아 있으면 새 설정이 올바른데도 작동하지 않는 것처럼 보일 수 있습니다. 예상과 다른 주소나 게이트웨이가 표시된다면 다른 DHCP 서버가 여전히 작동 중일 가능성도 있습니다.

첫 번째 허용 규칙은 연결 테스트용으로 사용하세요

제작자는 단일 테스트 노트북에 허용 범위가 넓은 아웃바운드 규칙을 적용하는 것으로 시작하며, WAN에서 LAN으로 시작되는 요청하지 않은 연결을 차단하는 방법을 설명합니다. OPNsense는 상태 기반 필터링을 사용하므로 허용된 연결에 대한 응답은 연결 상태에 따라 처리됩니다. OPNsense 방화벽 규칙 문서에서 인터페이스, 방향, 규칙 순서가 이 동작에 미치는 영향을 설명합니다.

영상에서는 비공개 상위 네트워크에서도 웹 인터페이스에 접속합니다. 직접 구축할 때는 관리자 액세스를 신뢰할 수 있는 관리 경로로 제한하고 콘솔 복구 옵션을 유지하세요. WAN이라는 레이블은 이 방화벽을 기준으로 한 역할을 나타냅니다. 상위의 비공개 랩 세그먼트와 공용 인터넷은 노출 조건이 서로 다릅니다.

처음에 제기된 IoT 관련 우려에 대응하려면 이를 지원하는 장비로 네트워크를 분리한 다음, 네트워크 간에 허용할 트래픽을 정의하세요. 같은 로컬 세그먼트 내에서 트래픽을 주고받는 기기는 라우팅 방화벽을 거치지 않고 통신할 수 있습니다. 게이트웨이 및 개인정보 보호에 관한 또 다른 실용적인 사례는 cachito labs의 OPNsense 방화벽 구축을 참조하세요.

연결성과 네트워크 격리 분리하기

규칙을 추가하기 전에 출발지, 목적지, 프로토콜, 의도한 목적을 정의하세요. 노트북 한 대가 인터넷에 연결되는지 확인하는 규칙은 가정 내 모든 기기에 적용되는 정책이 아닙니다. 네트워크를 분리하려면 별도의 네트워크를 구성하고 그 사이에 방화벽 경로를 두세요. 같은 세그먼트 내에서 주고받는 트래픽은 게이트웨이를 거치지 않을 수 있습니다.

규칙을 변경했는데도 효과가 없는 것 같다면 새 연결로 테스트하고 연결 상태를 확인하세요. OPNsense 규칙 가이드에서 상태 기반 처리에 대해 설명합니다. 기존 상태가 재테스트에 영향을 줄 수 있지만, 모든 상태를 초기화하면 다른 활성 연결이 끊어집니다. 진단을 위해 광범위한 변경을 하기 전에 구체적인 테스트 트래픽을 확인하세요.

DNS 루프를 만들지 않고 DHCP를 통해 Pi-hole에 연결하기

마무리 단계에서 The Social Dork는 DHCP로 제공되는 DNS 서버를 Pi-hole 주소로 설정합니다. 이렇게 하면 앞서 소개한 Pi-hole 및 Tailscale 광고 차단 프로젝트를 새 무선 네트워크에 적용할 수 있습니다. OPNsense는 라우팅되는 트래픽 경로를 제어하고, Pi-hole은 서비스를 통해 요청된 DNS 이름을 확인합니다. 두 구성 요소의 역할은 서로 다릅니다.

Pi-hole의 OPNsense 연동 가이드에서는 DHCP를 통한 직접 배포와 방화벽을 통한 포워딩을 서로 다른 구성 방식으로 설명합니다. 일관된 경로를 선택하고 리졸버끼리 쿼리를 서로에게 다시 전달하는 루프가 생기지 않도록 하세요. Pi-hole이 다른 네트워크에 있다면 클라이언트에서 해당 주소로 접속할 수 있는지도 확인하세요.

리졸버 경로 하나를 선택하고 처음부터 끝까지 그려 보세요

영상에서는 클라이언트에 DHCP로 제공된 Pi-hole 주소를 사용합니다. 링크된 공식 가이드의 포워딩 구성은 대안입니다. 이 구성을 선택한다면 Pi-hole의 업스트림이 요청을 동일한 포워딩 체인으로 다시 보내지 않도록 하세요. 경로가 명확하면 응답이 없는 경우를 훨씬 쉽게 진단할 수 있습니다.

DNS에도 전송 및 라우팅 종속성이 있습니다. 클라이언트와 리졸버가 서로 다른 네트워크에 있다면 경로와 관련 TCP/UDP 포트 53 정책을 확인하세요. 관찰된 결과가 DHCP 구성과 다르면 IPv6 DNS 광고 및 클라이언트의 개별 DNS 설정도 검토하세요. Pi-hole 웹 인터페이스에 접속된다는 사실만으로는 충분한 근거가 되지 않습니다.

외부에서도 필터링을 사용하려면 함께 제공된 Pi-hole 및 Tailscale 안내를 다시 확인하세요. 원격 DNS 액세스, 로컬 게이트웨이 정책, VPN을 통한 전체 인터넷 트래픽 전달은 서로 별개의 선택 사항입니다. 실제로 사용할 연결에서 각각 테스트하세요.

모든 기기를 옮기기 전에 전체 경로를 확인하세요

마지막 시연에서는 노트북의 Wi-Fi 네트워크를 바꾸고 필터링 설정을 적용한 경우와 적용하지 않은 경우에 동일한 웹사이트를 비교합니다. 이는 선택된 클라이언트 경로를 보여줄 뿐, 모든 웹사이트에 광고가 없거나 모든 기기가 격리되어 있음을 입증하지는 않습니다. 먼저 인터넷 액세스와 DNS를 확인한 다음, 관련 방화벽 및 Pi-hole 로그를 살펴 각 결과가 의도한 클라이언트와 연결되는지 확인하세요.

가정 내 기기를 옮기기 전에 클라이언트 리스 갱신, 허용된 연결, 그리고 네트워크 분할이 설계의 일부라면 별도 네트워크 간에 의도적으로 차단한 연결을 테스트하세요. 정상 작동하는 방화벽 설정을 내보내고 복구 경로를 확인하세요. 라우팅, DHCP, 필터링 및 관리를 이해하고 유지 관리할 수 있는 게이트웨이가 유용한 결과입니다. 원래 토폴로지와 설정 순서는 The Social Dork의 완전한 OPNsense 홈 방화벽 안내를 시청해 확인하세요.

단계별 승인 테스트 사용

1. 의도한 무선 네트워크에 연결하고 새 클라이언트 리스를 확인하세요.
2. 기본 게이트웨이를 확인한 다음, 적절한 경우 허용된 IP 기반 연결을 테스트하세요.
3. 선택한 리졸버를 통해 허용된 호스트 이름을 확인하고 해당 쿼리를 찾으세요.
4. 현재 Pi-hole 정책에 포함된 도메인을 테스트하고 예상한 응답이 나오는지 확인하세요.
5. 네트워크 분할을 구성했다면 라우팅 경계를 넘어 허용되는 연결과 차단되는 연결을 각각 테스트하세요.
6. 클라이언트 리스를 다시 연결하거나 갱신하고 의도한 설정이 돌아오는지 확인하세요.
7. 예정된 유지 관리 시간에 호스트와 게이트웨이 VM의 시작 경로를 확인한 다음, 상시 운영에 맡기세요.

네트워크 순서에 따라 문제 해결

로그를 사용해 한 번에 한 가지 질문에 답하세요. OPNsense의 방화벽 로그 문서에 따르면 상태 기반 흐름에서는 모든 패킷마다 실시간 로그 항목이 새로 생성되는 것은 아닙니다. 방화벽 진단 가이드에서 상태 정보를 확인할 수 있습니다. 로그가 조용하다는 사실만으로 방화벽을 통과한 트래픽이 없다고 단정할 수는 없습니다.

중요한 변경을 하기 전에 정상 작동하는 구성을 저장하고 명확한 롤백 계획을 마련하세요. 테스트 중에는 기존 연결을 별도로 유지하고, 방화벽을 우회해 외부 네트워크와 내부 네트워크가 실수로 연결되지 않도록 하세요. 유용한 롤백은 동일한 클라이언트 네트워크에 서로 경쟁하는 라우터 두 대를 추가하는 대신, 정상 작동이 확인된 게이트웨이와 클라이언트 구성을 복원합니다.

자주 묻는 질문

ZimaBoard 2만으로 Wi-Fi 무선 기능을 대체할 수 있나요?

이 동영상에서는 별도의 액세스 포인트가 Wi-Fi를 제공합니다. 보드는 가상화된 게이트웨이와 관련 서비스를 호스팅합니다. 라우팅과 무선 액세스는 서로 다른 역할입니다.

ISP 모뎀을 없애도 되나요?

서비스를 연결하는 데 더 이상 필요하지 않은 경우에만 가능합니다. DSL, 케이블 및 서비스 제공업체별 구성은 기존 종단 장비가 여전히 필요할 수 있습니다. 게이트웨이를 교체하기 전에 물리적 연결 및 서비스 요건을 확인하세요.

아웃바운드 허용 규칙이 IoT 장치를 격리해 주나요?

네트워크를 분리해 주지는 않습니다. 하나의 로컬 네트워크에 있는 장치는 라우팅 방화벽을 거치지 않고도 서로 통신할 수 있습니다. 격리하려면 별도의 네트워크와 네트워크 간 정책 검증이 필요합니다.

Pi-hole을 OPNsense 내부에서 실행해야 하나요?

시연 프로젝트에서는 가상화된 방화벽과 함께 Pi-hole 서비스를 사용하고, DHCP를 통해 해당 서비스의 주소를 알립니다. 중요한 것은 접속 가능하고 일관된 DNS 경로를 확보하는 것입니다. OPNsense를 설치하면 해당 서비스도 함께 설치된다고 가정하지 마세요.

방화벽 VM에 네트워크 경로가 두 개 필요한 이유는 무엇인가요?

라우팅 설계에는 외부 네트워크로 연결되는 경로와 별도의 내부 네트워크 경로가 필요합니다. 게스트와 호스트 간 매핑을 올바르게 설정해야 이러한 경계가 형성됩니다. 어댑터 이름이 두 개 표시된다는 것만으로는 네트워크가 격리되었다고 볼 수 없습니다.

ZimaOS 호스트를 재시작하면 어떻게 되나요?

게스트 방화벽과 그 밖의 호스팅 서비스가 작동하지 않을 수 있습니다. VM 시작 및 복구를 계획하고, 유지보수 시간에 이를 검증하세요. 하드웨어를 공유한다면 호스트 유지보수도 게이트웨이 가용성에 영향을 줍니다.

결론

The Social Dork의 구축 사례가 유용한 이유는 일체형 게이트웨이를 이해하기 쉬운 여러 역할, 즉 인터넷 서비스 연결, 가상화된 라우팅, 무선 액세스, 주소 할당, DNS 필터링으로 나누기 때문입니다. 노트북에서 처음으로 연결에 성공한 테스트는 출발점이 됩니다. 잘 관리되는 홈 게이트웨이를 위해서는 네트워크 경계 검증, 각 클라이언트 그룹에 적합한 정책, 복구 경로도 필요합니다.

가정 내 네트워크를 전환하기 전에 단일 클라이언트 점검을 완료한 다음, 추가 세분화나 VPN 동작을 별도로 검증하세요. OPNsense 동영상 안내를 자체 인터페이스 계획 및 최신 공식 문서와 함께 참고하세요. 목표는 동작을 설명하고 테스트하고 복구할 수 있는 네트워크를 구축하는 것입니다.