Rozbíjí hardwarové NAT zrychlení vaše pravidla směrování VPN?

Zapnutí hardwarového NAT zrychlení může VPN nastavení zrychlit a také může způsobit, že se pravidla směrování přestanou na některé pakety uplatňovat zcela bez chyby. Který z těchto případů nastane, závisí na tom, co rychlá cesta přeskakuje, a to se liší podle firmwaru, verze jádra a druhu použitého zrychlení. Nabídka nastavení vám jen zřídka řekne, které jste právě zapnuli.

Dvě tvrzení si zaslouží oddělit, než obviníte akcelerátor: že se pravidlo přestalo uplatňovat a že se čítač přestal aktualizovat. To není stejné pozorování.

Tři různá zrychlení se míchají dohromady

Ofload předávání, kryptografické zrychlení a ofload datového kanálu tunelu jsou samostatné mechanismy, které často sdílejí jediný přepínač. Ofload předávání umožňuje zavedeným tokům přeskočit část běžného zásobníku, kryptografické zrychlení zlevňuje šifrování a ofload tunelu přesouvá zapouzdření do hardwaru. Router, který zrychluje běžný směrovaný provoz, může nechat provoz tunelu zcela na pomalé cestě, což je výsledek výkonu, nikoli změna politiky. Existuje i opak: provoz tunelu je ofloadován, zatímco okolní politika se stále vyhodnocuje.

Linuxové flowtables jsou dokumentovaný případ, který stojí za přečtení nejvíc, protože zavedené toky lze předat rychlé cestě. Jejich účtování a práce se stavem se pak liší od klasického předávání, a proto začnou čítače vypadat podivně.

Čítač, který se přestal hýbat, dokazuje málo

Čítače pravidel počítají pakety, které projdou pravidlem, a ofloadovaný tok jím po prvním paketu už nikdy nemusí projít. Vznikne čítač, který zamrzne, zatímco provoz pokračuje, a pokud číslu věříte, vypadá přesně jako obejití. Sledování čítače je stále užitečné jako náznak, že tok opustil počítanou cestu. Zbytek diagnostiky musí vycházet z toho, kam pakety skutečně jdou.

Opačný závěr selhává stejně špatně. Rychlé stahování neukazuje, že se vaše výjimky a ošetření selhání stále uplatňují, protože procvičuje jeden tok, a ne politiku.

Tři podmínky rozhodují, zda ofload rozbije politiku

První podmínka je, zda rychlá cesta konzultuje hák, na kterém vaše politika závisí, protože politika vyjádřená značkami a trasami přežívá častěji než politika postavená na filtrování každého paketu. Druhá je, zda firmware takovou kombinaci vůbec dovoluje, protože některé sestavy ofload automaticky vypnou, když je aktivní tunel nebo funkce firewallu. Třetí je, zda je provoz způsobilý, protože zrychlení se obvykle váže na zavedené toky a může vylučovat fragmentované nebo neobvyklé pakety. Tam, kde všechny tři podmínky zrychlení přejí, politika stále platí, a tam, kde první selže, ji žádné ladění neobnoví.

Čtěte dokumentaci výrobce pro kombinaci, kterou provozujete, ne pro model routeru obecně. Verze firmwaru tyto odpovědi tiše mění.

Testujte politiku, ne propustnost

Změřte, co má politika zaručit, dřív než změříte, jak rychle běží. Níže uvedené příkazy ukazují, zda je flowtable nainstalovaná, co vidí sledování spojení a z jaké adresy klient vychází. Porovnejte nové spojení po změně, protože zavedené spojení si může ponechat starou cestu.

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

Záznam ve flowtable pokrývající provoz tunelu vám říká, že rychlá cesta je ve hře, a tabulka spojení ukazuje, zda je tok sledován tak, jak očekáváte. Kontrola adresy potvrzuje výstup, když se politika týká přístupu do internetu, zatímco ping potvrzuje soukromé cílové místo, které má zůstat dostupné. Spusťte stejnou sadu s vypnutým a potom zapnutým zrychlením a porovnejte výsledky, ne časy.

Zapište předchozí nastavení, aby experiment zůstal vratný. Obecný pokyn vypnout ofload všude se počítá jako obchvat, ne jako zjištění.