AH aka autentisering header fortsatte ...

Vi slapp i del to snakker om hvordan AH egentlig bare godkjenner deler av IP header og at dette er mindre enn ønskelig. Innser at visse deler av IP header vil endre seg i transitt nødvendig denne tilnærmingen. Dette er i stor grad hvorfor du egentlig ikke se mye av AH bruk, men ganske langt mer ESP trafikk. Når det er sagt la oss fortsette med vår titt på AH!

AH er ikke begrenset i bruk for å bare seg selv. Den kan også brukes i forbindelse med ESP eller det som kalles "nested", eller som vist i tunnelmodus. En av de viktigste forskjellene å realisere mellom ESP og AH er følgende. ESP autentiserer ikke noen del av IP-hodet i seg selv, med mindre det blir brukt i tunnelmodus. Hvis det er i tunnelmodus da den opprinnelige IP header har blitt innkapslet av ESP, som igjen genererer en annen IP header for ruting. Som for meg oppsummerer forskjellene mellom AH og ESP.

Hvordan ser AH ut?

Hva gjør en AH header ser ut som om? Vel det er bygget litt som ESP virkelig, og siden jeg ikke var i stand til å finne en AH pakke for å se på jeg vil liste den generelle nedbrytningen av en AH pakke som følger;

|| Mac Header || IP Header || AH Header || Data ||

er ovenfor hvordan en AH pakke ville se ut dersom sett horisontalt. MAC header er rett og slett den MAC-adressen til datamaskinen, etterfulgt av den vanlige IP spissen. Nestemann er AH spissen. AH header selv er brutt ned i ulike segmenter som vist nedenfor;

|| Neste header || Lengde || SPI || Sekvensnummer || Autentiseringsdata ||

Den neste hodefelt refererer til den innkapslede protokollen, mens lengden feltet brukes for å betegne størrelsen av autentiseringsdata nyttelast som målt i 4 byte ord. Neste vi har SPI eller sikkerhet parameter indeksverdi og etter det sekvensnummer. Endelig er den autentisering data selv.

Dette vil oppsummere vårt høye oversikt over AH og hvordan det fungerer. Vi har sett at AH har noen alvorlige mangler og i realiteten du ville være langt bedre tjent å bruke ESP som IPSec protokoll. Dersom du ønsker å lese mer om AH Jeg vil oppfordre deg til å sjekke ut den offisielle RFC på den.

GRE eller Generic Routing Encapsulation protokollen

Dette er faktisk en ganske ryddig protokoll og en hvis navn ganske mye oppsummerer hva det er designet for. Enkelt sagt er dette en generisk protokoll som kan kapsle andre protokoller og har deretter hele pakken rutes til en destinasjon. Det blir sagt det er mye mer til det da at forenklede forklaring. Så la oss komme videre med å grave litt dypere inn i GRE.

Generic ruting innkapsling er i seg selv en protokoll som vil kapsle en annen nettverkslaget protokollen og i sin tur bli sendt via en annen nettverkslaget protokollen. Vi vil bruke følgende eksempel for å prøve å gi denne forklaringen noen sammenheng. Datanettverket har en pakke som må være innkapslet og sendt til en annen datamaskin. Denne pakken vil bli deretter innkapslet hjelp av generiske ruting innkapsling protokollen. Denne nye pakken som brukes til å innkapsle GRE den opprinnelige pakken er deretter seg selv innkapslet i en annen protokoll og sendt på sin god vei til målets IP-adresse.

Du ville være helt rett i å tenke at det er en hel masse innkapsling skjer her! Det er den første opprinnelige pakken som er innkapslet bruker GRE, deretter GRE er innkapslet, og da er det på sin side sendt. Ganske mye alle datakommunikasjon bruke innkapsling av en eller annen form, er det bare til at vi ikke hører ofte om det så mye som når vi snakker om GRE. Dette er viktig for å forstå på grunn av beskaffenheten av GRE dvs: den er ment å innkapsle en annen protokoll. Det er lett å bli forvirret, men du kan huske bare at GRE svelger noe opp og igjen er innkapslet for overføring. Hva gjør en GRE pakke ligne skjønt? Vel la oss ta en titt på en under

GRE pakke

00: 03:. 11,297652 192.168.1.100 > 192.168.1.200: gre [KSv1] ID: 0600 S: 0 ppp: Konf-Req (0), Auth-Prot CHAP /MSCHAPv2, magi-Num = 110e07b6, PFC, ACFC, Ring tilbake CBCP, MRRU = 1614, End -skive Lokal, Link-Disc = 000f (ttl 125, id 18980, len 89)
0x0000 4500 0059 4a24 0000 7d2f e4da c0a8 0164 E..YJ $ ..} /......
0x0010 c0a8 01c8 3001 880b 0039 0600 0000 0000 H..X0 .... 9 ......
0x0020 ff03 c021 0100 0035 0305 c223 8105 0611 ...! ... 5 ... # ... .
0x0030 0e07 b607 0208 020d 0306 1 104 064e 1317 ............. N ..
0x0040 019b 4793 3c42 ae4b ca88 ce57 771b 8ddb ..G. < BK .. ww ...
0x0050 6600 0000 0017 0400 0f f ........

Listen bemerket GRE pakke er faktisk bære rundt PPP eller som det er referert til PPP-over-GRE. Vi kan også se fra det ovenstående pakke at det er en forholdsvis kompleks. Det er mange forskjellige beregninger involvert. Definere alle de ovennevnte beregninger er utenfor omfanget av denne artikkelen, men jeg vil oppfordre deg til å logge noen GRE pakker i et binært format, og deretter bruke Ethereal å se på de ulike delene av den.

Ved langt unna, er en av de enkleste måtene å studere IPSec å bare laste ned og installere en av freeware eller shareware-programmer. Det vil kun være gjennom bruk av IPSec programmer som du vil få en dypere forståelse av dem. Det, pluss faktisk logge hva som skjer under en IPSec økt er nyttig. Det er viktig å ikke bare logge økten selv, men også for å gjøre det helt fra starten av det. I en ideell verden for hjemmedatamaskinen lab faktisk du har to forskjellige tilkoblinger til Internett.

Å ha en slik lab oppsett lar deg gjøre mer i form av eksperimentering og absolutt bidrar til å sette opp en mer realistisk test scenario når du prøver å lære mer om VPN-tallet og deres konfigurasjon. Ikke alle har råd til et slikt oppsett selv, men kanskje hvis du jobber i et stort selskap du kan be folk i IT-avdelingen til å vise deg rundt. Dette ville være mest nyttig også, ettersom de fleste selskaper kjøre Cisco utstyr og har valgt Cisco sentriske VPN-løsninger.

wrapup

Vi har sett i løpet av de siste tre artikler som IPSec er faktisk en kompleks og noen ganger forvirrende område av studien. Om ikke annet, sementerer dette det faktum at videre studier av dette datasikkerhet domenet bør foretas. Det er mange gode IPSec løsninger der ute enten de er programvare eller maskinvare. Å vite hva som skjer under panseret på disse sikkerhetsapparater er en veldig god idé. Man skal aldri være helt blind på hva som skjer på deres nettverk, så du kan sannsynligvis finne deg selv å måtte feilsøke det! Jeg hadde en god tid å skrive denne artikkelserien som IPSec er et område jeg ignorerer ofte meg selv. Går tilbake over de ulike RFC for disse protokollene var en god repetisjon for meg, og jeg vil oppfordre deg til å lese den definitive kilde til informasjon for ESP, AH, IKE, og GRE. Det er deres respektive RFC. Jeg håper du likte denne serien på IPSec, og som alltid velkommen feedback.Till neste gang!