Чи ламає апаратне прискорення 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 підтверджує приватного адресата, який має залишатися доступним. Запустіть той самий набір із вимкненим, а потім увімкненим прискоренням і порівняйте результати, а не час.

Запишіть попереднє налаштування, щоб експеримент залишався оборотним. Загальна інструкція вимкнути розвантаження всюди вважається обхідним рішенням, а не знахідкою.