Die bewering dat 'n VPN-pakkie presies twee kontrolesomme dra, klink netjies en is dikwels genoeg verkeerd om te ontleed. Die aantal hang af van watter IP-weergawes voorkom, watter vervoerprotokol gedra word en watter beskermingsformaat die tonnel gebruik. 'n Opskrif-kontrolesom, 'n boonste-laag-kontrolesom en 'n kriptografiese integriteitsetiket is drie meganismes met drie bestekke. Om hulle te tel begin deur te merk wat elkeen dek.

Kyk watter IP-weergawes werklik op die draad is

IPv4-opskrifte dra 'n 16-bis opskrif-kontrolesom, en IPv6-opskrifte dra niks van die aard nie. Daardie enkele feit verander die aantal vir elke tonnel, want om IPv4 binne IPv6 te verpak en om IPv6 binne IPv4 te verpak lewer verskillende dokumente. 'n Tonnel kan beide families gelyk dra, en dan kan een rigting 'n veld bevat wat die ander een nie het nie. Stel die weergawes vas voordat jy enigiets tel.

Skryf die uitleg as 'n opskriflys eerder as 'n prent. Die volgorde maak saak wanneer jy 'n opname lees, en die aanwesigheid of afwesigheid van die kontrolesomveld is die eerste ding om te merk.

outer IPv6 | ESP | inner IPv6 | UDP | application data
outer IPv4 | ESP | inner IPv4 | TCP | application data

Die eerste reël het nêrens in sy IP-opskrifte 'n IP-opskrif-kontrolesom nie, terwyl die tweede twee het wanneer beide opskrifte IPv4 is. Dieselfde tonneltegnologie, 'n ander aantal, en nie een van die reëls is 'n volledige draadformaat nie.

Kyk wat elke kontrolesom dek

Dekking is die deel wat mense oorslaan, en dit is wat 'n aantal betekenisvol maak. Die IPv4-opskrif-kontrolesom beskerm die opskrif en niks anders nie, so dit sê niks oor die loonvrag daar agter nie. 'n UDP-kontrolesom oor IPv6 dek 'n pseudo-opskrif plus die UDP-opskrif en -loonvrag, wat beteken dit reik tot in die gedra pakkie wanneer die datagram getonnel is. TCP het sy eie kontrolesom met 'n soortgelyke pseudo-opskrif-afhanklikheid. Dit is drie verskillende bestekke al word al drie kontrolesomme genoem.

RFC 791 definieer die IPv4-opskrifkontrole en die herberekening daarvan by elke hop, en RFC 8200 definieer die boonste-laag-behandeling oor IPv6 insluitend die pseudo-opskrif. Nie een dokument sê dat 'n VPN-pakkie 'n vaste aantal kontrolesomme het nie, want nie een beskryf 'n tonnel nie.

tshark -r capture.pcap -Y "ip.proto == 50" -V | grep -i checksum

Kyk afsonderlik na die integriteitsbeskerming

ESP-integriteit is kriptografiese beskerming met sy eie dekking en 'n algoritme-afhanklike voorstelling. Dit is nie 'n IP- of UDP-kontrolesom onder 'n ander naam nie, en sy lengte wissel met die gekose konstruksie. 'n Integriteitskontrole dek 'n bepaalde deel van die pakkie, wat afhangend van die modus die ESP-opskrif en 'n deel van die loonvrag kan insluit. Om dit as 'n kontrolesomveld van bekende breedte te tel, is waar die meeste van hierdie verduidelikings ineenstort.

Lees die gekose konstruksie voordat jy grepe tel, en beskryf die resultaat as integriteitsbeskerming eerder as as 'n kontrolesom met 'n ander etiket. Die dekodeerder sal die veld vir jou benoem as jy dit vra.

tshark -r capture.pcap -Y esp -V | grep -iE "integrity|icv"

Kyk na die waarnemingspunt voordat jy tel

Opname op 'n binne-koppelvlak en opname op die draad kan heeltemal verskillende lae wys. Op die binne-koppelvlak is die tonnel reeds gestroop, so jy sien die gedra pakkie en geen van die buitenste opskrifte nie. Op die draad sien jy die buitenste opskrifte en 'n geënkripteerde loonvrag wat jy nie kan lees nie. Nie een siening is verkeerd nie, en hulle is nie sienings van dieselfde objek nie. Noem waar die opname geneem is voordat jy enige aantal aanhaal.

sudo tcpdump -ni eth0 -vv -c 5 esp
sudo tcpdump -ni tun0 -vv -c 5

Die eerste opdrag wys die buitenste pakkie met sy integriteitsleep, en die tweede wys die gedra pakkie met sy eie vervoerkontrolesom. Om syfers van beide opnames bymekaar te tel, tel niks dubbel nie, maar dit verduidelik dieselfde pakkie twee keer.

Kyk hoe die aantal teen 'n werklike opname pas

Dekodeer een pakkie volledig en merk elke veld wat die dekodeerder as 'n kontrolesom of 'n integriteitswaarde benoem. Vergelyk dan elke merk met die uitleg wat jy geskryf het, en skrap enigeen wat aan 'n laag behoort wat jy nie werklik tel nie. 'n Aantal wat daardie oefening oorleef, is verdedigbaar, en 'n aantal wat uit die geheue aangehaal word, is nie.

Herhaal vir die antwoordrigting, want 'n tonnel wat beide families dra, kan per rigting en per vloei verskil. Noem dan die aantal saam met sy bestek, byvoorbeeld drie kontrolesomme vir hierdie binne-pakkie by hierdie waarnemingspunt, eerder as as 'n eienskap van VPN-pakkies in die algemeen.

tshark -r capture.pcap -T fields -e ip.checksum -e udp.checksum -e tcp.checksum

Verwante artikels