Да ли хардверски NAT офлоуд квари ваша VPN правила усмеравања?

Укључивање хардверског NAT убрзања може учинити VPN поставку бржом, а може и учинити да политика усмеравања престане да се примењује на неке пакете без икакве грешке. Које ће се од тога догодити зависи од тога шта брза путања прескаче, а то се разликује између фирмвера, верзије кернела и врсте убрзања које се користи. Мени са подешавањима ретко каже које сте управо укључили.

Две тврдње заслужују раздвајање пре него што се оптужи убрзивач: да је правило престало да се примењује и да је бројач престао да се ажурира. То није исто запажање.

Три различита убрзања се мешају у једно

Офлоуд прослеђивања, криптографско убрзање и офлоуд податковног канала тунела су одвојени механизми који често деле један прекидач. Офлоуд прослеђивања омогућава успостављеним токовима да прескоче део нормалног стека, криптографско убрзање чини рад шифровања јефтинијим, а офлоуд тунела премешта енкапсулацију у хардвер. Рутер који убрзава обичан усмерени саобраћај може оставити саобраћај тунела потпуно на спорој путањи, што је резултат перформанси, а не промена политике. Постоји и обрнуто, када се саобраћај тунела офлоудује док се околна политика још оцењује.

Linux flowtables су документовани случај који је највреднији читања, јер се успостављени токови могу предати брзој путањи. Њихово рачуноводство и руковање стањем тада се разликују од класичног прослеђивања, и зато бројачи почињу да изгледају чудно.

Бројач који престане да се креће доказује мало

Бројачи правила броје пакете који пролазе кроз правило, а офлоудован ток можда никада више неће проћи кроз њега после првог пакета. То ствара бројач који се замрзава док саобраћај траје, и изгледа тачно као заобилазница ако верујете броју. Посматрање бројача је и даље корисно као наговештај да је ток напустио бројану путању. Остатак дијагностике мора доћи из тога где пакети заиста иду.

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

Три услова одлучују да ли офлоуд разбија политику

Први услов је да ли брза путања консултује куку од које зависи ваша политика, јер политика изражена ознакама и рутама преживљава чешће од оне изграђене на филтрирању по пакету. Други је да ли фирмвер уопште дозвољава такву комбинацију, јер неке градње аутоматски искључују офлоуд када је тунел или функција фајервол-а активна. Трећи је да ли је саобраћај подобан, јер је убрзање обично везано за успостављене токове и може искључити фрагментисане или необичне пакете. Тамо где сва три фаворизују убрзање, политика се и даље примењује, а тамо где први услов закаже, никакво подешавање је не враћа.

Читајте документацију произвођача за комбинацију коју покрећете, а не за модел рутера уопште. Верзије фирмвера тихо мењају те одговоре.

Тестирајте политику, а не пропусност

Измерите шта политика треба да гарантује пре него што измерите колико брзо ради. Команде испод показују да ли је flowtable инсталиран, шта праћење веза види и са које адресе клијент излази. Упоредите нову везу после промене, јер успостављена може задржати стару путању.

nft list flowtables
conntrack -L | head -n 20
curl -sS --max-time 8 https://api.ipify.org; echo
ping -c 3 192.168.50.20

Унос у flowtable који покрива саобраћај тунела говори вам да је брза путања у игри, а табела веза показује да ли се ток прати како очекујете. Провера адресе потврђује излаз када се политика тиче изласка на интернет, док ping потврђује приватно одредиште које треба да остане доступно. Покрените исти скуп са искљученим, а затим укљученим убрзањем и упоредите резултате, а не времена.

Запишите претходно подешавање да експеримент остане реверзибилан. Опште упутство да се офлоуд искључи свуда рачуна се као заобилазно решење, а не као налаз.