Egy G.729-csomag megszámlálása egy IPsec-alagúton

Az IPsec fölötti hangot kodek-bitrátként szokás megadni, és ez a szám minden határon hibás, kivéve magának a kodeknek a határát. A hang 8 kbit/s, az őt szállító csomag nagyobb, az ESP-burok még nagyobb, és az Ethernet-keret olyan keretezést ad hozzá, amelyet az alagúton készített felvétel soha nem mutat. Egy csomag megszámlálása megadott formátumból az egyetlen módja annak, hogy megtudjuk, mit kell a fizikai kapcsolatnak ténylegesen szállítania. Az alábbi végigvezetés ezt csak egy irányra teszi meg, és itt minden szám aritmetika, nem mérés.

Csomagolási döntéssel kezdj, ne kodekszémmal

A kodektáblázat a hasznos teher sebességét adja és semmi mást: a G.729 8 kbit/s-ot ad, ami 30 bájt hang 30 msenként. Semmit nem mond a fejlécekről, a védelemről vagy a keretezésről, és ezek a három döntik el az eredményt. Az intervallum olyan szakpolitikai döntés, amelyben mindkét félnek meg kell egyeznie, ezért először azt válaszd és mondd ki, mert minden későbbi szám ettől az egy döntéstől függ.

Ez a példa 30 ms-ot használ, így a csomagsebesség 33.3 másodpercenként. 12 bájtos RTP-fejlécet, 8 bájtos UDP-fejlécet és opciók nélküli 20 bájtos belső IPv4-fejlécet feltételez, valamint azt, hogy nincs SRTP, fejléc-tömörítés vagy forgalomáramlás-bizalmassági kitöltés; bármilyen változás a költségvetést is elmozdítja, ezért a feltevések a válasz mellé tartoznak.

Add hozzá a belső fejléceket, majd az ESP-burkot

Az alkalmazás hasznos terhet plusz RTP-t plusz UDP-t plusz IP-t küld, ami ennél a csomagolásnál 70 bájt. Ez a belső folyam 18.7 kbit/s-ra jön ki, már több mint kétszerese a kodek sebességének, mert a csomag nagyobb részét fejlécek, nem hang teszik ki. Egyik bájt sem hang; ezek a címzés és a sorrendezés ára. Az alagút fölött készített felvétel pontosan ezt a számot mutatja, és ezt idézik az emberek, amikor azt mondják, hogy a hívás kicsi.

Ez az a szám is, amely soha nem ér el a vezetékig. Az ESP-alagút mód egy 8 bájtos SPI-t és sorszámot, egy 8 bájtos kifejezett IV-t az AES-GCM-hez, egy 2 bájtos záró részt és egy 16 bájtos hitelesítési címkét ad hozzá. A 70 bájtos teher a záró résszel 72-re jön ki, ami már teljesíti a négybájtos igazítást, így itt nincs szükség további kitöltésre.RFC 4106 rögzíti a GCM IV és a címke méretét, és mindkettő az aritmetikába tartozik, nem lábjegyzetbe:

30  payload, G.729 at 30 ms
12  RTP
 8  UDP
20  inner IPv4
--
70  inner IP packet
 8  ESP SPI and sequence
 8  explicit IV
 2  pad length and next header
16  authentication tag
--
104 ESP packet

Add hozzá a külső fejléceket, amelyeket a NAT-átjárás megkövetel

Az ESP-burkon kívül egy 20 bájtos külső IPv4-fejléc és egy 8 bájtos UDP-fejléc áll a NAT-átjáráshoz, így a csomag 132 bájt lesz. Az UDP-becsomagolás azért van, mert a csomagnak túl kell élnie a felek közötti fordító eszközt, és ez megváltoztatja a külső formát anélkül, hogy hozzányúlna a védett teherhez. 33.3 csomag/másodperc mellett a 132 bájt körülbelül 35.2 kbit/s, azaz nagyjából négyszerese a kodek névleges sebességének.

Sem a címke, sem az IV nem hagyható ki a becslésből, hogy kisebb legyen, mert mindkettő része annak, amit a kapcsolat ténylegesen szállít. Az a becslés, amely kihagyja őket, olyan csomagot ír le, amelyet a vevő elutasítana. Ugyanez vonatkozik a záró részre, amely a teher határát és a védett területen belüli következő fejlécet jelöli.

Nevezd meg a határt, mielőtt a számot idézed

A külső IP-szám még mindig kizárja az Ethernet-keretezést. A címkézett vagy címkézetlen hozzáférési kapcsolat egy 14 bájtos MAC-fejlécet és egy 4 bájtos keretellenőrző sorozatot ad hozzá, így a keret 150 bájt lesz, ami az a méret, amit a kapcsolóport számol. Ugyanazon csomagsebesség mellett ez 40 kbit/s, ötszöröse a kodek sebességének, és a különbség nem pazarlás, hanem a szállítás költsége.

A 40 kbit/s-os szám még mindig kizárja a preambulumot, a keretek közötti rést, a VLAN-címkéket, a szolgáltatói becsomagolást, az RTCP-t, a jelzést és a másik irányba haladó hangot. Ez irányonkénti becslés, nem kapcsolatfoglalás, és foglalásként idézni túlbecsüli azt, amit a kapcsolatnak az egyik helyen fenn kell tartania, miközben alábecsüli azt egy másikon. A gazdagépen készült felvétel is elmulaszthatja a kapcsolat által hozzáadott keretezést, ezért a határt a szám mellett kell megnevezni, és ezért hasznosabb egy határtáblázat, mint egyetlen fő szám. Külön foglalj arra az irányra, amelyet nem számoltál meg.

Ellenőrizd az aritmetikát az interfész ellen

Mielőtt megbízol a becslésben, hasonlítsd össze azzal, amit az interfész ismert számú csomagra jelent. A fizikai interfészen vegyél fel, ne az alagúteszközön, hogy a keretezés, amelyet el akarsz számolni, benne legyen, és kis eltérésre számíts, nem tökéletes egyezésre.

sudo tcpdump -ni eth0 -c 50 'udp port 4500'
ip -s link show eth0

A felvétel megerősíti a külső csomagméretet, míg az interfész-számlálók a sebességet keretezéssel együtt mutatják. Ha a kettő körülbelül az Ethernet-juttalékkal tér el, az aritmetika helyes, és csak a határt nevezték meg rosszul. Az egy keretfejlécnél jóval nagyobb eltérés valami másra utal a kapcsolaton, például újraküldésekre vagy az interfészt megosztó másik folyamra. Írd a csomagolási intervallumot, a védelmi készletet és a határt a szám mellé, mert a három nélküli becslést a következő olvasó mérésként idézi.