MAC stemmer ikke i IKE betyr at kontrollen av den delte nøkkelen mislyktes

Cloud VPN-loggen din viser et forsøk med en delt nøkkel etterfulgt av MAC mismatched, og den første impulsen er ofte å lete etter et adresseproblem. I denne grenen er MAC en meldingsautentiseringskode: en verdi beregnet over utvekslingen med den forhandlede nøkkelen. Motparten sammenlignet sin egen beregning med verdien den fikk, og de var forskjellige. Det er ikke noe nettverkskort involvert, og ingen grensesnittinnstilling endrer den sammenligningen.

I praksis fremkaller to betingelser den: hemmelighetene i de to endene er ikke samme verdi, eller identitetene som brukes til å velge hemmeligheten samsvarer ikke. Avgjør hvilken ved å lese paret, ikke den enkelte tunnelen.

Hva trinnet beviser

Kontrollen kjører etter at begge sider har utvekslet startparametere og identifisert seg. Den velger kandidat-delte nøkler for den lokale og eksterne identiteten og prøver å validere de mottatte autentiseringsdataene; når ingen validerer, sendes diagnosen ut. Det er en sterk uttalelse om autentisering og en svak om årsaken, fordi den ikke sier hvilken side som er feil.

Tidligere suksess overføres ikke til denne kontrollen. En fullført IKE_SA_INIT, eller en NAT-deteksjonsnyttelast som returnerte de forventede verdiene, beviser at motpartene kan snakke sammen. Det beviser ingenting om hvorvidt de deler en hemmelighet.

To konfigurasjonsfeil, én melding

Den første er en reell uoverensstemmelse i hemmeligheten, og det er vanligvis en klargjøringsulykke: en generert verdi installert på én konsoll og skrevet på nytt på den andre, et etterfølgende tegn som overlevde på den ene siden, eller et anførselstegn som kom med en innliming. Den andre er en identitetsuoverensstemmelse, der hemmeligheten er riktig, men identiteten motparten presenterer velger en annen oppføring, slik at den riktige hemmeligheten aldri prøves. Begge gir samme linje, derfor koster gjetting en ettermiddag.

Sammenlign paret før du rører noen hemmelighet. Tilpass tunnelen, motpartens endepunkt, tidsvinduet og den eksterne konfigurasjonen, fordi to overflødige tunneler kan ha forskjellige hemmeligheter, og skjermen foran deg er kanskje ikke den som feilet.

NAT-deteksjon er et annet trinn

NAT-deteksjon spør hvordan pakker skrives om, ikke hvem motparten er. En kundegateway bak NAT autentiserer fortsatt riktig når dens konfigurerte identitet er den motparten forventer, og et NAT-problem vises som en uoverensstemmelse i forslag eller port i stedet for en mislykket autentiseringssammenligning.

Ikke overfør en gammel uttalelse om én leverandørversjon til en gjeldende utrulling. Det NAT-gjennomgang krever i din versjon, hører til dens egen dokumentasjon, og uttrykket MAC mismatch er ikke bevis for eller mot.

Avgjør ut fra paret, ikke skjermen

Les begge konfigurasjonene side ved side med hemmeligheten skjult, og still deretter tre spørsmål. Er identiteten på hver side nøyaktig det den andre forventer, tegn for tegn? Bruker begge ender samme IKE-versjon og samme autentiseringsmetode? Svarer den feilende tunnelen til konfigurasjonen du leser? Et nei på et av dem avgjør reparasjonen uten å røre hemmeligheten.

Hvis alle tre er rene, erstatt hemmeligheten gjennom den godkjente arbeidsflyten i stedet for å redigere rundt den.

Etter at motparten autentiserer

Når autentiseringen lykkes, er neste feilflate den underordnede sikkerhetsassosiasjonen: forslag og trafikkvelgere. Å rotere en hemmelighet som allerede er akseptert kan ikke rette en underordnet feil, og det forlenger avbruddet. Les den underordnede tilstanden, deretter velgerne og beskyttede områder på begge sider, og tilpass veiledningen for feilsøking av Cloud VPN til trinnet som faktisk feilet.

Korreler ferske logger fra begge ender for samme par og samme vindu. Én side alene gir en dom uten den andres input, og det er tvetydigheten som skapte meldingen i utgangspunktet.

Hva man ikke skal konkludere

Ikke les meldingen som et krav om å endre MAC-adresser, og ikke publiser den delte hemmeligheten mens du ber om hjelp; et utdrag som inneholder nøkkelen trenger at nøkkelen fjernes, ikke at loggen beholdes. Ikke anta en rutingfeil heller, fordi motparter som ikke kan nå hverandre, ikke lager noen autentiseringssammenligning i det hele tatt. Og ikke generaliser en dokumentert begrensning fra én produktfamilie til enhver IPsec-implementering.

Registrer paret som feiler, tunnelens tilstand før og etter, og hvilken av de to betingelsene du endret. Den registreringen gjør neste forekomst til en fem minutters kontroll.