Bryter hårdvaruacceleration av NAT dina VPN-routningsregler?

Att slå på hårdvaruacceleration för NAT kan göra en VPN-uppsättning snabbare, och det kan också göra att en routningspolicy slutar gälla för vissa paket helt utan felmeddelande. Vilket av det som händer beror på vad snabbvägen hoppar över, och det skiljer sig mellan firmware, kärnversion och vilken typ av acceleration som används. Inställningsmenyn berättar sällan vilken du just slog på.

Två påståenden förtjänar att skiljas åt innan acceleratorn får skulden: att en regel slutade tillämpas och att en räknare slutade uppdateras. Det är inte samma observation.

Tre olika accelerationer blandas ihop

Vidarebefordringsavlastning, kryptografisk acceleration och avlastning av tunnelns datakanal är separata mekanismer som ofta delar en enda switch. Vidarebefordringsavlastning låter etablerade flöden hoppa över en del av den normala stacken, kryptografisk acceleration gör chifferarbetet billigare, och tunnelavlastning flyttar inkapslingen till hårdvara. En router som accelererar vanlig routad trafik kan lämna tunneltrafiken helt på den långsamma vägen, vilket är ett prestandaresultat och inte en policyändring. Det omvända finns också, där tunneltrafik avlastas medan policyn runt omkring fortfarande utvärderas.

Linux flowtables är det dokumenterade fall som är mest värt att läsa, eftersom etablerade flöden kan lämnas över till en snabbväg. Deras redovisning och tillståndshantering skiljer sig då från klassisk vidarebefordran, och det är därför räknarna börjar se märkliga ut.

En räknare som slutar röra sig bevisar lite

Regelräknare räknar paketen som passerar regeln, och ett avlastat flöde kanske aldrig passerar den igen efter det första paketet. Det ger en räknare som fryser medan trafiken fortsätter, och den ser exakt ut som en kringgående om du litar på siffran. Att följa räknaren är fortfarande användbart som en antydan om att flödet lämnade den räknade vägen. Resten av diagnosen måste komma från var paketen faktiskt tar vägen.

Den motsatta slutsatsen misslyckas lika illa. En snabb nedladdning visar inte att dina undantagsregler och felhantering fortfarande gäller, eftersom den övar ett flöde och inte policyn.

Tre villkor avgör om avlastning bryter policyn

Det första villkoret är om snabbvägen rådfrågar kroken som din policy bygger på, eftersom en policy uttryckt som markeringar och rutter överlever oftare än en som byggts på filtrering per paket. Det andra är om firmware tillåter kombinationen över huvud taget, eftersom vissa byggen stänger av avlastning automatiskt när en tunnel eller en brandväggsfunktion är aktiv. Det tredje är om trafiken är kvalificerad, eftersom acceleration vanligtvis är knuten till etablerade flöden och kan utesluta fragmenterade eller ovanliga paket. Där alla tre gynnar acceleration gäller policyn fortfarande, och där det första misslyckas återställer ingen mängd justering den.

Läs leverantörens dokumentation för den kombination du kör, inte för ruttermodellen i allmänhet. Firmwareversioner ändrar dessa svar tyst.

Testa policyn, inte genomströmningen

Mät vad policyn ska garantera innan du mäter hur snabbt det går. Kommandona nedan visar om en flowtable är installerad, vad anslutningsspårningen ser och från vilken adress klienten går ut. Jämför en ny anslutning efter ändringen, eftersom en etablerad kan behålla sin gamla väg.

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

En flowtable-post som täcker tunneltrafiken säger att snabbvägen är igång, och anslutningstabellen visar om flödet spåras som du förväntar dig. Adresskontrollen bekräftar utgången när policyn gäller internetutgång, medan ping bekräftar en privat destination som ska förbli nåbar. Kör samma uppsättning med acceleration av och sedan på, och jämför resultaten, inte tiderna.

Anteckna den tidigare inställningen så att experimentet förblir reversibelt. En allmän instruktion att stänga av avlastning överallt räknas som en tillfällig lösning, inte som en upptäckt.