pfSense на Virtio: TCP застанува додека не се исклучи offload-от

Клиент известува дека тунелот се поврзува, ping одговара, страницата за најава се вчитува, а потоа преносот замрзнува на истото место при секој обид. Оваа шема веќе кажува многу: достапноста работи, а постојаната пропусност не. Пред да го отворите заштитниот ѕид, утврдете дали VPN воопшто учествува во дефектот. Пуштете голем TCP низ истата порта без тунел на патеката; ако и тој замрзне, OpenVPN никогаш не бил вклучен.

Гостин pfSense со virtio мрежна карта има многу добра причина да не успее токму во таа форма.

Малите пакети поминуваат, големиот TCP заглавува

Ракувањата, DNS одговорите и ICMP ехоата се мали и обично поминуваат. Постојаните преноси го принудуваат гостинот да сегментира, и токму таму се појавува оштетената offload патека. Дефектот не мора да биде симетричен: излезниот сообраќај може да е чист додека влезниот паѓа, или обратно, па корисникот може да се најави и потоа да застане на првиот голем одговор. Бидејќи истиот клиент работи низ друга порта, вината паѓа на најновата компонента.

Затоа тестирајте ја портата без тунелот. Доволно е преземање од LAN во WAN што ќе трае неколку секунди, и тоа мора да се направи пред каква било промена на поставките за да има значење подоцнежната споредба.

Што всушност ветува offload-от

virtio е паравертуелен: домаќинот и гостинот ја делат работата, домаќинот објавува можности за контролна сума и сегментирање и очекува гостинот да го заврши започнатото. Ако стекот на гостинот не го прави тоа, рамките излегуваат со нецелосни контролни суми или домаќинот ги отфрла. Емулираната E1000 нуди поедноставен и побавен модел во кој проблемот исчезнува без ниту една промена во pfSense. Преговорот за можности се одвива по уред, што објаснува зошто еден гостин работи со месеци, а неговиот преизграден близнак не успева уште првиот ден.

Договорениот сет зависи од верзијата на хипервизорот и избраниот модел на мрежна карта, а не само од конфигурацијата што сте ја увезле.

Едно поле за избор ја задржува virtio

Во интерфејсот на pfSense, Систем па Напредно па Мрежа содржи поле за избор со име Оневозможи хардверски offload на контролната сума. Кога е означено, гостинот ги пресметува контролните суми во софтвер, што одговара на она што FreeBSD стекот зад pfSense го очекува од паравертуелен уред. Две поврзани опции на истата страница покриваат хардверски offload на TCP сегментирањето и хардверски offload на големиот прием. Посегнете по нив кога ракувањата успеваат, а големите преноси не.

Оставете ја мрежната карта како virtio додека ја правите промената. Преминот кон E1000 троши процесор на секој пакет за целиот животен век на VM и ја сокрива конфигурациската проблема од секој што ќе го наследи домаќинот, што е полоша размена од малку побавна, но предвидлива податочна патека.

Измерете ја цената што штотуку ја прифативте

Софтверското пресметување контролни суми ја преместува работата во гостинот, затоа потоа измерете ја пропусноста наместо да претпоставите дека не чини ништо. На мала VM казната е реална, но таа е видлива и стабилна, за разлика од тивок губиток. Споредете ги бројачите на грешки на интерфејсот и дневникот на јадрото на гостинот пред и по. Хипервизорот што го филтрира мостот е одделен дефект со други докази и ниту едно offload знаменце нема да го излечи.

Менувајте една работа по тест и запишете ја патеката во менито, полето што сте го означиле и бројот што сте го измериле. Секој што ќе се соочи со следниот преизграден гостин ќе ги сака сите три.

Другите заштитни ѕидови засновани на BSD нудат еквивалентна контрола во нивните сопствени поставки на интерфејсот, па размислувањето важи и кога патеката во менито не.