pfSense sobre Virtio: el TCP se atasca hasta que se desactiva la descarga

Un cliente informa de que el túnel se conecta, un ping responde, la página de acceso se carga y luego la transferencia se congela en el mismo punto en cada intento. Ese patrón ya dice mucho: la accesibilidad funciona y el rendimiento sostenido no. Antes de abrir el firewall, averigüe si la VPN participa siquiera en el fallo. Haga pasar TCP grande por la misma puerta de enlace sin túnel en la ruta; si también se congela, OpenVPN nunca estuvo implicado.

Un invitado pfSense con una tarjeta de red virtio tiene muy buenos motivos para fallar exactamente de esa forma.

Los paquetes pequeños pasan, el TCP masivo se cuelga

Los handshakes, las respuestas DNS y los ecos ICMP son pequeños y suelen pasar. Las transferencias sostenidas obligan al invitado a segmentar, y es ahí donde aparece una ruta de descarga dañada. El fallo no tiene por qué ser simétrico: el tráfico de salida puede estar limpio mientras el de entrada se pierde, o al revés, así que un usuario puede iniciar sesión y luego atascarse en la primera respuesta grande. Como el mismo cliente funciona por otra puerta de enlace, la culpa recae en el componente más reciente.

Así que pruebe la puerta de enlace sin el túnel. Una descarga de LAN a WAN lo bastante grande como para durar unos segundos basta, y debe hacerse antes de cualquier cambio de configuración para que la comparación posterior signifique algo.

Qué promete realmente la descarga

virtio es paravirtual: anfitrión e invitado comparten el trabajo, el anfitrión anuncia capacidades de suma de comprobación y segmentación y espera que el invitado termine lo que empezó. Si la pila del invitado no lo hace, las tramas salen con sumas de comprobación incompletas o el anfitrión las descarta. Una E1000 emulada ofrece un modelo más simple y más lento en el que el problema se evapora sin un solo cambio en pfSense. La negociación de capacidades ocurre por dispositivo, lo que explica por qué un invitado funciona durante meses y su gemelo reconstruido falla el primer día.

El conjunto negociado depende de la versión del hipervisor y del modelo de tarjeta de red elegido, no solo de la configuración que importó.

Una casilla mantiene virtio

En la interfaz de pfSense, Sistema y luego Avanzado y luego Red contiene una casilla llamada Desactivar la descarga de suma de comprobación por hardware. Al marcarla, el invitado calcula las sumas de comprobación por software, lo que coincide con lo que la pila FreeBSD tras pfSense espera de un dispositivo paravirtual. Dos opciones relacionadas en la misma página cubren la descarga de segmentación TCP por hardware y la descarga de recepción grande por hardware. Recurra a ellas cuando los handshakes funcionen pero las transferencias masivas no.

Deje la tarjeta de red como virtio mientras hace el cambio. Pasar a E1000 quema CPU en cada paquete durante toda la vida de la VM y oculta el problema de configuración a quien herede el anfitrión, lo que es un mal negocio comparado con una ruta de datos algo más lenta pero predecible.

Mida el coste que acaba de aceptar

El cálculo de sumas de comprobación por software traslada trabajo al invitado, así que mida el rendimiento después en lugar de suponer que no cuesta nada. En una VM pequeña la penalización es real, pero es visible y estable, a diferencia de una pérdida silenciosa. Compare los contadores de errores de la interfaz y el registro del núcleo del invitado antes y después. Un hipervisor que filtra el puente es un fallo aparte con pruebas distintas, y ninguna marca de descarga lo curará.

Cambie una cosa por prueba y anote la ruta del menú, la casilla que marcó y el número que midió. Quien se enfrente al siguiente invitado reconstruido querrá las tres cosas.

Otros firewalls basados en BSD ofrecen un control equivalente en sus propios ajustes de interfaz, así que el razonamiento viaja incluso cuando la ruta del menú no lo hace.