Merk av modusen før du sammenligner to VPN-pakkediagrammer

To diagrammer kan begge være riktige og se forskjellige ut, fordi de kan beskrive forskjellige pakker. En forhandlingsmelding og en applikasjonsdatapakke deler ikke samme oppsett, selv ikke innenfor én økt, og transportmodus og tunnelmodus gjør heller ikke det. Å sammenligne tegninger uten å si hvilken pakke og hvilken modus hver av dem representerer gir en diskusjon om headere som aldri skulle ha stemt overens. Fire etiketter avgjør det før sammenligningen begynner.

Skriv implementasjonen og modusen, kanalen, den ytre transporten og nyttelasten ved siden av hver tegning.

Transportmodus og tunnelmodus flytter headeren ulikt

I transportmodus sitter ESP etter IP-headeren og før protokollen som fraktes, slik at den opprinnelige IP-headeren blir utenfor beskyttelsen. I tunnelmodus adresserer en ny ytre IP-header de to IPsec-partnerne, og den beskyttede indre pakken beholder sin egen IP-header. Begge er definert i RFC 4303, og begge er riktige for sin modus. En forenklet skisse som utelater traileren og integritetsfeltene er grei for plassering og ubrukelig for å telle bytes.

Transport betyr ikke spesielt TCP eller UDP. Protokollen som fraktes på neste lag kan være hva som helst, og et diagram som setter transportmodus lik én protokoll har stille lagt til en antakelse.

Kontrollmeldinger er ikke datameldinger

L2TP holder to meldingstyper atskilt: datameldinger som bærer PPP-rammer, og kontrollmeldinger som setter opp, vedlikeholder og river tunnelen og samtalene dens. Kontrollkanalen er pålitelig, mens tapte datameldinger rett og slett ikke sendes på nytt av L2TP. En tegning som inneholder PPP kan derfor beskrive nyttelasten en datamelding bærer, ikke en header som enhver beskyttet økt må inneholde. Å kombinere L2TP med beskyttelse legger den valgte sikkerhetsordningen på toppen og gjør ikke alle meldinger identiske.

Hvis et diagram hevder at begge slags meldinger ser like ut, beskriver det en annen protokoll eller et annet omfang.

Sammenlign ekvivalente opptakspunkter

Et opptak på det ytre grensesnittet viser beskyttelses- og transportheaderne; et indre opptak, tatt etter dekapsulering, viser pakken som fraktes. Ingen av dem er feil, og å sammenligne den ene med den andre får headere til å se manglende eller dupliserte ut. UDP-innkapsling, slik den er definert for NAT-gjennomgang, legger til et ekstra ytre lag som en tegning med native ESP ikke vil ha. Begge tegningene kan være gyldige beskrivelser av forskjellige transportordninger.

Oppgi opptakspunktet sammen med diagrammet, og sammenlign ekvivalente meldinger i ekvivalente modus. En manglende header er bare bevis på en feil når begge tegningene hevder samme punkt og samme pakketype.

Hold etikettene sammen med tegningen

Et diagram uten etiketter eldes dårlig, fordi neste leser legger til sine egne antakelser. Legg til de fire etikettene, merk beskyttelsesgrensen, og noter om tegningen er for plassering eller for dimensjonering. Hvis den er for dimensjonering, bruk den fullstendige spesifikasjonen i stedet for en skisse. Kostnaden for etikettene er ett minutt; kostnaden for diskusjonen de forhindrer er en hel ettermiddag.

Når to dokumenter er uenige, sammenlign etikettene deres først. Uenighet på modus- eller kanalnivå forklarer forskjellen helt, og ingen header mangler egentlig.

Noter hvilken pakke, hvilken modus og hvilket opptakspunkt tegningen viser. Den noten er diagrammets andre halvdel.