Bryter maskinvarebasert NAT-avlasting VPN-rutingreglene dine?

Å slå på maskinvarebasert NAT-akselerasjon kan gjøre et VPN-oppsett raskere, og det kan også gjøre at en rutingpolicy slutter å gjelde for enkelte pakker helt uten feilmelding. Hvilket av disse som skjer, avhenger av hva hurtigveien hopper over, og det varierer mellom fastvare, kjerneversjon og hvilken type akselerasjon som er i bruk. Innstillingsmenyen forteller sjelden hvilken du nettopp slo på.

To påstander fortjener å skilles før akseleratoren får skylden: at en regel sluttet å bli håndhevet, og at en teller sluttet å bli oppdatert. Det er ikke samme observasjon.

Tre ulike akselerasjoner blandes sammen

Videresendingsavlasting, kryptografisk akselerasjon og avlasting av tunnelens datakanal er separate mekanismer som ofte deler en enkelt bryter. Videresendingsavlasting lar etablerte strømmer hoppe over deler av den normale stakken, kryptografisk akselerasjon gjør krypteringsarbeidet billigere, og tunnelavlasting flytter innkapslingen til maskinvare. En ruter som akselererer vanlig rutet trafikk, kan la tunneltrafikken ligge helt på den langsomme veien, og det er et ytelsesresultat, ikke en policyendring. Det motsatte finnes også, der tunneltrafikk avlastes mens policyen rundt fortsatt evalueres.

Linux flowtables er det dokumenterte tilfellet som er mest verdt å lese, siden etablerte strømmer kan overleveres til en hurtigvei. Regnskapet og tilstandsbehandlingen deres skiller seg da fra klassisk videresending, og det er derfor tellerne begynner å se merkelige ut.

En teller som slutter å bevege seg beviser lite

Regeltellere teller pakkene som passerer regelen, og en avlastet strøm passerer kanskje aldri gjennom den igjen etter den første pakken. Det gir en teller som fryser mens trafikken fortsetter, og den ser nøyaktig ut som en omgåelse hvis du stoler på tallet. Å følge med på telleren er fortsatt nyttig som et hint om at strømmen forlot den telte veien. Resten av diagnosen må komme fra hvor pakkene faktisk går.

Den motsatte slutningen feiler like ille. En rask nedlasting viser ikke at unntaksreglene og feilhåndteringen din fortsatt gjelder, fordi den øver på én strøm og ikke på policyen.

Tre betingelser avgjør om avlasting bryter policyen

Den første betingelsen er om hurtigveien konsulterer kroken policyen din er avhengig av, siden en policy uttrykt som merker og ruter oftere overlever enn en som er bygget på filtrering per pakke. Den andre er om fastvaren tillater kombinasjonen i det hele tatt, fordi noen bygg slår av avlasting automatisk når en tunnel eller en brannmurfunksjon er aktiv. Den tredje er om trafikken er kvalifisert, siden akselerasjon vanligvis er knyttet til etablerte strømmer og kan utelukke fragmenterte eller uvanlige pakker. Der alle tre favoriserer akselerasjon, gjelder policyen fortsatt, og der den første svikter, gjenoppretter ingen mengde justering den.

Les leverandørdokumentasjonen for kombinasjonen du kjører, ikke for rutermodellen generelt. Fastvareversjoner endrer disse svarene i stillhet.

Test policyen, ikke gjennomstrømningen

Mål hva policyen skal garantere før du måler hvor fort det går. Kommandoene nedenfor viser om en flowtable er installert, hva tilkoblingssporing ser, og hvilken adresse klienten går ut fra. Sammenlign en ny tilkobling etter endringen, siden en etablert kan beholde den gamle veien.

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-oppføring som dekker tunneltrafikken forteller deg at hurtigveien er i spill, og tilkoblingstabellen viser om strømmen spores slik du forventer. Adressekontrollen bekrefter utgangen når policyen gjelder internett-utgang, mens ping bekrefter en privat destinasjon som skal forbli tilgjengelig. Kjør samme sett med akselerasjon av og deretter på, og sammenlign resultatene, ikke tidene.

Noter den forrige innstillingen slik at eksperimentet forblir reversibelt. En generell instruks om å slå av avlasting overalt regnes som en omvei, ikke som et funn.