Inre och yttre paket i en VPN-fångst: varför storlekarna skiljer sig

Du fångar paket på 1400 byte på tunnelgränssnittet, fångar igen på det fysiska gränssnittet, och siffrorna vägrar stämma. Adresserna skiljer sig, storlekarna skiljer sig, och den andra filen ser ut som ett annat samtal. Inget är trasigt. Två olika paket sitter på två olika lager, och gapet mellan dem är vad tunneln gör med din trafik. Läs båda vyerna innan du skyller på MTU:n.

Två utsiktspunkter, och paketet var och en visar

En fångst på tunnelgränssnittet visar det inre paketet: applikationens nyttolast med sin ursprungliga källa och destination, innan något skydd har tillämpats. En fångst på det fysiska gränssnittet visar det yttre paketet: ett IP-huvud, ett transporthuvud, inkapslingen och sedan det krypterade inre paketet som nyttolast. Samma samtal, olika objekt. När du har namngett vilket av dem filen innehåller upphör missförhållandet att vara ett mysterium.

Storleksskillnaden är overhead, adresskillnaden är design. Vänd på det och förvirringen blir förutsägbar: folk jämför ett inre paket på 1400 byte med ett yttre på 1450 byte, drar slutsatsen att något är fel och börjar ändra MTU-inställningar som aldrig var skyldiga. Märk filen med gränssnittet och lagret, för den etiketten är det första en läsare behöver och det första folk utelämnar.

Bestäm lagret innan du startar fångsten

Bestäm vilket lager som svarar på din fråga innan det första paketet skrivs. En MTU-fråga behöver oftast den yttre vyn, eftersom det är där huvuden hopar sig och där vägens gräns visar sig. En applikationsfråga behöver oftast den inre vyn, eftersom det är där nyttolasten du bryr dig om fortfarande finns. Att fånga båda utan en plan ger två filer och ingen slutsats.

Använd ett ofarligt, tillåtet test och filtrera på den källa, destination och tid du bryr dig om. Läs fångstverktygets gränssnitts- och filteralternativ innan du samlar in, eftersom metadata oftast räcker och är mycket lättare att dela än nyttolast. Behandla den inre fångsten som känslig som standard, eftersom den innehåller okrypterad applikationsdata som först skyddas längre fram på vägen.

Vad storleksskillnaden faktiskt innehåller

Det yttre paketet bär extra huvuden och skyddsmaterial, och hur mycket det bär beror på protokollet och dess alternativ. Fragmentering, aggregering eller omordning längs vägen kan bryta det skenbara ett-till-ett-förhållandet mellan ett inre paket och de yttre paket som bär det, så en storlek-för-storlek-jämförelse är inte alltid möjlig. Vid en misstänkt MTU-störning, leta efter storleksåterkoppling och punkten där trafiken stannar, och jämför det med vad applikationen rapporterar. Ett mönster av omsändningar utan svar är en annan signal än ett ICMP-fel som bär en nästa hopp-storlek.

Ett enda paket som lämnar värden bevisar ingenting om huruvida den bortre änden tog emot det. Om din fångst slutar vid ditt eget gränssnitt har du visat att kärnan skickade något, och det är det svagaste bevis som finns om vägen. Kombinera fångsten med ett repeterbart symtom: samma destination, samma operation, samma storlek, två körningar med en variabel ändrad.

Att läsa offload i siffrorna

Segmentering på värdsidan och andra typer av offload tillför en andra förvrängning, och det är den som gör att lokala fångster inte stämmer med det som går på länken. En lokal fångst kan visa buffertar som adaptern delar senare, så ramarna på länken är mindre och fler än filen antyder. Det är därför en stor buffert i fångstfilen inte bevisar att en överdimensionerad ram passerade varje länk. Om storlekarna spelar roll för din slutsats, notera var fångsten gjordes och om offload var aktivt på det gränssnittet.

Annars mäter du värdens bekvämlighet i stället för vägens beteende. Två filer märkta med gränssnitt och offload-status avgör de flesta av dessa dispyter på en minut.

Där fångsten slutar vara bevis

Att se krypterade yttre paket visar att det finns en skyddsgräns under dessa testförhållanden, och det säger ingenting om andra applikationer på enheten, om operatörens hantering eller om slutpunktens eget tillstånd. Att se klartext inne i tunneln betyder inte heller att tunneln är trasig; det betyder att du fångade ovanför krypteringspunkten, vilket är en legitim plats att titta på. En fångst är bevis om en plats, inte en dom om ett system, och ärendet bör beskriva den så. Behåll scope-meningen i rapporten, för det är den som hindrar en enskild observation från att bli ett revisionspåstående.

Namnge varje fil med dess gränssnitt, filter och tidsstämpel, och radera den när utredningen är slut. tcpdump-manualen dokumenterar de gränssnitts- och filterflaggor som används här, inklusive de som håller en fångst liten.

Om du måste dela bevis, dela storlekar, tidsstämplar och flaggor i stället för nyttolast. Frågan gällde paketstorlek, och svaret behöver sällan någons data.