pfSense pe Virtio: TCP se blochează până când offload-ul este oprit

Un client raportează că tunelul se conectează, pingul răspunde, pagina de autentificare se încarcă, iar transferul îngheață apoi în același punct la fiecare încercare. Acest tipar spune deja multe: accesibilitatea funcționează, iar debitul susținut nu. Înainte de a deschide firewall-ul, aflați dacă VPN-ul participă măcar la defecțiune. Trimiteți TCP mare prin același gateway fără tunel pe cale; dacă îngheață și acesta, OpenVPN nu a fost niciodată implicat.

Un invitat pfSense cu o placă de rețea virtio are un motiv foarte bun să eșueze exact în acea formă.

Pachetele mici trec, TCP voluminos se blochează

Strângerile de mână, răspunsurile DNS și ecourile ICMP sunt mici și de obicei trec. Transferurile susținute obligă invitatul să segmenteze, și acolo apare o cale de offload deteriorată. Defecțiunea nu trebuie să fie simetrică: traficul de ieșire poate fi curat în timp ce cel de intrare se pierde, sau invers, astfel încât un utilizator se poate autentifica și apoi se blochează la primul răspuns mare. Deoarece același client funcționează prin alt gateway, vina cade pe componenta cea mai nouă.

Așadar testați gateway-ul fără tunel. Un download de la LAN la WAN suficient de mare pentru a rula câteva secunde este de ajuns, și trebuie făcut înainte de orice modificare de setări pentru ca comparația ulterioară să însemne ceva.

Ce promite de fapt offload-ul

virtio este paravirtual: gazda și invitatul împart munca, gazda anunță capacități de sumă de control și segmentare și așteaptă ca invitatul să termine ce a început. Dacă stiva invitatului nu face asta, cadrele pleacă cu sume de control incomplete sau sunt aruncate de gazdă. O E1000 emulată oferă un model mai simplu și mai lent în care problema dispare fără o singură modificare în pfSense. Negocierea capacităților are loc pentru fiecare dispozitiv, ceea ce explică de ce un invitat rulează luni întregi, iar geamănul său reconstruit eșuează din prima zi.

Setul negociat depinde de versiunea hipervizorului și de modelul plăcii de rețea ales, nu doar de configurația importată.

O singură casetă păstrează virtio

În interfața pfSense, Sistem apoi Avansat apoi Rețea conține o casetă numită Dezactivare offload sumă de control hardware. Dacă este bifată, invitatul calculează sumele de control în software, ceea ce corespunde cu ceea ce stiva FreeBSD din spatele pfSense așteaptă de la un dispozitiv paravirtual. Două opțiuni înrudite pe aceeași pagină acoperă offload-ul hardware de segmentare TCP și offload-ul hardware de recepție mare. Apelați la ele când strângerile de mână reușesc, dar transferurile mari nu.

Lăsați placa de rețea ca virtio în timp ce faceți modificarea. Trecerea la E1000 arde CPU la fiecare pachet pe toată durata de viață a VM-ului și ascunde problema de configurare de oricine moștenește gazda, ceea ce este un schimb mai prost decât o cale de date puțin mai lentă, dar previzibilă.

Măsurați costul pe care tocmai l-ați acceptat

Calculul software al sumelor de control mută munca în invitat, așa că măsurați debitul după aceea în loc să presupuneți că nu costă nimic. Pe un VM mic pedeapsa este reală, dar este vizibilă și stabilă, spre deosebire de o pierdere tăcută. Comparați contoarele de erori ale interfeței și jurnalul kernelului invitatului înainte și după. Un hipervizor care filtrează puntea este o defecțiune separată cu alte dovezi, și niciun steag de offload nu o vindecă.

Schimbați un singur lucru pe test și notați calea din meniu, caseta bifată și numărul măsurat. Oricine se va confrunta cu următorul invitat reconstruit va vrea toate trei.

Alte firewall-uri bazate pe BSD oferă un control echivalent în propriile setări de interfață, așa că raționamentul se transferă chiar și atunci când calea din meniu nu o face.