Virtio의 pfSense: offload를 끄기 전까지 TCP가 멈춘다

한 클라이언트의 보고에 따르면 터널은 연결되고 ping은 응답하며 로그인 페이지도 로드되지만, 그다음 전송이 매번 같은 지점에서 멈춥니다. 이 패턴만으로도 도달성은 작동하고 지속 처리량은 작동하지 않는다는 것을 알 수 있습니다. 방화벽을 열기 전에 VPN이 애초에 이 장애에 관여하는지 확인하십시오. 경로에 터널을 두지 않고 같은 게이트웨이로 큰 TCP를 흘려보내고, 그것도 멈춘다면 OpenVPN은 처음부터 무관했습니다.

virtio 네트워크 카드를 쓰는 pfSense 게스트가 정확히 그런 형태로 실패할 매우 좋은 이유가 있습니다.

작은 패킷은 통과하고 대용량 TCP는 멈춘다

핸드셰이크, DNS 응답, ICMP 에코는 작아서 보통 통과합니다. 지속적인 전송은 게스트가 세그먼트를 만들도록 강제하며, 손상된 offload 경로는 바로 그 지점에서 드러납니다. 장애가 대칭일 필요는 없는데, 나가는 트래픽은 깨끗한데 들어오는 트래픽이 떨어지거나 그 반대일 수 있어 사용자가 로그인은 하되 첫 번째 큰 응답에서 멈출 수 있습니다. 같은 클라이언트가 다른 게이트웨이에서는 되기 때문에 가장 최근 구성 요소가 책임을 뒤집어씁니다.

그래서 터널 없이 게이트웨이를 시험하십시오. 몇 초쯤 지속될 만큼 큰 LAN에서 WAN으로의 다운로드면 충분하며, 이후 비교가 의미를 가지려면 어떤 설정 변경보다 먼저 해야 합니다.

offload가 실제로 약속하는 것

virtio는 반가상화로, 호스트와 게스트가 작업을 나누고 호스트는 체크섬과 세그멘테이션 기능을 알리며 게스트가 시작한 일을 끝내기를 기대합니다. 게스트의 스택이 그렇게 하지 않으면 프레임은 불완전한 체크섬으로 나가거나 호스트가 버립니다. 에뮬레이트된 E1000은 더 단순하고 느린 모델을 제공하며, 그 경우 pfSense를 한 줄도 바꾸지 않고 문제가 사라집니다. 기능 협상은 장치마다 이루어지므로 한 게스트는 몇 달을 돌고 다시 만든 쌍둥이는 첫날 실패합니다.

협상된 집합은 하이퍼바이저 버전과 선택한 NIC 모델에 달려 있으며, 가져온 구성에만 달려 있지 않습니다.

체크박스 하나로 virtio를 유지할 수 있다

pfSense 인터페이스에서는 시스템, 그다음 고급, 그다음 네트워킹 경로에 하드웨어 체크섬 offload 비활성화라는 체크박스가 있습니다. 이를 선택하면 게스트가 체크섬을 소프트웨어로 계산하며, 이는 pfSense 뒤의 FreeBSD 스택이 반가상 장치에 기대하는 것과 일치합니다. 같은 페이지의 관련 옵션 두 개가 하드웨어 TCP 세그멘테이션 offload와 하드웨어 대형 수신 offload를 다룹니다. 핸드셰이크는 되는데 대용량 전송이 안 될 때 이것들을 찾으십시오.

변경하는 동안 NIC는 virtio로 두십시오. E1000으로 바꾸면 VM 수명 내내 패킷마다 CPU를 태우고, 호스트를 물려받는 누구에게서든 구성 문제를 감추므로, 조금 느리지만 예측 가능한 데이터 경로보다 나쁜 거래입니다.

방금 받아들인 비용을 측정하라

소프트웨어 체크섬은 작업을 게스트로 옮기므로, 비용이 없다고 가정하지 말고 나중에 처리량을 측정하십시오. 작은 VM에서 대가는 실제이지만 조용한 손실과 달리 눈에 보이고 안정적입니다. 변경 전후로 인터페이스 오류 카운터와 게스트 커널 로그를 비교하십시오. 브리지를 필터링하는 하이퍼바이저는 다른 증거를 가진 별개의 장애이며 어떤 offload 플래그도 그것을 고치지 못합니다.

시험마다 한 가지만 바꾸고 메뉴 경로, 선택한 체크박스, 측정한 숫자를 적어 두십시오. 다음에 다시 만든 게스트를 마주할 사람은 세 가지를 모두 원할 것입니다.

BSD 기반의 다른 방화벽도 자체 인터페이스 설정에서 동등한 제어를 제공하므로, 메뉴 경로가 달라도 논리는 통합니다.