pfSense su Virtio: il TCP si blocca finché l’offload non viene disattivato

Un cliente segnala che il tunnel si connette, un ping risponde, la pagina di accesso si carica e poi il trasferimento si blocca nello stesso punto a ogni tentativo. Questo schema dice già molto: la raggiungibilità funziona e il throughput sostenuto no. Prima di aprire il firewall, accertatevi che la VPN partecipi davvero al guasto. Fate passare TCP voluminoso attraverso lo stesso gateway senza tunnel nel percorso; se si blocca anche quello, OpenVPN non è mai stato coinvolto.

Un guest pfSense con una scheda di rete virtio ha ottimi motivi per fallire esattamente in quella forma.

I pacchetti piccoli passano, il TCP voluminoso si impunta

Gli handshake, le risposte DNS e gli echo ICMP sono piccoli e di solito passano. I trasferimenti sostenuti costringono il guest a segmentare, ed è lì che emerge un percorso di offload danneggiato. Il guasto non deve essere simmetrico: il traffico in uscita può essere pulito mentre quello in entrata si perde, o viceversa, così un utente può accedere e poi bloccarsi sulla prima risposta grande. Poiché lo stesso client funziona attraverso un altro gateway, la colpa ricade sul componente più recente.

Provate quindi il gateway senza il tunnel. Un download da LAN a WAN abbastanza grande da durare qualche secondo basta, e va fatto prima di qualsiasi modifica alle impostazioni perché il confronto successivo abbia senso.

Cosa promette davvero l’offload

virtio è paravirtuale: host e guest condividono il lavoro, l’host annuncia capacità di checksum e segmentazione e si aspetta che il guest finisca ciò che ha iniziato. Se lo stack del guest non lo fa, i frame partono con checksum incompleti o vengono scartati dall’host. Una E1000 emulata offre un modello più semplice e più lento in cui il problema svanisce senza una sola modifica a pfSense. La negoziazione delle capacità avviene per dispositivo, il che spiega perché un guest funziona per mesi mentre il suo gemello ricostruito fallisce il primo giorno.

L’insieme negoziato dipende dalla versione dell’hypervisor e dal modello di scheda di rete scelto, non solo dalla configurazione importata.

Una casella di controllo tiene virtio

Nell’interfaccia di pfSense, Sistema poi Avanzate poi Rete contiene una casella chiamata Disattiva l’offload hardware del checksum. Selezionandola, il guest calcola i checksum nel software, il che corrisponde a ciò che lo stack FreeBSD dietro pfSense si aspetta da un dispositivo paravirtuale. Due opzioni correlate nella stessa pagina coprono l’offload hardware della segmentazione TCP e l’offload hardware della ricezione grande. Ricorretevi quando gli handshake riescono ma i trasferimenti voluminosi no.

Lasciate la scheda di rete come virtio mentre fate la modifica. Passare a E1000 brucia CPU su ogni pacchetto per tutta la vita della VM e nasconde il problema di configurazione a chiunque erediti l’host, il che è uno scambio peggiore di un percorso dati un po’ più lento ma prevedibile.

Misurate il costo che avete appena accettato

Il calcolo software dei checksum sposta lavoro nel guest, quindi misurate il throughput dopo invece di supporre che non costi nulla. Su una VM piccola la penalità è reale, ma è visibile e stabile, a differenza di una perdita silenziosa. Confrontate i contatori di errore dell’interfaccia e il log del kernel del guest prima e dopo. Un hypervisor che filtra il bridge è un guasto separato con prove diverse, e nessun flag di offload lo curerà.

Cambiate una cosa per test e annotate il percorso di menu, la casella selezionata e il numero misurato. Chi affronterà il prossimo guest ricostruito vorrà tutti e tre.

Altri firewall basati su BSD offrono un controllo equivalente nelle proprie impostazioni di interfaccia, quindi il ragionamento viaggia anche quando il percorso di menu no.