Indre og ytre pakker i en VPN-fangst: hvorfor størrelsene avviker

Du fanger pakker på 1400 byte på tunellgrensesnittet, fanger på nytt på det fysiske grensesnittet, og tallene nekter å stemme. Adressene avviker, størrelsene avviker, og den andre filen ser ut som en helt annen samtale. Ingenting er ødelagt. To forskjellige pakker ligger på to forskjellige lag, og avstanden mellom dem er det tunellen gjør med trafikken din. Les begge visningene før du gir MTU-en skylden.

To utsiktspunkter, og pakken hver av dem viser

Et opptak gjort på tunellgrensesnittet viser den indre pakken: nyttelasten til applikasjonen med sin opprinnelige kilde og destinasjon, før noen beskyttelse er brukt. Et opptak på det fysiske grensesnittet viser den ytre pakken: en IP-header, en transportheader, innkapslingen og deretter den krypterte indre pakken som nyttelast. Samme samtale, forskjellige objekter. Når du navngir hvilken av dem filen inneholder, er ikke avviket lenger noe mysterium.

Størrelsesforskjellen er overhead, og adresseforskjellen er design. Snu det rundt, og forvirringen blir forutsigbar: folk sammenligner en indre pakke på 1400 byte med en ytre pakke på 1450 byte, bestemmer at noe er galt, og begynner å endre MTU-innstillinger som aldri var skylden. Merk filen med grensesnittet og laget, for den merkingen er det første en leser trenger og det første folk utelater.

Bestem laget før du starter opptaket

Bestem hvilket lag som svarer på spørsmålet ditt, før den første pakken skrives. Et MTU-spørsmål trenger vanligvis den ytre visningen, for det er der headere hoper seg opp og der banens grense dukker opp. Et applikasjonsspørsmål trenger vanligvis den indre visningen, for det er der nyttelasten du bryr deg om fortsatt finnes. Å ta opp begge uten en plan gir to filer og ingen konklusjon.

Bruk en ufarlig, autorisert test og filtrer på kilden, destinasjonen og tidspunktet du bryr deg om. Les opptaksverktøyets grensesnitt- og filtervalg før du samler inn, siden metadata vanligvis er nok og langt lettere å dele enn nyttelast. Behandle det indre opptaket som sensitivt som standard, for det inneholder ukrypterte applikasjonsdata som først blir beskyttet lenger framme på banen.

Hva størrelsesforskjellen faktisk inneholder

Den ytre pakken bærer ekstra headere og beskyttelsesmateriale, og hvor mye den bærer avhenger av protokollen og valgene dens. Fragmentering, aggregering eller omorganisering langs banen kan bryte det tilsynelatende en-til-en-forholdet mellom en indre pakke og de ytre pakkene som bærer den, så en størrelse-for-størrelse-sammenligning er ikke alltid tilgjengelig. Ved en mistenkt MTU-feil, se etter størrelsestilbakemelding og punktet der trafikken stopper, og sammenlign det med det applikasjonen rapporterer. Et retransmisjonsmønster uten svar er et annet signal enn en ICMP-feil som bærer en nestehopp-størrelse.

En enkelt pakke som forlater verten beviser ingenting om hvorvidt den andre enden mottok den. Hvis opptaket ditt slutter ved ditt eget grensesnitt, har du vist at kjernen sendte ut noe, som er det svakeste beviset som finnes om banen. Kombiner opptaket med et repeterbart symptom: samme destinasjon, samme operasjon, samme størrelse, kjørt to ganger med én variabel endret.

Å lese offload inn i tallene

Segmentering på vertssiden og annen offload legger til en andre forvrengning, og det er den som får lokale opptak til å være uenige med ledningen. Et lokalt opptak kan vise buffere som adapteren senere deler opp, så rammene på lenken er mindre og flere enn filen antyder. Det er derfor en stor buffer i opptaksfilen ikke beviser at en overstor ramme krysset hver lenke. Hvis størrelsene betyr noe for konklusjonen din, noter hvor opptaket ble gjort og om offload var aktivt på det grensesnittet.

Ellers måler du vertens bekvemmelighet i stedet for banens oppførsel. To filer merket med grensesnittet og offload-tilstanden avgjør de fleste av disse diskusjonene på et minutt.

Hvor opptaket slutter å være bevis

Å se krypterte ytre pakker viser at det finnes en beskyttelsesgrense under disse testforholdene, og det sier ingenting om andre applikasjoner på enheten, operatørens håndtering eller endepunktets egen tilstand. Å se klartekst inne i tunellen betyr heller ikke at tunellen er ødelagt; det betyr at du tok opp over krypteringspunktet, som er et legitimt sted å se. Et opptak er bevis om et sted, ikke en dom over et system, og saken bør beskrives slik. Behold omfangssetningen i rapporten, for det er den som hindrer en enkelt observasjon fra å bli en revisjonspåstand.

Gi hver fil navn etter grensesnitt, filter og tidsstempel, og slett den når undersøkelsen er over. tcpdump-håndboken dokumenterer grensesnitt- og filterflaggene som brukes her, inkludert de som holder et opptak lite.

Hvis du må dele bevis, del størrelser, tidsstempler og flagg i stedet for nyttelast. Spørsmålet gjaldt pakkestørrelse, og svaret trenger sjelden noens data.