Разваля ли хардуерното NAT ускорение правилата ви за маршрутизация на VPN?

Включването на хардуерно NAT ускорение може да направи VPN настройката по-бърза, а също може да накара правилата за маршрутизация да спрат да се прилагат към някои пакети без никаква грешка. Кое от двете се случва зависи от това какво пропуска бързият път, а това се различава между фърмуера, версията на ядрото и вида ускорение, който се използва. Менюто с настройки рядко ви казва кое точно сте включили.

Две твърдения заслужават да бъдат разделени, преди ускорителят да бъде обвинен: че дадено правило е спряло да се прилага и че даден брояч е спрял да се обновява. Това не е едно и също наблюдение.

Три различни ускорения се смесват

Офлоудът на препращане, криптографското ускорение и офлоудът на канала за данни на тунела са отделни механизми, които често споделят един превключвател. Офлоудът на препращане позволява на установените потоци да пропуснат част от нормалния стек, криптографското ускорение прави шифроването по-евтино, а офлоудът на тунела премества инкапсулацията в хардуера. Рутер, който ускорява обикновен маршрутизиран трафик, може да остави трафика на тунела изцяло на бавния път, което е резултат за производителността, а не промяна в политиката. Съществува и обратното: трафикът на тунела се офлоудва, докато околната политика все още се оценява.

Flowtables в Linux са документираният случай, който най-си заслужава четене, тъй като установени потоци могат да бъдат предадени на бърз път. Отчитането и обработката на състоянието им тогава се различават от класическото препращане и затова броячите започват да изглеждат странно.

Брояч, който спира да се движи, доказва малко

Броячите на правилата отчитат пакетите, които преминават през правилото, а офлоуднат поток може никога повече да не премине през него след първия пакет. Така се получава брояч, който замръзва, докато трафикът продължава, и изглежда точно като заобикаляне, ако вярвате на числото. Наблюдението на брояча все още е полезно като подсказка, че потокът е напуснал отчитания път. Останалата част от диагностиката трябва да идва от това накъде всъщност отиват пакетите.

Обратното заключение се проваля също толкова зле. Бързото изтегляне не показва, че правилата ви за изключения и обработката на откази все още се прилагат, защото то упражнява един поток, а не политиката.

Три условия решават дали офлоудът разваля политиката

Първото условие е дали бързият път се допитва до куката, от която зависи политиката ви, тъй като политика, изразена чрез маркери и маршрути, оцелява по-често от такава, изградена върху филтриране на всеки пакет. Второто е дали фърмуерът изобщо позволява тази комбинация, защото някои сборки автоматично изключват офлоуда, когато е активен тунел или функция на защитната стена. Третото е дали трафикът е подходящ, тъй като ускорението обикновено е обвързано с установени потоци и може да изключва фрагментирани или необичайни пакети. Там, където и трите условия благоприятстват ускорението, политиката все още се прилага, а там, където първото се проваля, никакво настройване не я възстановява.

Четете документацията на доставчика за комбинацията, която използвате, а не за модела рутер като цяло. Версиите на фърмуера променят тези отговори тихо.

Тествайте политиката, а не пропусквателната способност

Измерете какво трябва да гарантира политиката, преди да измервате колко бързо работи. Командите по-долу показват дали е инсталирана 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 потвърждава частна дестинация, която трябва да остане достъпна. Пуснете същия набор с изключено и след това с включено ускорение и сравнете резултатите, а не времената.

Запишете предишната настройка, за да остане експериментът обратим. Обща инструкция да се изключи офлоудът навсякъде се брои за заобиколно решение, а не за констатация.