MAC samsvarer ikke i IKE: kontrollen av den delte nøkkelen mislyktes

Cloud VPN-loggen din viser et forsøk med delt nøkkel, etterfulgt av meldingen om at MAC ikke samsvarer, og den første innskytelsen er ofte å lete etter et adresseproblem. I denne grenen er MAC en meldingsautentiseringskode: en verdi som beregnes over utvekslingen med den forhandlede nøkkelen. Motparten sammenlignet sin egen beregning med verdien den mottok, og de var ulike. Ingen nettverkskort er involvert, og ingen grensesnittinnstilling endrer den sammenligningen.

To forhold skaper dette i praksis: nøklene på de to endene er ikke samme verdi, eller identitetene som brukes til å velge nøkkelen, samsvarer ikke. Avgjør hvilken av dem ved å lese paret, ikke den enkelte tunnelen.

Hva trinnet beviser

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

Tidligere suksess gjelder ikke for 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 de deler en nøkkel.

To konfigurasjonsfeil, én melding

Den første er en reell nøkkelmismatch, og den er som regel en ulykke ved klargjøringen: en generert verdi installert på én konsoll og skrevet inn på nytt på den andre, et tegn på slutten som overlevde på den ene siden, eller et anførselstegn som fulgte med en innliming. Den andre er en identitetsmismatch, der nøkkelen er riktig, men identiteten motparten presenterer velger en annen oppføring, slik at den riktige nøkkelen aldri prøves. Begge gir samme linje, og derfor koster gjetting en ettermiddag.

Sammenlign paret før du rører noen av nøklene. Match tunnelen, motpartens endepunkt, tidsvinduet og den eksterne konfigurasjonen, fordi to redundante tunneler kan holde ulike nøkler, og skjermen foran deg er kanskje ikke den som feilet.

NAT-deteksjon er et annet trinn

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

Ikke ta med en gammel uttalelse om én leverandørutgave inn i en aktuell utrulling. Hva NAT-traversering krever i din utgave, hører hjemme i dens egen dokumentasjon, og uttrykket MAC-mismatch er ikke bevis for eller mot det.

Avgjør ut fra paret, ikke skjermen

Les begge konfigurasjonene side ved side med hemmeligheten sladdet, og still så 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å noe av dette avgjør reparasjonen uten at du rører hemmeligheten.

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

Etter at motparten har autentisert seg

Når autentiseringen lykkes, er den neste feilflaten barnesikkerhetsassosiasjonen: forslag og trafikkvelgere. Å rotere en hemmelighet som allerede er godtatt kan ikke rette en barnfeil, og det forlenger avbruddet. Les tilstanden til barnet, deretter velgerne og de beskyttede områdene på begge sider, og knyt veiledningen i Cloud VPN-feilsøking 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 andre sidens innspill, og det er nettopp tvetydigheten som skapte meldingen i utgangspunktet.

Hva du ikke bør konkludere

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

Skriv ned paret som feilet, tunnelstatusen før og etter, og hvilket av de to forholdene du endret. Den loggen gjør neste forekomst om til en kontroll på fem minutter.