Włączenie sprzętowej akceleracji NAT może przyspieszyć konfigurację VPN, a także sprawić, że polityka routingu przestanie obowiązywać dla niektórych pakietów bez żadnego błędu. To, który z tych skutków wystąpi, zależy od tego, co pomija szybka ścieżka, a to różni się między firmware, wersją jądra i rodzajem używanej akceleracji. Menu ustawień rzadko mówi, którą właśnie włączyłeś.

Dwa twierdzenia zasługują na rozdzielenie, zanim obwini się akcelerator: że reguła przestała być egzekwowana oraz że licznik przestał się aktualizować. To nie jest ta sama obserwacja.

Trzy różne akceleracje są mieszane w jedną

Odciążenie przekazywania, akceleracja kryptograficzna i odciążenie kanału danych tunelu to odrębne mechanizmy, które często dzielą jeden przełącznik. Odciążenie przekazywania pozwala ustalonym przepływom pominąć część normalnego stosu, akceleracja kryptograficzna czyni pracę szyfrowania tańszą, a odciążenie tunelu przenosi enkapsulację do sprzętu. Router przyspieszający zwykły ruch routowany może pozostawić ruch tunelowy całkowicie na wolnej ścieżce, co jest wynikiem wydajnościowym, a nie zmianą polityki. Istnieje też sytuacja odwrotna, w której ruch tunelowy jest odciążany, podczas gdy otaczająca go polityka nadal jest oceniana.

Linux flowtables to udokumentowany przypadek, który najbardziej warto przeczytać, ponieważ ustalone przepływy można przekazać do szybkiej ścieżki. Ich rozliczanie i obsługa stanu różnią się wtedy od klasycznego przekazywania, i dlatego liczniki zaczynają wyglądać dziwnie.

Licznik, który przestał się poruszać, dowodzi niewiele

Liczniki reguł zliczają pakiety przechodzące przez regułę, a odciążony przepływ może już nigdy przez nią nie przejść po pierwszym pakiecie. Daje to licznik, który zastyga, podczas gdy ruch trwa, i wygląda dokładnie jak obejście, jeśli zaufa się liczbie. Obserwowanie licznika nadal jest przydatne jako wskazówka, że przepływ opuścił liczoną ścieżkę. Reszta diagnozy musi pochodzić z tego, dokąd pakiety faktycznie trafiają.

Odwrotne wnioskowanie zawodzi równie mocno. Szybkie pobieranie nie dowodzi, że reguły wyjątków i obsługa błędów nadal obowiązują, bo ćwiczy jeden przepływ, a nie politykę.

Trzy warunki decydują, czy odciążenie psuje politykę

Pierwszym warunkiem jest czy szybka ścieżka konsultuje hak, od którego zależy twoja polityka, ponieważ polityka wyrażona znacznikami i trasami przetrwa częściej niż zbudowana na filtrowaniu każdego pakietu. Drugi to, czy firmware w ogóle pozwala na takie połączenie, bo niektóre kompilacje automatycznie wyłączają odciążenie, gdy aktywny jest tunel lub funkcja zapory. Trzeci to, czy ruch się kwalifikuje, ponieważ akceleracja zwykle jest powiązana z ustalonymi przepływami i może wykluczać pakiety pofragmentowane lub nietypowe. Tam, gdzie wszystkie trzy sprzyjają akceleracji, polityka nadal obowiązuje, a tam, gdzie zawodzi pierwszy, żadna ilość strojenia jej nie przywróci.

Czytaj dokumentację dostawcy dla zestawu, który uruchamiasz, a nie dla modelu routera ogólnie. Wersje firmware zmieniają te odpowiedzi po cichu.

Testuj politykę, nie przepustowość

Zmierz, co polityka ma gwarantować, zanim zmierzysz, jak szybko działa. Poniższe polecenia pokazują, czy flowtable jest zainstalowany, co widzi śledzenie połączeń i z którego adresu klient wychodzi. Porównaj nowe połączenie po zmianie, ponieważ ustalone może zachować starą ścieżkę.

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

Wpis flowtable obejmujący ruch tunelowy mówi, że szybka ścieżka działa, a tabela połączeń pokazuje, czy przepływ jest śledzony tak, jak oczekujesz. Kontrola adresu potwierdza wyjście, gdy polityka dotyczy wyjścia do internetu, natomiast ping potwierdza prywatny cel, który powinien pozostać osiągalny. Uruchom ten sam zestaw z wyłączoną, a potem włączoną akceleracją i porównaj wyniki, a nie czasy.

Zapisz poprzednie ustawienie, aby eksperyment pozostał odwracalny. Ogólne polecenie wyłączenia odciążenia wszędzie liczy się jako obejście, a nie jako ustalenie.

Powiązane artykuły