pfSense sobre Virtio: el TCP s’atura fins que es desactiva l’offload

Un client informa que el túnel es connecta, un ping respon, la pàgina d’inici de sessió es carrega i després la transferència es congela al mateix punt a cada intent. Aquest patró ja diu moltes coses: l’abastabilitat funciona i el rendiment sostingut no. Abans d’obrir el tallafoc, esbrineu si la VPN participa gens en la fallada. Feu passar TCP gran per la mateixa passarel·la sense cap túnel al camí; si també es congela, OpenVPN no hi va tenir mai res a veure.

Un convidat pfSense amb una targeta de xarxa virtio té un motiu molt bo per fallar exactament d’aquesta manera.

Els paquets petits passen, el TCP massiu s’encalla

Les negociacions, les respostes DNS i els ecos ICMP són petits i normalment passen. Les transferències sostingudes obliguen el convidat a segmentar, i és aquí on surt el camí d’offload malmès. La fallada no ha de ser simètrica: el trànsit de sortida pot ser net mentre el d’entrada cau, o al revés, de manera que un usuari pot iniciar sessió i després encallar-se amb la primera resposta gran. Com que el mateix client funciona per una altra passarel·la, la culpa recau en el component més nou.

Per tant, proveu la passarel·la sense el túnel. Una baixada de LAN a WAN prou gran per durar uns quants segons és suficient, i s’ha de fer abans de qualsevol canvi de configuració perquè la comparació posterior signifiqui alguna cosa.

Què promet realment l’offload

virtio és paravirtual: amfitrió i convidat comparteixen la feina, l’amfitrió anuncia capacitats de suma de verificació i segmentació i espera que el convidat acabi el que ha començat. Si la pila del convidat no ho fa, les trames surten amb sumes de verificació incompletes o l’amfitrió les descarta. Una E1000 emulada ofereix un model més simple i més lent en què el problema s’evapora sense cap canvi a pfSense. La negociació de capacitats es fa per dispositiu, cosa que explica per què un convidat funciona durant mesos i el seu bessó reconstruït falla el primer dia.

El conjunt negociat depèn de la versió de l’hipervisor i del model de targeta de xarxa triat, no només de la configuració que heu importat.

Una casella manté virtio

A la interfície de pfSense, Sistema i després Avançat i després Xarxa conté una casella anomenada Desactiva l’offload de suma de verificació per maquinari. Marcar-la fa que el convidat calculi les sumes de verificació per programari, cosa que coincideix amb el que la pila FreeBSD darrere de pfSense espera d’un dispositiu paravirtual. Dues opcions relacionades a la mateixa pàgina cobreixen l’offload de segmentació TCP per maquinari i l’offload de recepció gran per maquinari. Recorreu-hi quan les negociacions funcionen però les transferències massives no.

Deixeu la targeta de xarxa com a virtio mentre feu el canvi. Passar a E1000 crema CPU a cada paquet durant tota la vida de la VM i amaga el problema de configuració a qui hereti l’amfitrió, cosa que és un mal intercanvi comparat amb un camí de dades una mica més lent però predictible.

Mesureu el cost que acabeu d’acceptar

El càlcul de sumes de verificació per programari trasllada feina al convidat, així que mesureu el rendiment després en lloc de suposar que no costa res. En una VM petita la penalització és real, però és visible i estable, a diferència d’una pèrdua silenciosa. Compareu els comptadors d’errors de la interfície i el registre del nucli del convidat abans i després. Un hipervisor que filtra el pont és una fallada separada amb proves diferents, i cap indicador d’offload la curarà.

Canvieu una cosa per prova i anoteu el camí del menú, la casella que heu marcat i el número que heu mesurat. Qui s’enfronti al proper convidat reconstruït voldrà les tres coses.

Altres tallafocs basats en BSD ofereixen un control equivalent a la seva pròpia configuració d’interfície, així que el raonament viatja fins i tot quan el camí del menú no ho fa.