IPsec-gennemstrømning lavere end forventet? Tjek den aktive SA først
En lang transformliste er ikke den session, der beskytter din overførsel. Registrér den forhandlede SA, nyttelaststørrelsen og den leverede hastighed, før du giver krypteringen skylden.
Konfigurationen tilbyder otte transforms, nogen læser den stærkeste, og gennemstrømningstallet bliver hægtet på den. Tunnelen har sandsynligvis ikke valgt den transform, og den kørte heller ikke den arbejdsbyrde, som nogen havde forestillet sig. Det, der blev forhandlet, er én post fra den liste, med én pakkestørrelse, i én retning, på én build. Mål det, og diskussionen om algoritmer slutter som regel, før den begynder.
Symptomet: et tal under det, konfigurationen lover
En lang transformliste beskriver muligheder, og hver mulighed vurderes på papiret i stedet for på denne hardware. Det forhandlede resultat er én kombination, som begge parter accepterede, og det kan være den svageste, som en af siderne stadig tillader af hensyn til kompatibilitet. Hvad den kombination præsterer, afhænger af offload-tilstand, pakkestørrelse og køadfærd, så to enheder med en identisk politikfil kan ende meget langt fra hinanden. Listen er en menu; associationen er den ordre, der kom tilbage.
At læse listen fortæller, hvad der kunne være valgt. At læse associationen fortæller, hvad der faktisk bærer overførslen, og det er det eneste, et gennemstrømningstal beskriver. Hvert tuningtrin, der starter ved listen, er et gæt med ekstra papirarbejde.
Registrér den association, der bærer denne overførsel
På en ASA show crypto ipsec sa lister de aktive associationer med deres transforms og tællere per retning, og kommandoreferencen fra Cisco dokumenterer det output. Vælg den peer og den retning, der betyder noget, og bemærk, at en rekey erstatter associationen og nulstiller dens tællere, hvilket stille ugyldiggør en baseline, du stadig stolede på. Gem outputtet sammen med testnotaterne, så næste kørsel har noget at sammenligne med. Et associations-id, der driver mellem kørsler, gør enhver senere sammenligning meningsløs.
| What to record | Where to read it | What it rules out |
|---|---|---|
| Negotiated transform and SA identifiers | show crypto ipsec sa for that peer and direction | "the configuration picked the wrong algorithm" |
| Offload or accelerator state for that build | platform show commands and interface statistics | "the crypto engine is the ceiling" |
| Payload size and offered rate | the test tool's own settings and summary | "packets per second versus bytes per second" |
| Delivered rate and loss at the receiver | the receiving endpoint, not the sender's counters | "the sender transmitted, so it arrived" |
| Access-link load and drops | underlay interface counters along the path | "the bottleneck lives inside the tunnel" |
Fem rækker er nok til at gøre en måling reproducerbar, og hver enkelt udelukker en bestemt forklaring, når den mangler. Ingen af dem er en post fra forslagslisten, for listen kan ikke sige, hvad der beskytter dine bytes lige nu. Udfyld tabellen én gang, og den næste hændelse starter med data i stedet for en ny diskussion om algoritmer.
Rækken om access-link er den, folk springer over, og den er den, der oftest forklarer et gab, der ser kryptografisk ud. En mættet underlay eller en policer langs stien giver samme symptomform som en langsom engine.
Mål én retning med en kontrolleret belastning
Kør testen fra et LAN-endepunkt, der repræsenterer applikationen, i stedet for fra gatewayen selv, fordi en gateway-genereret probe kan følge en anden lokal politik. Mål én retning, før du tilføjer en anden stream, og registrér både den tilbudte hastighed og det, modtageren faktisk modtog. En hastighedsbegrænset UDP-kørsel adskiller den tilbudte belastning fra TCP's trængselsrespons, mens en ubegrænset UDP-afsender ikke er en neutral diagnose. Log også nyttelastlængden, fordi et større datagram ændrer både pakkehastigheden og indkapslings-overhead.
show crypto ipsec sa peer 203.0.113.9
iperf3 -c 10.20.0.10 -u -b 200M -l 1200 -t 30Kør den samme test to gange med samme nyttelastlængde og varighed, fordi én kørsel ikke kan skelne et loft fra et dårligt minut. Hvis modtageren rapporterer færre pakker, end afsenderen sendte, er tabet din konklusion, og krypteringsmotoren er kun én af flere kandidater til det.
Forklar gabet, før du justerer noget
Kontrollér videresendelsespolitik, køtab, interfacefejl og ressourcegrænser sammen med krypteringsstien, fordi et hastighedsunderskud alene aldrig identificerer en CPU. Hold også regnskabslagene eksplicitte: ydre tunnelbytes omfatter indkapsling, og retransmissioner flytter forholdet mellem indre og ydre tællere. At sammenligne ubeslægtede tællere byte for byte fremstiller en afvigelse, der aldrig var der.
Pakkestørrelsen fortjener sin egen kontrollerede sammenligning i stedet for et tal kopieret fra et gammelt eksempel. TCP MSS justerer TCP og har ingen effekt på vilkårlige UDP-datagrammer, så en fast 1350 hentet fra et ældre dokument måler absolut intet. Ændr nyttelastlængden med vilje, og se hvad modtageren rapporterer.
Ændr én variabel, og behold arbejdsbyrden
Når baselinen gentager sig inden for et smalt bånd, ændrer du én understøttet variabel og kører den oprindelige applikationsopgave igen. Det trin er det, der gør et tal til en årsag, og det er det eneste, der retfærdiggør at røre konfigurationen. Gentag den samme arbejdsbyrde i stedet for en venligere.
Fjern ikke forslag, svækk ikke autentificeringen, og slå ikke beskyttelsen fra for at gøre et syntetisk tal større. De træk ændrer sikkerhedspositionen og måler derefter resultatet af den ændring, ikke tunnelens kapacitet.