Markér tilstanden, før du sammenligner to VPN-pakkediagrammer

To diagrammer kan begge være korrekte og se forskellige ud, fordi de kan beskrive forskellige pakker. En forhandlingsmeddelelse og en applikationsdatapakke deler ikke samme layout, end ikke inden for én session, og transporttilstand og tunneltilstand gør heller ikke. At sammenligne tegninger uden at angive, hvilken pakke og hvilken tilstand hver repræsenterer, giver en diskussion om headere, der aldrig skulle have passet sammen. Fire etiketter afgør det, før sammenligningen begynder.

Skriv implementeringen og tilstanden, kanalen, den ydre transport og den medbragte nyttelast ved siden af hver tegning.

Transporttilstand og tunneltilstand flytter headeren forskelligt

I transporttilstand sidder ESP efter IP-headeren og før den medbragte protokol, så den oprindelige IP-header bliver uden for beskyttelsen. I tunneltilstand adresserer en ny ydre IP-header de to IPsec-peers, og den beskyttede indre pakke beholder sin egen IP-header. Begge er defineret i RFC 4303, og begge er korrekte for deres tilstand. En forenklet skitse, der udelader traileren og integritetsfelterne, er fin til placering og ubrugelig til at tælle bytes.

Transport betyder ikke specifikt TCP eller UDP. Den medbragte næste-lags-protokol kan være hvad som helst, og et diagram, der sidestiller transporttilstand med én protokol, har stille tilføjet en antagelse.

Kontrolmeddelelser er ikke datameddelelser

L2TP holder to meddelelsestyper adskilt: datameddelelser, der bærer PPP-rammer, og kontrolmeddelelser, der opretter, vedligeholder og nedbryder tunnelen og dens opkald. Kontrolkanalen er pålidelig, hvorimod tabte datameddelelser simpelthen ikke gensendes af L2TP. En tegning, der indeholder PPP, kan derfor beskrive den nyttelast, en datameddelelse bærer, ikke en header, som enhver beskyttet session skal indeholde. At kombinere L2TP med beskyttelse lægger den valgte sikkerhedsordning ovenpå og gør ikke alle meddelelser identiske.

Hvis et diagram påstår, at begge slags meddelelser ser ens ud, beskriver det en anden protokol eller et andet omfang.

Sammenlign ækvivalente opsamlingspunkter

En opsamling på det ydre interface viser beskyttelses- og transportheadere; en indre opsamling, taget efter dekapsulering, viser den medbragte pakke. Ingen af dem er forkert, og at sammenligne den ene med den anden får headere til at se manglende eller dublerede ud. UDP-indkapsling, som defineret til NAT-gennemgang, tilføjer endnu et ydre lag, som en tegning med native ESP ikke har. Begge tegninger kan være gyldige beskrivelser af forskellige transportordninger.

Angiv opsamlingspunktet sammen med diagrammet, og sammenlign ækvivalente meddelelser i ækvivalente tilstande. En manglende header er kun bevis på en fejl, når begge tegninger hævder samme punkt og samme pakketype.

Hold etiketterne sammen med tegningen

Et diagram uden etiketter ældes dårligt, fordi den næste læser tilføjer sine egne antagelser. Tilføj de fire etiketter, markér beskyttelsesgrænsen, og notér, om tegningen er til placering eller til dimensionering. Hvis den er til dimensionering, brug den fulde specifikation i stedet for en skitse. Prisen for etiketterne er et minut; prisen for diskussionen, de forhindrer, er en eftermiddag.

Når to dokumenter er uenige, så sammenlign deres etiketter først. Uenighed på tilstands- eller kanalniveau forklarer forskellen fuldstændigt, og ingen header mangler faktisk.

Notér, hvilken pakke, hvilken tilstand og hvilket opsamlingspunkt tegningen viser. Den note er diagrammets anden halvdel.