pfSense på Virtio: TCP stopper til offload slås av
En virtualisert pfSense svarer på ping og stopper deretter på store TCP-overføringer. Slå av virtio-banen for kontrollsum-offload og mål kostnaden i stedet for å bytte nettverkskort.
En klient melder at tunnelen kobler til, at ping svarer, at innloggingssiden lastes, og at overføringen deretter fryser på samme punkt ved hvert forsøk. Det mønsteret sier allerede mye: tilgjengelighet virker, og vedvarende gjennomstrømning gjør det ikke. Før du åpner brannmuren, finn ut om VPN-en i det hele tatt deltar i feilen. Send stor TCP gjennom samme gateway uten tunnel i banen; hvis den også fryser, var OpenVPN aldri involvert.
En pfSense-gjest med et virtio-nettverkskort har en meget god grunn til å feile nøyaktig i den formen.
Små pakker slipper gjennom, store TCP-overføringer henger
Håndtrykk, DNS-svar og ICMP-ekkoer er små og slipper vanligvis gjennom. Vedvarende overføringer tvinger gjesten til å segmentere, og det er der en skadet offload-bane dukker opp. Feilen trenger ikke være symmetrisk: utgående trafikk kan være ren mens inngående droppes, eller omvendt, slik at en bruker kan logge inn og deretter stoppe på det første store svaret. Fordi den samme klienten virker gjennom en annen gateway, får den nyeste komponenten skylden.
Test derfor gatewayen uten tunnelen. En LAN-til-WAN-nedlasting som er stor nok til å gå i noen sekunder, er tilstrekkelig, og den må gjøres før noen innstillinger endres, slik at sammenligningen etterpå betyr noe.
Hva offload egentlig lover
virtio er paravirtualisert: vert og gjest deler arbeidet, verten annonserer kontrollsum- og segmenteringsevner og forventer at gjesten fullfører det den startet. Hvis gjestens stack ikke gjør det, forlater rammer verten med ufullstendige kontrollsummer eller droppes av verten. En emulert E1000 tilbyr en enklere og langsommere modell der problemet forsvinner uten en eneste endring i pfSense. Forhandling av evner skjer per enhet, noe som forklarer hvorfor én gjest går i månedsvis mens dens gjenoppbygde tvilling feiler på dag én.
Settet som forhandles frem, avhenger av hypervisorversjonen og den valgte nettverkskortmodellen, ikke bare av konfigurasjonen du importerte.
Én avkrysningsboks beholder virtio
I pfSense-grensesnittet inneholder System, deretter Avansert, deretter Nettverk en avkrysningsboks kalt Deaktiver maskinvare-offload for kontrollsum. Når den er satt, beregner gjesten kontrollsummer i programvare, noe som samsvarer med det FreeBSD-stacken bak pfSense forventer av en paravirtual enhet. To relaterte alternativer på samme side dekker maskinvare-TCP-segmenteringsoffload og maskinvare-offload for stor mottak. Grip etter dem når håndtrykk lykkes, men store overføringer ikke gjør det.
La nettverkskortet være virtio mens du gjør endringen. Å bytte til E1000 brenner CPU på hver pakke gjennom hele VM-ens levetid og skjuler konfigurasjonsproblemet for alle som arver verten, noe som er en dårligere handel enn en litt langsommere, men forutsigbar databane.
Mål kostnaden du nettopp har akseptert
Programvarebaserte kontrollsummer flytter arbeid inn i gjesten, så mål gjennomstrømningen etterpå i stedet for å anta at det ikke koster noe. På en liten VM er straffen reell, men den er synlig og stabil, i motsetning til et stille tap. Sammenlign grensesnittets feiltellere og gjestens kjernelogg før og etter. En hypervisor som filtrerer broen, er en egen feil med andre bevis, og ingen offload-flagg kurerer den.
Endre én ting per test og skriv ned menystien, boksen du krysset av og tallet du målte. Den som møter den neste gjenoppbygde gjesten, vil ha alle tre.
Andre BSD-baserte brannmurer tilbyr tilsvarende kontroll under sine egne grensesnittinnstillinger, så resonnementet reiser selv når menystien ikke gjør det.