본문으로 이동
PEERYXNETWORK

Defense Fabric 구축 및 운영 가이드

자체 인프라에 필터링 소프트웨어를 설치하고 운영하는 네트워크 팀을 위한 실무 참고 자료입니다.

이 가이드의 내용

설치에서 운영 적용까지

  1. 호환되는 서버와 독립적인 관리 접속 경로를 준비합니다.
  2. 라이선스를 만들고 포트를 할당한 뒤 서버를 등록합니다.
  3. 관찰 모드에서 인터페이스, 텔레메트리, 라우팅을 검증합니다.
  4. 정상 트래픽, 공격 완화, 우회 해제와 장애 복구를 테스트합니다.

소프트웨어의 역할

Defense Fabric은 고객의 서버에서 탐지, 패킷 필터링, 정책 제어를 수행합니다. 로컬 처리 용량은 해당 서버와 링크에 따라 달라집니다. Peeryx 보호 IP 트랜짓의 업스트림 네트워크 용량은 소프트웨어 라이선스에 포함되지 않습니다.

Flow Collector는 관찰과 우회 제어를 위한 별도의 무료 도구이며 Defense Fabric 필터링 엔진을 대체하지 않습니다. Peeryx 트랜짓은 트래픽을 상위 네트워크에서 필터링할 수 있도록 별도로 제공되는 네트워크 서비스입니다.

서버 및 운영체제

현재 설치 프로그램은 Debian 12를 대상으로 하며, 배포되는 필터링 플러그인은 x86-64용입니다. 장비에 귀속되는 라이선스에는 TPM 2.0이 필요합니다. 설치 프로그램은 VPP와 플러그인을 25.10-release로 고정합니다. 운영체제를 업데이트하면서 다른 VPP ABI로 교체하지 마세요.

  • 독립적인 관리 접속, 정상 DNS, 정확한 시스템 시각, 등록·라이선스 확인·서명된 업데이트에 필요한 아웃바운드 HTTPS를 준비합니다.
  • CPU, 메모리 구성, NUMA 배치, PCIe 레인 폭, NIC의 정확한 부품 번호, 펌웨어, 드라이버, 광모듈을 함께 검증합니다. ConnectX 제품군 이름만으로 호환성을 확인할 수는 없습니다.
  • 서버 관리와 트래픽 인터페이스를 분리합니다. 엔진, 플로우 수집, 진단 자료 보관에 충분한 CPU, 메모리, 저장 공간을 확보합니다.

용량 산정과 성능 근거

Gbit/s와 Mpps를 함께 살펴보세요. 100 Gbit/s 이더넷에서 64바이트 프레임은 프리앰블과 프레임 간 간격을 포함하면 이론상 약 148.81 Mpps입니다. 이는 회선 속도 계산값이며 필터링 측정 결과가 아닙니다. 포트 두 개가 종단 간 용량 두 배를 보장하지는 않습니다.

공개한 하드웨어 구성은 적합성 검증 후보입니다. 해당 구성의 재현 가능한 성능 보고서는 공개되어 있지 않습니다. 실제 장비에 예정된 규칙 수와 패킷 크기를 적용하고, 정상 트래픽을 함께 흘리며 완화 기능을 켠 상태로 시험하세요. 처리량뿐 아니라 손실, 지연, 복구도 기록합니다.

필터링 서버 구성 선택 →

라이선스, 포트, 서버

기본 라이선스에는 10G 포트 하나가 포함됩니다. 구매한 포트는 해당 라이선스가 관리하는 서버 간에 공유하는 풀을 구성합니다. 두 번째 서버를 설치해도 풀은 복제되지 않습니다. 유료 운영 전에 서버별로 필요한 포트 속도와 개수를 할당하세요. 라이선스당 관리 한도는 서버 128대입니다.

14일 체험에는 포트 개수나 선언된 속도에 대한 소프트웨어 할당량 제한이 없습니다. 물리적 한계, 하드웨어 검증, 네트워크 활성화 요건은 그대로 적용됩니다. 서버를 추가해도 체험 기간은 다시 시작되지 않습니다.

라이선스 유효성, 서버 신원, 라우팅 준비 상태는 별도로 확인해야 합니다. 체험 종료 후 라이선스 기반 운영을 계속하려면 결제와 유효한 사용 권한이 필요합니다. 적용되는 만료일과 갱신 상태는 고객 포털에 표시됩니다.

월간 라이선스 구성 →

설치 및 등록

고객 계정의 Defense Fabric 페이지에서 시작합니다. 구독을 만들거나 선택하고 서버를 추가한 뒤, 유효기간이 짧은 일회용 등록 토큰을 생성합니다. 해당 서버의 설치 지침을 사용하고 신원 정보와 토큰을 비공개로 보관하세요.

설치 프로그램은 Debian 12, TPM 사용 가능 여부, 필요한 VPP 버전을 확인합니다. 별도의 데이터 플레인이 이미 실행 중이면 덮어쓰지 말고 점검 및 이전 계획을 세우세요. 서명 검증과 등록 성공만으로 고객 트래픽이 보호되고 있음을 입증할 수는 없습니다.

  • 설치 버전을 기록하고 설치 결과를 확인합니다.
  • 포털 연결, 필터링 엔진, 할당 포트, 인터페이스 카운터를 각각 확인합니다.
  • 전달 경로와 반환 경로의 테스트가 끝날 때까지 관찰 상태를 유지합니다.

인터페이스와 정제 트래픽 반환 경로

필터링할 트래픽을 받는 입력과 정제된 트래픽을 돌려보내는 별도의 논리 인터페이스를 구분합니다. 라우터와 필터링 서버 양쪽에서 VLAN, 주소, 게이트웨이, MTU, 다음 홉 도달성을 확인하세요. Linux 관리 인터페이스 카운터를 필터링 포트 카운터와 혼동하지 마세요.

우회한 트래픽이 다시 미정제 입력으로 들어가 루프를 만들지 않도록 합니다. 제어 평면과 정제 트래픽 게이트웨이 주소는 보호 대상 주소 범위 밖에 두세요. 경로가 준비되었다고 판단하기 전에 실제 고객 트래픽을 양방향으로 측정합니다.

인라인, BGP 우회, 하이브리드

인라인: 트래픽이 항상 로컬 필터링 경로를 통과합니다. 서버, 인터페이스, 전원 장애 시 동작을 검증하세요. 소프트웨어를 설치하는 것만으로 물리적 바이패스가 생기지는 않습니다.

BGP 우회: 라우터가 선택한 공격 대상의 트래픽을 필터링 다음 홉으로 보냅니다. 명시적인 import/export 필터와 커뮤니티를 설정하고, 광고, FIB 반영, 정제 반환 경로, 철회를 확인합니다. 플로우 내보내기 지연과 라우팅 수렴은 응답 시간에 영향을 줍니다.

하이브리드: 업스트림 완화가 필요할 때 로컬 필터링에 Peeryx 보호 트랜짓을 결합합니다. 트랜짓은 별도의 활성화, 승인된 프리픽스, 시험한 전달 경로가 필요합니다. 라이선스를 구매했다고 업스트림 라우팅이 바뀌었다고 가정하지 마세요.

BGP, FlowSpec, RTBH

Router ID, 로컬 및 피어 주소, ASN, 도달 가능한 필터링 다음 홉, 합의된 우회 커뮤니티를 설정합니다. 포털의 라우팅 스위치는 에이전트가 세션과 광고를 관리하도록 허용합니다. 초안 저장은 라우터가 의도한 경로를 설치했다는 확인이 아닙니다.

FlowSpec은 기능이 켜져 있고 시뮬레이션이 꺼져 있으며 해당 BGP 주소군이 연결되었을 때만 선택적 업스트림 규칙을 내보냅니다. dry-run부터 시작하여 생성 규칙과 라우터의 지원 기능·한계를 확인하세요. 포털은 동시 규칙 수를 50개로 제한합니다.

RTBH는 최후 수단으로, 정상 트래픽을 포함한 해당 목적지의 모든 트래픽을 폐기합니다. 임계값, 조건 지속 시간, 철회까지의 유효기간을 별도 제어 항목으로 다루고 복구도 시험하세요.

sFlow, NetFlow, IPFIX

허용된 익스포터가 도달할 수 있는 주소에서 수집을 켭니다. 사설 네트워크나 VPN 사용을 권장합니다. 기본 수신 포트는 UDP 6343입니다. 양쪽 포트를 맞추고 익스포터 허용 목록을 제한하세요. 무제한으로 접근 가능한 수집기를 인터넷에 노출하지 마세요.

탐지 임계값을 고르기 전에 샘플링과 익스포터 타임아웃을 확인합니다. sFlow에는 샘플링 비율이 포함됩니다. NetFlow/IPFIX 익스포터가 비율을 제공하지 않을 때는 설정된 배수를 사용합니다. 수집 구간은 5~60초로 설정할 수 있습니다.

추정 속도를 인터페이스 카운터와 비교하고 데이터의 최신성을 확인합니다. 내보낸 데이터가 없다고 트래픽이나 공격이 끝났다는 뜻은 아닙니다. 패킷 캡처와 플로우 추정치는 서로 다른 관측입니다.

프리픽스, 임계값, 복구

보호 정책에는 등록된 IPv4 /24 블록과 그 내부의 /32 예외를 사용합니다. 프로파일 적용 전에 정상 트래픽 양상을 확인하세요. 이 버전의 프로토콜별·목적지별 탐지 임계값은 PPS 단위입니다. FlowSpec과 RTBH의 Gbit/s 설정은 각 기능의 별도 용량 판단에 사용됩니다.

Monitor는 공격 우회 없이 관찰합니다. Automatic은 탐지된 공격 동안 우회합니다. Permanent는 검증된 필터링 경로를 계속 활성화합니다. 해제 임계값을 진입 임계값보다 낮게 설정하고 유지 시간을 두어 변동하는 공격 때문에 경로가 반복 변경되지 않도록 합니다.

프로파일은 프로토콜 임계값을 불러옵니다. 애플리케이션 허용 목록이 아니며, 더 엄격한 프로파일이 더 바쁜 네트워크에 자동으로 적합한 것도 아닙니다.

적응형 규칙과 TCP/UDP 보호

적응형 탐지는 관찰 모드에서 시그니처를 평가하거나 활성 모드에서 생성된 규칙을 적용합니다. 제외하거나 백엔드를 바꾸기 전에 기록된 시그니처와 정상 트래픽에 미치는 영향을 살펴보세요. 백엔드는 설치 버전과 검증된 하드웨어에 맞아야 합니다.

SYN proxy는 연결 수립을 검증하며 시험된 대칭 경로가 필요합니다. SYN challenge는 지원되는 비대칭 구성용입니다. 두 기능을 서로 바꾸어 쓸 수는 없으며 포털은 호환되지 않는 조합을 막습니다. SYNACK 전용 검증도 문서에 명시된 대칭 경로가 필요합니다.

소스 할당량은 해당 기능을 켠 프리픽스에서 소스 IP별 UDP 또는 SYN/SYNACK 합산 패킷 수를 제한합니다. NAT, VPN, 프록시 사용자는 소스 주소 하나를 공유할 수 있습니다. 할당량을 정할 때 정상적인 합산 트래픽을 고려하세요.

예외와 필터링 이후 방화벽

등록된 /24 안의 특정 호스트에는 /32 예외를 사용합니다. 범위를 좁히고 문서화하세요. accept 규칙은 필터링 이후의 방화벽 단계에 적용됩니다. 앞 단계에서 폐기된 패킷을 복구하거나 모든 다른 보호 검사를 우회하도록 보장하지 않습니다.

포털은 프리픽스당 순서가 있는 방화벽 우선순위를 최대 20개 허용합니다. 적용 전에 프로토콜, 소스 범위, 목적지 포트, 속도 단위를 확인하세요. TCP/UDP 포트 조건은 모든 IP 프로토콜에 의미가 있는 것은 아닙니다.

포털, 보고서, API

포털 연결, 엔진 상태, BGP 상태, 트래픽 보호 준비 상태를 따로 읽으세요. 연결된 에이전트나 실행 중인 프로세스는 성공적인 전달 테스트가 아닙니다. 통계는 샘플링 값이므로 오래된 데이터를 트래픽 0으로 보지 말고 조사해야 합니다.

공격 기록, 저장된 완화 규칙, 사용 가능한 PCAP·ZIP·PDF 자료는 사고 분석에 도움이 됩니다. 보존 기간과 패킷 샘플링에 따라 재구성할 수 있는 정보가 제한됩니다. 내보내기 파일이 항상 공격의 전체 캡처인 것은 아닙니다.

지원 작업과 권한 범위는 공개 OpenAPI 명세를 확인하세요. 인증이 필요하므로 토큰을 필요한 계정과 권한에 한정합니다. 정책 쓰기는 리비전을 사용하고 적용 대기 상태를 반환합니다. 변경이 적용되었다고 판단하기 전에 노드 상태를 확인하세요. 포털의 비공개 내부 인터페이스에 의존하는 자동화를 만들지 마세요.

OpenAPI · JSON →

여러 서버와 ECMP

공유 라이선스와 두 번째 서버만으로 자동 상태 복제나 고가용성이 만들어지지는 않습니다. 전체 네트워크 설계에 대해 장애 감지, 경로 선호도, 철회, 복구를 정의하고 각 장애를 따로 시험하세요.

지원되는 두 번째 링크 설계는 같은 ASN의 직접 연결 iBGP와 미정제·정제 트래픽용 분리 VLAN을 사용하며 Fabric 2.8.0 이상이 필요합니다. 각 세션은 고유한 로컬 다음 홉을 사용합니다. ECMP는 플로우를 분산하므로 단일 플로우는 한 링크에 남을 수 있습니다.

SYN proxy와 SYNACK challenge는 이 이중 경로 모드에서 적합성이 검증되지 않았습니다. 100G 링크 두 개가 200 Gbit/s 필터링 성능을 보장하지는 않습니다.

업데이트와 설정 복구

포털의 서명된 업데이트 절차를 사용합니다. 업데이트가 필터링 엔진을 재시작할 수 있으므로 점검 시간을 계획하세요. 시작 전에 목표 버전을 확인하고 독립적인 접속 경로를 확보합니다.

업데이터는 버전을 검증하고 설정을 보존하며 복구 파일을 준비합니다. 설치가 실패하면 진단 자료와 복구된 상태를 살펴보세요. 롤백이 되었다고 모든 네트워크 경로가 복구된 것으로 간주해서는 안 됩니다.

정책을 바꾸기 전에 관련 설정을 저장하고 예정된 변경을 비교합니다. 백업과 인증 정보는 비공개로 보관하세요. 트래픽을 다시 우회시키기 전에 복원한 정책이 실행 중인 소프트웨어에서 유효한지 검증합니다.

운영 적용 전 인수 점검표

실서비스를 우회시키기 전에 인수 시험과 원복 조건을 합의하세요. 생성 권한이 있는 트래픽과 통제 가능한 시험 목적지를 사용합니다.

  • 기준선: 보호가 꺼진 상태와 켜진 상태에서 정상 트래픽, 카운터, 손실, 애플리케이션 접근성을 비교합니다.
  • 탐지: 범위를 제한한 이벤트로 시험하고 의도한 목적지, 규칙, 경로만 영향을 받는지 확인합니다.
  • 복구: 이벤트를 중단하고 설정된 유지 시간이 지난 뒤 규칙 철회와 정상 전달을 확인합니다.
  • 장애: 익스포터, BGP, 필터링 노드 상실을 별도로 시험합니다. 실제 경로와 장애 시 트래픽 통과 또는 차단 여부를 확인합니다.
  • 버전, 서버, NIC, 패킷 크기, 규칙 수, 샘플링, 시험 시간, 손실, 지연을 기록합니다. 성공과 원복 양쪽의 증거를 보관합니다.

실패한 계층별로 진단

포털 연결이 없을 때: 관리 연결, DNS, 시각, HTTPS, 신원, 라이선스를 확인합니다. 관리 연결만 복구하려고 운영 BGP를 바꾸지 마세요.

엔진은 작동하지만 보호 트래픽이 없을 때: 필터링 인터페이스, VLAN, 다음 홉, 실제 RX/TX 카운터를 확인합니다. BGP 세션 상태와 별도로 라우터 FIB와 정제 반환 경로를 점검합니다.

예상치 못한 완화가 발생할 때: 측정된 정상 속도, 샘플링, 프로파일, 기록된 규칙을 비교합니다. 저장된 초안을 수정하고 검토한 뒤 의도적으로 적용하세요. 프로세스 재시작이나 경로 삭제 전에 진단 자료부터 수집합니다.

알려진 제한

이 가이드는 배포된 Debian 12/x86-64 버전과 IPv4 보호 절차를 설명합니다. 다른 운영체제, 임의의 NIC, IPv6 정책 기능 동등성, 무손실 전환, 특정 Mpps 성능을 인증하지 않습니다.

로컬 필터링은 이미 업스트림에서 포화된 대역폭을 되찾을 수 없습니다. Peeryx 트랜짓은 필터링 지점을 상위 네트워크로 옮기는 별도 서비스입니다. Flow Collector는 별도로 검증한 온디맨드 설계를 지원할 수 있습니다.

SYN 관련 기능, ECMP, 자동 라우팅은 각각 호환성 요건이 있습니다. 테스트하지 않은 조합은 검증 대상으로 취급해야 하며, 이미 활성화된 서비스로 보면 안 됩니다.

Peeryx Flow Collector →

구축 계획 검토 요청

서버 및 NIC 모델, 사용 가능한 링크 용량, 예정된 트래픽 경로, ASN, 필요한 보호 기능을 알려 주세요. 공개 메시지에는 라이선스 키나 등록 토큰을 넣지 마세요.

구축 계획 검토 요청 →