pfSense på Virtio: TCP stannar tills offload stängs av

En klient rapporterar att tunneln ansluter, att ping svarar, att inloggningssidan laddas och att överföringen sedan fryser på samma punkt vid varje försök. Det mönstret säger redan mycket: nåbarheten fungerar och den varaktiga genomströmningen inte. Innan du öppnar brandväggen, ta reda på om VPN:en alls deltar i felet. Skicka stor TCP genom samma gateway utan tunnel i vägen; om den också fryser var OpenVPN aldrig inblandat.

En pfSense-gäst med ett virtio-nätverkskort har mycket goda skäl att misslyckas exakt i den formen.

Små paket slipper igenom, stor TCP hänger

Handskakningar, DNS-svar och ICMP-ekon är små och slipper vanligtvis igenom. Varaktiga överföringar tvingar gästen att segmentera, och det är där en skadad offload-väg visar sig. Felet behöver inte vara symmetriskt: utgående trafik kan vara ren medan ingående tappas, eller tvärtom, så en användare kan logga in och sedan fastna på det första stora svaret. Eftersom samma klient fungerar via en annan gateway får den nyaste komponenten skulden.

Testa därför gatewayen utan tunneln. En nedladdning från LAN till WAN som är stor nog att gå i några sekunder räcker, och den måste göras före varje inställningsändring så att jämförelsen efteråt betyder något.

Vad offload egentligen lovar

virtio är paravirtualiserat: värd och gäst delar arbetet, värden annonserar kontrollsumme- och segmenteringsförmågor och förväntar sig att gästen slutför det den påbörjade. Om gästens stack inte gör det lämnar ramar värden med ofullständiga kontrollsummor eller släpps av värden. En emulerad E1000 erbjuder en enklare och långsammare modell där problemet försvinner utan en enda ändring i pfSense. Förhandling av förmågor sker per enhet, vilket förklarar varför en gäst går i månader medan dess återuppbyggda tvilling misslyckas dag ett.

Den förhandlade uppsättningen beror på hypervisorversionen och den valda nätverkskortsmodellen, inte bara på konfigurationen du importerade.

En kryssruta behåller virtio

I pfSense-gränssnittet innehåller System, sedan Avancerat, sedan Nätverk en kryssruta med namnet Inaktivera maskinvaru-offload för kontrollsumma. När den är markerad beräknar gästen kontrollsummor i programvara, vilket motsvarar vad FreeBSD-stacken bakom pfSense förväntar sig av en paravirtuell enhet. Två närbesläktade alternativ på samma sida täcker maskinvaru-TCP-segmenteringsoffload och maskinvaru-offload för stor mottagning. Gripa efter dem när handskakningar lyckas men stora överföringar inte gör det.

Låt nätverkskortet vara virtio medan du gör ändringen. Att byta till E1000 bränner CPU på varje paket under hela VM:ens livstid och döljer konfigurationsproblemet för alla som ärver värden, vilket är en sämre affär än en något långsammare men förutsägbar dataväg.

Mät kostnaden du just accepterade

Programvaruberäknade kontrollsummor flyttar arbete in i gästen, så mät genomströmningen efteråt i stället för att anta att det inte kostar något. På en liten VM är straffet verkligt, men det är synligt och stabilt, till skillnad från en tyst förlust. Jämför gränssnittets felfält och gästens kernellogg före och efter. En hypervisor som filtrerar bryggan är ett separat fel med andra bevis, och ingen offload-flagga botar det.

Ändra en sak per test och skriv ned menyvägen, rutan du kryssade i och talet du mätte. Den som möter nästa återuppbyggda gäst kommer att vilja ha alla tre.

Andra BSD-baserade brandväggar erbjuder motsvarande kontroll under sina egna gränssnittsinställningar, så resonemanget följer med även när menyvägen inte gör det.