pfSense sobre Virtio: o TCP atáscase ata que se desactiva a descarga

Un cliente informa de que o túnel se conecta, un ping responde, a páxina de acceso carga e despois a transferencia conxélase no mesmo punto en cada intento. Ese patrón xa di moito: a accesibilidade funciona e o rendemento sostido non. Antes de abrir a devasa, averigüe se a VPN participa sequera no fallo. Faga pasar TCP grande pola mesma pasarela sen túnel na ruta; se tamén se conxela, OpenVPN nunca estivo implicado.

Un convidado pfSense cunha tarxeta de rede virtio ten moi boas razóns para fallar exactamente dese xeito.

Os paquetes pequenos pasan, o TCP masivo colga

As apertones de mans, as respostas DNS e os ecos ICMP son pequenos e adoitan pasar. As transferencias sostidas obrigan o convidado a segmentar, e é aí onde aparece unha ruta de descarga danada. O fallo non ten por que ser simétrico: o tráfico de saída pode estar limpo mentres o de entrada se perde, ou ao revés, así que un usuario pode iniciar sesión e despois atascarse na primeira resposta grande. Como o mesmo cliente funciona por outra pasarela, a culpa recae no compoñente máis recente.

Así que probe a pasarela sen o túnel. Unha descarga de LAN a WAN o bastante grande como para durar uns segundos abonda, e debe facerse antes de calquera cambio de configuración para que a comparación posterior signifique algo.

Que promete realmente a descarga

virtio é paravirtual: anfitrión e convidado comparten o traballo, o anfitrión anuncia capacidades de suma de comprobación e segmentación e espera que o convidado remate o que comezou. Se a pila do convidado non o fai, as tramas saen con sumas de comprobación incompletas ou o anfitrión descártaas. Unha E1000 emulada ofrece un modelo máis simple e máis lento no que o problema se evapora sen un só cambio en pfSense. A negociación de capacidades ocorre por dispositivo, o que explica por que un convidado funciona durante meses e o seu xemelgo reconstruído falla o primeiro día.

O conxunto negociado depende da versión do hipervisor e do modelo de tarxeta de rede escollido, non só da configuración que importou.

Unha caixa mantén virtio

Na interface de pfSense, Sistema e despois Avanzado e despois Rede contén unha caixa chamada Desactivar a descarga de suma de comprobación por hardware. Ao marcala, o convidado calcula as sumas de comprobación por software, o que coincide co que a pila FreeBSD tras pfSense espera dun dispositivo paravirtual. Dúas opcións relacionadas na mesma páxina cobren a descarga de segmentación TCP por hardware e a descarga de recepción grande por hardware. Recorra a elas cando as apertones de mans funcionen pero as transferencias masivas non.

Deixe a tarxeta de rede como virtio mentres fai o cambio. Pasar a E1000 queima CPU en cada paquete durante toda a vida da VM e oculta o problema de configuración a quen herde o anfitrión, o que é un mal negocio comparado cunha ruta de datos algo máis lenta pero previsible.

Mida o custo que acaba de aceptar

O cálculo de sumas de comprobación por software traslada traballo ao convidado, así que mida o rendemento despois en lugar de supor que non custa nada. Nunha VM pequena a penalización é real, pero é visible e estable, a diferenza dunha perda silenciosa. Compare os contadores de erros da interface e o rexistro do núcleo do convidado antes e despois. Un hipervisor que filtra a ponte é un fallo aparte con probas distintas, e ningunha marca de descarga o curará.

Cambie unha cousa por proba e anote a ruta do menú, a caixa que marcou e o número que mediu. Quen se enfronta ao seguinte convidado reconstruído quererá as tres cousas.

Outras devasas baseadas en BSD ofrecen un control equivalente nos seus propios axustes de interface, así que o razoamento viaxa incluso cando a ruta do menú non o fai.