forståelse af IPSec tunneler (L2L)

i Min nuværende rolle beskæftiger jeg mig med L2L (LAN til LAN) tunneler ganske ofte. De er den’ billige ‘ måde at forbinde to steder i forhold til dedikerede adgangskredsløb. Det eneste krav er at have det rigtige udstyr og en’ altid tændt ‘ statisk IP på hvert sted. Jeg spøger ofte med, at det er let at konfigurere en L2L-tunnel på en ASA og kun tager 20 konfigurationslinjer i CLI. Når det er sagt som alt andet i netværksverdenen, hvis du ikke forstår, hvordan teknologien fungerer, vil du sidde fast en dag. At skrive 20 config linjer i en konsol og faktisk forstå, hvad der sker, er to helt forskellige ting. I dette indlæg vil jeg tale om IPSec basics, Hvordan tunneler dannes, og nogle fejlfindingstrin, du kan tage, når du løber ind i problemer.

terminologi
IPSec (Internet Protocol Security) – hvad vi taler om

Ike (Internet nøgleudveksling) – tænk på IKE som det værktøjssæt, der kræves for at etablere og opretholde en sikker forbindelse mellem to slutpunkter. Grundlæggende tillader IKE forbindelsen at danne og vedligeholde SAs (Sikkerhedsforeninger), som er den vigtigste del af en IPSec – tunnel

ISAKMP (Internet Security Association and Key Management Protocol) – ISAKMP er den standard, der definerer, hvordan man arbejder med SAs. Med andre ord håndterer ISAKMP, hvordan SAs oprettes, vedligeholdes, ændres og rives ned. Har du bemærket overlapningen? Ike og ISAKMP lyder forfærdeligt ens,ikke? Det er fordi de er. Faktisk bemærker Cisco endda dette i deres dokumentation.

” Internet Security Association og Key Management Protocol, også kaldet IKE, er forhandlingsprotokollen, der lader to værter blive enige om, hvordan man opbygger en IPsec security association. Hver isakmp forhandling er opdelt i to sektioner kaldet Phase1 og Fase 2.”

Peer – adresse-afhængigt af kontekst er det enten den offentlige adresse i den ene ende af tunnelen eller i den anden ende af tunnelen.

DH (Diffie-Hellman) – DH tillader to parter at dele en hemmelig nøgle over en usikker kanal. DH bruges under Ike fase 1 til at udveksle nøgler og etablere en sikker hemmelig nøgle.

ISAKMP – Politiksæt-et politiksæt, der angiver Ike-krypteringsalgoritmen, Ike-godkendelsesalgoritmen, Ike-godkendelsestypen, DH-versionen og Ike-tunnelens levetid. ISAKMP-Politiksættet bruges under Ike-fase 1-forhandlinger. For at gøre dette endnu mere forvirrende kaldes ISAKMP – politiksæt også enten ISAKMP-transformationssæt, IKE-transformationssæt eller bare almindelige gamle transformationssæt

IPSec-Transformationssæt-et transformationssæt består af indstillinger, der er relevante for oprettelsen af IPSec-tunnelen. Det faktiske transformationssæt bruges under IKE-fase 2 og består generelt kun af Ike-kryptering og autentificeringstype. Igen er den forvirrende del, at ofte nogle mennesker bare kalder disse transformationssæt.

SAs (Sikkerhedsforeninger) – dybest set er det det sæt IPSec-parametre, som begge sider af tunnelen er enige om. Jeg vil gøre en kritisk forskel her for dem af os i Cisco land. Der vil være en ISAKMP SA og en IPSec SA. Der oprettes flere tunneler, mens IPSec-tunnelen oprettes. Bare husk, at ISAKMP SA betragtes som resultatet af Ike-fase 1, og IPSec SA betragtes som resultatet af Ike-fase 2. Også, en SA er kun en envejsforbindelse. Da de fleste trafik mellem slutpunkter kræver tovejskommunikation, vil hver ASA oprette sin egen SA for at tale med den anden peer.

Nonce – et tal, der normalt bruges til en sikker nøgle, der kun bruges en gang. Hvis det bruges en anden gang, er det normalt et tegn på et bedragerisk forbindelsesforsøg.

Terminologisammendrag – VPN-terminologi er virkelig, virkelig, virkelig forvirrende. Bare prøv at huske, at ISAKMP og Ike undertiden bruges om hverandre. Derudover er transform-sæt en generel betegnelse for en gruppe af indstillinger. Jeg forsøger kun at bruge sætningen, når jeg henviser til, hvad jeg skriver efter ‘transform-set’ i CLI, som bruges til at specificere godkendelses-og krypteringstypen for IKE-fasen 2.

processen
nu hvor vi kender nogle af nøgleordene, kan vi begynde at tale om, hvordan IPSec-tunnelen dannes. Efter min mening er der 4 faser i en IPSec-tunnels levetid. Jeg lægger dem ud nedenfor, og så taler vi om dem

fase 1 – interessant trafik genererer oprettelsen af tunnelen
fase 2 – Ike fase 1
fase 3 – Ike fase 2
fase 4 – Tunnelafslutning

nogle mennesker kaster en fase mellem min fase 3 og 4 og viser den som ‘IPSec-tunnel oprettet’, som efter mit synspunkt faktisk ikke er en fase. Notering af produktet af faser 1 til 3 synes ikke at retfærdiggøre sin egen fase i mit sind. Lad os i hvert fald gå i detaljer om hver enkelt.

fase 1 – interessant trafik genererer oprettelsen af tunnelen
hvad mange mennesker ikke ved om IPSec er, at det er det, jeg kalder en ‘on demand’ – tjeneste. Det vil sige, når du opretter en tunnel dens ikke oppe og køre hele tiden. Det, vi kalder ‘interessant trafik’, udløser oprettelsen af en tunnel. Oprettelse af tunnelen tager ikke meget lang tid, men kan i de fleste tilfælde bemærkes, når du bruger ping til test. I de fleste tilfælde, når jeg prøver at pinge fra en klientmaskine over tunnelen, vil den første ICMP-anmodning mislykkes, fordi tunnelen indlæses. Efterfølgende ICMP ‘ er gennemgår korrekt. Interessant trafik er defineret på ASA med en ACL. Derefter specificeres ACL inden for tunnels crypto map med en’ match address ‘ kommando. Et eksempel ACL kan se sådan ud …

adgangsliste L2LCryptoMap udvidet tilladelse ip< lokalt undernet >< lokal maske >< Destinationsundernet ><Destinationsmaske>

du beder ASA om at matche trafik, der kommer fra dit undernet til undernet på den anden side af tunnelen. Dette rejser spørgsmålet om duplikerede private undernet. Hvis dit undernet på indersiden af begge ASAs er det samme, vil du have problemer. Tænk på det på denne måde, når en klient på den ene side forsøger at gå til en ressource på det andet undernet, vil det ikke gå nogen steder. Som standard vil klienten ARP for et svar, fordi den mener, at den eksterne klient, du forsøger at få adgang til, er på sit lokale undernet. Da det ikke forsøger at gå ud af subnet, vil klienten aldrig kontakte standardporten (ASA ‘ s indvendige grænseflade), og du vil aldrig danne en tunnel. Selvom du gjorde det, ville trafikken stadig ikke flyde. Der er nogle ‘vanskelige’ ting, vi kan gøre for at løse dette problem, men de falder ikke inden for denne blogindlæg. Bedste situation er at have unikke private netværk på hvert sted.

fase 2 – Ike fase 1
når ASA får en anmodning om et eksternt undernet, som det matcher til et kryptokort, begynder IKE fase 1. Målet med Ike fase 1 er at opsætte forbindelsen til Ike fase 2. Grundlæggende lægger Ike-fase 1 grundarbejdet for, at den faktiske forbindelse skal forekomme. Det skaber faktisk sin egen SA, der undertiden kaldes management SA. Denne ledelse SA bruges af IKE fase 2 til at skabe de faktiske datatunneler. Fra et teknisk synspunkt er der tre trin til Ike fase 1. Det første skridt kaldes politisk forhandling. Politisk forhandling koger ned til at finde matchende transformationssæt på hvert slutpunkt. Inden ISAKMP sa danner, skal hvert slutpunkt blive enige om et matchende Ike-politiksæt. Følgende punkter skal matche inden for den politik, der er sat på hver side af tunnelen.

-Ike-krypteringsalgoritmen
-Ike-Godkendelsesalgoritmen
-Ike-nøgledefinitionen
– Diffie Hellman-versionen
– Ike-levetiden

husk, IKE-politiksæt er forbundet med Ike-fase 1-færdiggørelse. Et slutpunkt kan have et hvilket som helst antal politiksæt, der evalueres i en rækkefølge. For eksempel kan du have politik sæt 10, 20 og 30. Slutpunkterne gennemgår de politiske sæt i rækkefølge, startende med det laveste først, indtil de finder et match. Derfor giver det mening at definere stærkere politiske sæt først. Hvis de defineres efter svagere politiske sæt, kan du ende med at finde et svagere match først.

nu, før vi går for meget længere ind i IKE fase 1, er det relevant at forklare, at der er to forskellige typer Ike fase 1. Den, der oftest bruges, kaldes ‘hovedtilstand’ og består af 6 meddelelser, der udveksles mellem jævnaldrende. Den anden type kaldes ‘aggressiv’ tilstand og kondenserer de meddelelser, der sendes mellem jævnaldrende i 3 meddelelser. Hovedtilstand er langsommere i opsætningen, men mere sikker. Aggressiv tilstand er hurtigere i opsætningen, men mindre sikker. Citer mig ikke på dette, men jeg tror, at hovedtilstand bruges som standard. Jeg har ikke tænkt mig at dykke ned i detaljerne her, de begge udrette det samme, og detaljerne jeg nævnt ovenfor bør fingerpeg dig ind på de store forskelle.

vores første skridt til Ike fase 1 var politisk forhandling – peers nødt til at blive enige om en matchende politik sæt. De gør dette ved at sende politiksæt til hinanden til sammenligning og finde det laveste matchende politiksæt. Når det er afsluttet, kan vi gå videre til det næste trin, som er DH-nøgleudvekslingen. Under denne proces udveksler jævnaldrende offentlige nøgler, der bruges til at etablere den delte hemmelighed. Når denne proces er udført, dannes fase 1 SA (ISAKMP SA), og vi går videre til det sidste trin, som er peer-godkendelse.

under peer-godkendelse bruges den definerede godkendelsesmetode til at sikre, at useriøse enheder ikke danner sikre forbindelser til dit netværk. Det meste af tiden gøres dette med foruddelte nøgler. Dette trin er ret simpelt, peers kontrollerer for at sikre, at nøglerne matcher. Hvis de ikke gør det, mislykkes godkendelse. Hvis de matcher, går vi videre til IKE-fase 2.

fase 3 – Ike fase 2
jeg kan godt lide at tænke på Ike fase 2 som den egentlige bygning af datatunnelen. Arbejdet op til dette punkt har primært været at sikre, at vi har en sikker kommunikationskanal på plads, så vi kan bygge den faktiske IPsec SAs. Sammenlignet med Ike fase 1 har Ike fase 2 kun en type tilstand, der kaldes ‘hurtig tilstand’. Hurtigtilstand bruger den eksisterende ISAKMP SA oprettet i IKE fase 1 og opretter IPSec SAs og administrerer nøgleudvekslingerne. Det første trin i hurtig tilstand er at forhandle IPSec-transformationssæt (ikke det samme som ISAKMP-politiksættene!!). Følgende punkter skal matche I begge ender for at IPSec SAs kan dannes.

-IPSec-protokollen
-IPsec-krypteringstypen
-IPSec-Godkendelsestypen
– IPSec-tilstanden
– IPSec SA-levetiden

lad os nu tage et kort øjeblik at sammenligne transformationssæt fra Ike fase 1 og fase 2. Følgende er en typisk konfiguration ud af en ASA.

ISAKMP Policy Set
crypto isakmp policy 10
authentication pre-share
encryption 3DES
hash sha
group 2
lifetime 86400

IPSec transform
crypto ipsec transform-set ESP-3DES-SHA esp-3DES esp-sha-HMAC

se noget mærkeligt? I ISAKMP-politiksættet kan du tydeligt se de 5 krævede stykker af transformationssættet, der skal aftales. I IPSec-transformationen er det ikke så klart. Dette skyldes, at transformationen virkelig kun definerer 3 af de 5 krævede stykker. Eksemplet ovenfor definerer IPSec-protokollen (ESP), IPSec-godkendelsestypen (SHA) og IPSec-krypteringstypen (3DES). IPSec-tilstand og IPSec SA levetid behøver ikke at blive defineret. Når de ikke er det, antager ASA simpelthen følgende værdier på 28.800 for SA-levetiden og ‘tunnel’ – tilstanden for alle transformationssæt. Jeg ændrer normalt ikke disse værdier, medmindre den anden side ændrede dem.

så når transformationssættene er blevet forhandlet og matchet, kan vi oprette IPSec SAs. Som nævnt ovenfor er en SA en ensrettet forbindelse. Så for at trafikken skal strømme hver vej, skal der dannes to IPSec SAs. ASA gør dette arbejde for dig selvfølgelig, så der er ikke meget detaljer at dele her. Hurtigtilstand bruger nonces til at generere nyt nøglemateriale, der forhindrer replay-angreb. Det tredje trin er processen med periodisk genforhandling af forbindelsen. SAs skal regenereres inden tunnelens levetid udløber. Hurtigtilstand overvåger dette og genererer nye SAs, før de gamle udløber.

fase 4 – Tunnelafslutning
på dette tidspunkt har vi en fuldt funktionel VPN-tunnel! Trafikken skal passere i begge retninger. Det eneste, der er tilbage at gøre, er at rive tunnelen ned, hvis der ikke er nogen interessant trafik. SAs regenereres kun, hvis interessant trafik fortsætter med at strømme. Hvis interessant trafik stopper kommer i SA får lov til at udløbe ud efter dens levetid er nået. Hvis SA får lov til at udløbe, skylles alle data vedrørende SAS ud af SA. Næste gang interessant trafik genereres hele processen starter fra bunden.

fejlfinding
det mest almindelige problem i IPSec-forbindelse er ikke at finde transform-set-matches til Ike fase 1 og 2. Hvis du løber ind i problemer, er det første, du altid skal gøre, at dobbelttjekke indstillingerne på begge sider for at sikre, at de matcher 100%. Den næste ting du kan gøre er at tage et kig på SAs på ASA og afgøre, om de er oprettet, og hvis de er, hvilken status de har.

for at se Ike Phase 1 sa udstede denne kommando
ASA# Vis crypto isakmp sa

for at se IKE Phase 2 sa udstede denne kommando
ASA# Vis crypto ipsec sa

hvis du ikke har en fase 1 SA, kommer du ikke meget langt. Staten SA fortæller dig et par ting. Det fortæller dig, om SA blev oprettet med hoved-eller aggressiv tilstand, hvilken side bragte tunnelen op, og fortæller dig også status for forhandlinger. Et kig på en typisk fase 1 SA er vist nedenfor.

ASA# Vis crypto isakmp sa
Aktiv SA: 1
Rekey SA: 0 (en tunnel rapporterer 1 aktiv og 1 Rekey SA under rekey)
Total IKE SA: 1

1 Ike Peer: <Peer IP-adresse>
Type : L2L rolle : responder
Rekey : Ingen tilstand : MM_ACTIVE

som du kan se fra ovenstående output, har vi en Ike fase 1 SA. Typen er ‘ L2L ‘(hvilket indikerer, at det er et sted til sted IPSec tunnel), rollen er’ responder ‘ (hvilket betyder, at peer bragte tunnelen op), og tilstanden er MM_Active (hvilket betyder, at den bruger hovedtilstand (MM) og IKE fase 1 fungerer (aktiv)). MM_ACTIVE er, hvad vi ønsker at se på en fase 1 IKE SA. Det betyder, at alt er klar til IKE fase 2 at forekomme. Så hvad skal du gøre, hvis du ikke har den aktive tilstand? Eller ingen SA overhovedet?

der er flere andre stater, der kan clue dig ind i, hvad der foregår med ISAKMP SA.

Bemærk: Disse statuskoder er kun for den nyere Asa-version, den ældre IPSec-kode brugte forskellige statusmeddelelser.
de to første bogstaver fortæller dig, om forbindelsen blev oprettet med hovedtilstand (MM) eller aggressiv tilstand (AM). Da det kan være enten hoved-eller aggressiv tilstand, vil jeg liste er simpelthen som ‘ … ‘ nedenfor. Indrømmet, at du kun vil se nogle af dem med enten hoved-eller aggressiv tilstand. Definitionerne jeg liste til hver stat er, hvad jeg har fundet at være problemet i de fleste tilfælde.

Active – Connected
Authentication error, kontroller din authentication method
Authentication error, kontroller din authentication method
ikke i stand til at matche Ike fase 1 – politikker, bekræft på hver side
VE_VAIT_MSG2 – venter på svar fra peer

desuden, hvis du har ikke en sa overhovedet, start med at kontrollere det åbenlyse. Start ved lag 1 og arbejd dig op for at sikre, at begge enheder har forbindelse, og at peer-adresserne er korrekte.

99% af tiden er et problem med IKE fase 1 SA. Hvis du får en tilstand af aktiv på fase 1, er du sandsynligvis i god form. Hvis du stadig har problemer, tage et kig på din Ike fase 2 SA. Jeg vil ikke vise et eksempel på en, da det for det meste kun er statistik. Det samme koncept gælder dog, hvis du ikke har en IPSec SA, har du ikke en VPN-tunnel.

Debugging
hvis du stadig har problemer, som noget andet på ASA, prøv debugging. De to kommandoer, du leder efter, ville være…

Asa# debug crypto isakmp
Asa# debug crypto ipsec
asa# terminal monitor

sørg for at aktivere terminal monitor, hvis du ikke er på konsolporten

Den Store løsning
jeg kan ikke fortælle dig, hvor mange gange jeg har brugt timer på at få en tunnel til at indlæse med absolut ingen succes. I sidste ende løste to kommandoer altid mine problemer. Når alt andet fejler, rydde alle dine ISAKMP og IPSEC SAs. Dette vil naturligvis blæse alle IPSec-forbindelser til kassen væk. Noget ved bare at sprænge alle de andre forbindelser væk og starte fra bunden ser ud til at ordne det. For at gøre dette….

ASA# clear crypto ipsec sa
ASA# clear crypto isakmp sa

konklusion
jeg håber, at du gennem denne artikel har set, at det at have en baseforståelse af, hvordan IPSec fungerer, gør en verden til forskel. At vide, hvor man skal kigge efter fejl, og hvordan man fortolker dem, er nøglen til fejlfinding af IPSec L2L-tunneler.