Xena VulcanBay를 사용한 방화벽 성능 테스트

이 구체적인 테스트 사례에서는 2개의 40Gbps QSFP+ 인터페이스를 갖춘 Xena VulcanBay를 사용하여 차세대 방화벽의 성능을 테스트했습니다. 구체적으로 다음과 같은 테스트 시나리오에 관심이 있었습니다.

• 순수 처리량
• 연결 수가 많음(세션 부하)
• NAT 사용
• 현실적인 교통
• 잠재적인 처리량 침해를 감지하기 위해 새로운 방화벽 규칙을 "추진"하는 더 긴 테스트 기간

이 글에서는 Xena VulcanBay를 관리 도구, VulcanManager, 그리고 Cisco Nexus Switch를 사용하여 방화벽 클러스터를 연결하는 방법을 소개합니다. 테스트 시나리오를 나열하고 잠재적인 문제점에 대한 몇 가지 힌트를 제공합니다.

테스트에는 펌웨어 버전 28, 40G 인터페이스 라이선스, 그리고 3.6.0개의 패킷 엔진을 모두 사용할 수 있는 Xena VulcanBay Vul-40PE-28G를 사용했습니다. VulcanManager는 버전 2.1.23.0에서 실행되었습니다. VulcanBay를 하나만 사용했기 때문에(분산된 위치에 여러 개를 사용하지 않았기 때문에), 유일한 관리자 사용자가 28개의 패킷 엔진을 이 두 포트에 균등하게 분배할 수 있었습니다.

 

최대 80G 처리량을 가진 테스트의 경우, 두 개의 QSFP+ 모듈(왼쪽)과 이러한 포트에 패킷 엔진을 분산하는 것(오른쪽)이 충분했습니다.배선

충분한 QSFP+ 모듈과 해당 처리량을 갖춘 단일 Cisco Nexus 스위치를 사용하여 VulcanBay를 각 방화벽 클러스터에 연결했습니다. 모든 방화벽 클러스터와 VulcanBay를 이 스위치에 동시에 연결했고, 테스트에 항상 동일한 IPv4/IPv6 주소 범위를 사용했기 때문에, 개별 인터페이스의 "종료/비종료"만으로 어떤 방화벽 제조업체를 테스트할지 결정할 수 있었습니다. 따라서 전체 실험실을 원격으로 제어할 수 있었습니다. 일반적인 재택근무 직원에게 매우 실용적이었습니다. 더욱이, 모든 테스트에서 유의미한 기준값을 얻기 위해 VulcanBay를 "자기 자신"에 연결하는 것이 매우 쉬웠습니다. 이를 위해 VulcanBay에 연결된 두 개의 40G 인터페이스는 모두 동일한 VLAN에 임시로 구성되었습니다.

 

클라이언트와 서버 각각에 두 개의 회선을 사용하여 모든 방화벽 클러스터는 중앙 스위치에 연결되었습니다. 또한 VulcanBay도 포함되었습니다. Neox Networks.

QSFP+ 모듈이 있는 스위치도 있는데, 이 스위치는 4x 10G로 설계되었으며 1x 40G로 설계되지 *않습니다*. 40G 인터페이스가 있는 VulcanBay를 연결하는 경우 후자는 불가피합니다.

 

40G 인터페이스를 갖춘 최신 QSFP+ 슬롯 덕분에 두 개의 연결만으로 80Gbit/s의 이중 처리량을 달성할 수 있습니다.IP 서브넷

저희의 경우, 레이어 3 모드에서 다양한 방화벽을 테스트하고자 했습니다. 이를 위해 "테스트 대상 장치(DUT)"의 라우팅을 통합하고자 구형 IPv4 프로토콜과 IPv6 프로토콜 모두에 적합한 서브넷을 생성했습니다. VulcanBay에서 시뮬레이션된 IP 서브넷은 방화벽에 직접 연결됩니다. 예를 들어 /16 IPv4 서브넷을 사용하는 경우입니다. network바로 이것 /16 network 방화벽에서도 설정을 구성해야 합니다. 특히 중요한 것은 기본 게이트웨이 설정인데, 예를 들어 클라이언트 IPv4의 경우 10.0.0.1로 설정해야 합니다. network추가로 "ARP 사용" 옵션(오른쪽)을 사용하면 표시되는 MAC 주소에 대해 걱정할 필요가 없습니다. VulcanBay가 자체적으로 MAC 주소를 확인합니다.

 

테스트가 MAC 플러딩과 동일하지 않도록 주소 범위를 조정해야 합니다.

IPv6에도 동일하게 적용됩니다. 여기서는 network 일반적인 슬래시 표기법으로 입력하는 대신 게이트웨이와 주소 범위만 자동으로 결정됩니다. "NDP 사용"을 통해 VulcanBay는 레이어 2 MAC 주소를 레이어 3 IPv6 주소로 자동 변환합니다.

 

"게이트웨이 사용"은 VulcanBay에 테스트에 중간 라우터/방화벽을 사용해야 한다고 알려줍니다.

MAC 플러딩! 사용된 테스트 시나리오에 따라 VulcanBay는 클라이언트 또는 서버 세그먼트에서 수백만 개의 IPv4/IPv6 주소를 시뮬레이션할 수 있습니다. 이는 모든 중간 스위치 또는 방화벽에 대한 순수한 MAC 주소 플러딩입니다. 일반적인 고급 가중치는 MAC 주소 테이블에 최대 128k 개의 MAC 주소를 저장할 수 있습니다. Xena Networks에서 기본적으로 설정한 16만(!) 개의 IPv4 주소 또는 1.8 x 10^19개의 IPv6 주소라는 기본 범위를 그대로 두면 테스트 결과가 무의미해집니다. 따라서 위 스크린샷(노란색 표시: 65k 주소)에서 볼 수 있듯이 처음부터 주소 범위를 현실적인 값으로 줄이는 것을 강력히 권장합니다.

참고 값을 얻기 위해 모든 테스트에서 VulcanBay는 "자체적으로 연결"되었습니다. IPv4는 동일한 "서브넷"을 사용할 수 있도록 허용했습니다. network주소 범위가 다른 경우 IPv6에서는 *동일한* /64 접두사 내의 서브넷이 필요합니다.테스트 사례

1) 순수 처리량: 첫 번째 테스트 시나리오에서는 방화벽의 처리량에만 집중했습니다. 이를 위해 IPv4와 IPv6에 각각 한 번씩 "패턴" 시나리오를 선택했는데, 이 시나리오에서는 자동으로 비율을 50:50으로 설정합니다. 설정에서 "양방향"을 선택하여 데이터를 양방향으로 전송(두 경우 모두 이중화)했습니다. 따라서 80개의 2G 인터페이스로 최대 처리량 40G에 도달할 수 있었습니다. 대역폭을 여러 세션에 분산하기 위해(실제 테스트에서는 이것이 더 현실적인 테스트 사례입니다), 1000명의 사용자를 선택했고, 각 사용자는 100개의 소스 포트에서 10개의 서버로 연결을 설정해야 했습니다. IPv1와 IPv4 각각에 대해 6만 개의 세션을 생성합니다. 5초의 램프업 시간(즉각적인 최대 부하 대신 연결 수가 부드럽게 증가하는 시간)을 설정하여 순수 테스트를 120초 동안 진행한 후 5초의 램프다운 시간을 가졌습니다.

 

IPv50와 IPv50가 4:6으로 분포된 테스트 시나리오 "패턴"입니다. "부하 프로필"(오른쪽)은 시간 축을 사용하여 시뮬레이션 대상 사용자를 보여줍니다.

테스트 중에 VulcanManager는 TCP 연결이나 레이어 1 처리량과 같은 유용한 데이터를 표시합니다. 상단 영역의 그래픽을 통해 한눈에 좋은 인상을 받을 수 있습니다. 다음 스크린샷에서 활성 연결 수가 계획된 연결 수의 절반에도 미치지 못하는 것을 확인할 수 있으며(나쁨), 레이어 5-7 Goodput은 테스트 시작 시 좋지 않은 문제가 있습니다. 두 문제 모두 테스트 대상 장치의 IPv6 구현 오류로 밝혀졌습니다.

 

이론적으로 2G 처리량에서 80만 개의 세션이 방화벽을 통과했어야 하지만, 그 중 절반도 통과하지 못했습니다.

"활성 세션" 그래픽은 실제 활성 세션을 보여주는 것이 아니라, 테스트 중 라이브 뷰와 이후 PDF 보고서에서 시뮬레이션된 사용자 수를 보여줍니다. 그래프는 2000명의 사용자를 정확하게 보여주지만, 실제로 테스트 기간 동안 2만 개의 세션이 존재했습니다.

2) 많은 연결 수(세션 부하): IPv4와 IPv6의 경우에도 이 테스트 동안 20천만 개의 병렬 TCP 세션이 설정 및 유지되었습니다. 세션 수의 합뿐만 아니라, 단 30초라는 짧은 램프업 시간도 중요했습니다. 이는 초당 667,000만 60천 개의 연결 설정 속도에 해당합니다! 세션은 30초 동안 데이터 전송 없이 유지되었습니다. 이후 XNUMX초 동안 TCP에서 일반적으로 FIN-ACK를 통해 세션이 다시 종료되었습니다. 테스트의 목표는 테스트 대상 방화벽이 연결을 정상적으로 통과시키고, 두 번째로 연결을 완전히 해제하여 메모리를 확보하는 것이었습니다.

각 테스트 전에 스위치의 MAC 주소 테이블과 방화벽의 세션, ARP, NDP 캐시를 삭제했습니다. 따라서 모든 테스트는 처음부터 끝까지 완벽하게 진행되었습니다.

3) NAT 시나리오: 1)과 동일한 테스트를 사용했으며, 유일한 차이점은 클라이언트의 IPv4 연결 방식입니다. network 서버에 network 방화벽에 소스 NAT가 설정되었습니다. 목표는 이로 인해 방화벽 성능이 저하되는지 여부를 확인하는 것이었습니다.

4) 현실적인 트래픽: 미리 정의된 "데이터센터 믹스"를 통해 단 몇 번의 클릭만으로 수천 명의 사용자를 대상으로 HTTPS, SMB2, LDAP, AFS(UDP 및 TCP 경유) 연결 흐름을 시뮬레이션할 수 있었습니다. 이는 방화벽의 전체 부하 테스트가 아니라, 설치 및 해체 속도와 애플리케이션 탐지에 대한 테스트였습니다. 방화벽의 앱 ID가 활성화되었는지 비활성화되었는지에 따라 큰 차이가 있었습니다.

5) 커밋을 포함한 10분 연속 실행: 이 테스트는 시나리오 1과 4, 즉 전체 부하(1)와 동시에 세션 설정 및 종료(4)를 지속적으로 실행하는 시나리오로 구성되었습니다. 각 방화벽에 10개의 규칙을 추가로 설치하는 동안 이 테스트는 500분 동안 지속적으로 실행되었습니다. 이 테스트에서는 이 프로세스가 방화벽 처리량에 측정 가능한 문제를 일으키는지 확인하고자 했으며, 실제로도 어느 정도 문제가 발생했습니다.시험 결과

각 테스트가 끝나면 VulcanManager는 가능한 모든 세부 정보가 포함된 통계 및 보고 페이지를 표시합니다. "보고서 생성"을 통해 모든 세부 정보 외에도 선택한 테스트 시나리오 및 테스트 대상 장치에 대한 정보가 포함된 PDF 파일을 생성할 수 있습니다. 중요한 것은 관련 수치와 관련성이 낮은 수치를 구분하고 적절한 맥락에 배치하여 의미 있는 결과를 얻는 것입니다. 다양한 차세대 방화벽을 비교하는 동안 처리량 테스트에는 "계층 1 안정 처리량(bps)", 연결 테스트에는 "성공적인 TCP 연결"만 사용했습니다. VulcanBay가 연결된 기준값과 비교했을 때, 표와 그래픽으로 쉽게 표시할 수 있는 의미 있는 비교 결과를 얻을 수 있었습니다.

 

통계 및 보고 페이지에서는 대략적인 개요(중간)를 제공하고 모든 OSI 계층과 선택한 테스트 시나리오에서 테스트 값을 읽을 수 있는 기능(링크, 폴드아웃 탭)을 제공합니다.

 

모든 세부 정보가 포함된 PDF 보고서의 세부 정보입니다.

Xena Networks의 다양한 기존 "애플리케이션 조합" 시나리오는 방화벽 성능 값을 직접 비교하는 용도가 아니라, 특정 목적에 맞는 생성 방식을 제공합니다. network 트래픽을 분석하는 방식입니다. 이를 통해 애플리케이션 감지 기능을 확인하거나 병렬로 실행되는 다른 시나리오에 대한 부하를 조금 더 높일 수 있습니다.추가 기능

VulcanManager에는 본 사례 연구에서 사용하지 않은 몇 가지 흥미로운 기능이 있습니다. 예를 들어 TLS 트래픽(TLS 가로채기 테스트용)과 패킷 리플레이(업로드된 PCAP에서 추출한 맞춤형 시나리오 및 더욱 구체적인 시나리오 테스트용)가 있습니다. 또한 Dropbox, eBay, LinkedIn, HTTPS, IMAP, NFS와 같은 애플리케이션 또는 프로토콜 기반 테스트 시나리오는 사용하지 않았습니다. 이는 테스트 목적이 순수 처리량과 세션 수에 중점을 두었기 때문입니다.맺음말

XENA Networks의 VulcanBay는 다양한 차세대 방화벽을 비교하는 데 이상적인 테스트 장비입니다. 매우 짧은 시간 안에 다양한 테스트 시나리오를 구성하고 테스트했습니다. 처음에는 테스트 결과의 양이 너무 많아서 감당하기 어려웠습니다. 중요한 것은 관련 정보에 집중하는 것이었습니다.