pfSense auf Virtio: TCP stockt, bis das Offload abgeschaltet ist

Ein Client meldet, dass der Tunnel sich verbindet, ein Ping antwortet, die Anmeldeseite lädt und die Übertragung dann bei jedem Versuch an derselben Stelle einfriert. Dieses Muster sagt bereits viel: Erreichbarkeit funktioniert, dauerhafter Durchsatz nicht. Bevor Sie die Firewall öffnen, prüfen Sie, ob das VPN überhaupt an dem Fehler beteiligt ist. Schicken Sie großes TCP über dasselbe Gateway, ohne Tunnel im Pfad; friert es dann ebenfalls ein, war OpenVPN nie beteiligt.

Ein pfSense-Gast mit einer virtio-Netzwerkkarte hat einen sehr guten Grund, genau in dieser Form zu scheitern.

Kleine Pakete kommen durch, großes TCP hängt

Handshakes, DNS-Antworten und ICMP-Echos sind klein und kommen meist durch. Dauerhafte Übertragungen zwingen den Gast zu segmentieren, und genau dort zeigt sich ein beschädigter Offload-Pfad. Der Fehler muss nicht symmetrisch sein: ausgehend kann sauber sein, während eingehend verworfen wird, oder umgekehrt, sodass sich ein Benutzer anmelden kann und dann bei der ersten großen Antwort hängen bleibt. Weil derselbe Client über ein anderes Gateway funktioniert, bekommt die neueste Komponente die Schuld.

Testen Sie das Gateway also ohne den Tunnel. Ein LAN-zu-WAN-Download, der groß genug ist, um einige Sekunden zu laufen, genügt, und er muss vor jeder Einstellungsänderung erfolgen, damit der Vergleich danach etwas bedeutet.

Was Offload tatsächlich verspricht

virtio ist paravirtual: Host und Gast teilen sich die Arbeit, der Host kündigt Prüfsummen- und Segmentierungsfähigkeiten an und erwartet, dass der Gast beendet, was er begonnen hat. Tut der Stack des Gasts das nicht, verlassen Frames den Gast mit unvollständigen Prüfsummen oder werden vom Host verworfen. Eine emulierte E1000 bietet ein einfacheres, langsameres Modell, in dem das Problem ohne eine einzige Änderung an pfSense verschwindet. Die Fähigkeitsaushandlung erfolgt pro Gerät, was erklärt, warum ein Gast monatelang läuft und sein neu aufgebauter Zwilling am ersten Tag scheitert.

Der ausgehandelte Satz hängt von der Hypervisor-Version und dem gewählten Netzwerkkartenmodell ab, nicht nur von der importierten Konfiguration.

Ein Kontrollkästchen erhält virtio

In der pfSense-Oberfläche enthält der Pfad System, dann Erweitert, dann Netzwerke ein Kontrollkästchen mit dem Namen Hardware-Prüfsummen-Offload deaktivieren. Ist es gesetzt, berechnet der Gast Prüfsummen in Software, was dem entspricht, was der FreeBSD-Stack hinter pfSense von einem paravirtualen Gerät erwartet. Zwei verwandte Optionen auf derselben Seite decken das Hardware-TCP-Segmentierungsoffload und das Hardware-Offload für großen Empfang ab. Greifen Sie danach, wenn Handshakes gelingen, große Übertragungen aber nicht.

Lassen Sie die Netzwerkkarte virtio, während Sie die Änderung vornehmen. Der Wechsel zu E1000 verbrennt CPU bei jedem Paket für die gesamte Lebensdauer der VM und verdeckt das Konfigurationsproblem vor jedem, der den Host erbt, was ein schlechterer Tausch ist als ein etwas langsamerer, aber vorhersagbarer Datenpfad.

Messen Sie die Kosten, die Sie gerade akzeptiert haben

Softwareseitige Prüfsummen verlagern Arbeit in den Gast, also messen Sie danach den Durchsatz, statt anzunehmen, dass es nichts kostet. Auf einer kleinen VM ist die Strafe real, aber sie ist sichtbar und stabil, anders als ein stiller Verlust. Vergleichen Sie Fehlerzähler der Schnittstelle und das Kernel-Log des Gasts vorher und nachher. Ein Hypervisor, der die Bridge filtert, ist ein eigener Fehler mit anderen Belegen, und kein Offload-Flag heilt ihn.

Ändern Sie pro Test eine Sache und notieren Sie den Menüpfad, das angekreuzte Kästchen und den gemessenen Wert. Wer den nächsten neu aufgebauten Gast vor sich hat, wird alle drei wollen.

Andere BSD-basierte Firewalls bieten eine gleichwertige Kontrolle in ihren eigenen Schnittstelleneinstellungen, sodass die Argumentation auch dann trägt, wenn der Menüpfad es nicht tut.