MAC samsvarar ikkje i IKE: kontrollen av den delte nøkkelen mislukkast

Cloud VPN-loggen din viser eit forsøk med delt nøkkel, etterfølgt av meldinga om at MAC ikkje samsvarar, og den første innskoten er ofte å leite etter eit adresseproblem. I denne greina er MAC ein meldingsautentiseringskode: ein verdi som blir rekna ut over utvekslinga med den forhandla nøkkelen. Motparten samanlikna si eiga utrekning med verdien han tok imot, og dei var ulike. Ingen nettverkskort er involvert, og ingen grensesnittinnstilling endrar denne samanlikninga.

To tilhøve skapar dette i praksis: nøklane på dei to endane er ikkje same verdi, eller identitetane som blir brukte til å velje nøkkelen, svarar ikkje til kvarandre. Avgjer kva av dei to det er ved å lese paret, ikkje den enkelte tunnelen.

Kva steget beviser

Kontrollen køyrer etter at båe sider har utveksla startparametrane sine og identifisert seg. Han vel kandidatnøklar for den lokale og den eksterne identiteten og prøver å validere autentiseringsdataa som er mottekne; når ingen av dei validerer, blir diagnosen sende ut. Det er ei sterk utsegn om autentisering og ei svak utsegn om årsak, fordi han ikkje seier kva side som er feil.

Tidlegare suksess gjeld ikkje for denne kontrollen. Ein fullført IKE_SA_INIT, eller ei NAT-detekteringsnyttelast som gav dei venta verdiane, beviser at motpartane kan snakke saman. Det beviser ingenting om dei deler ein nøkkel.

To konfigurasjonsfeil, éi melding

Den første er ein reell nøkkelmismatch, og han er oftast ei ulukke i klargjeringa: ein generert verdi installert på éin konsoll og skriven inn på nytt på den andre, eit teikn på slutten som overlevde på den eine sida, eller eit hermeteikn som følgde med eit innliming. Den andre er ein identitetsmismatch, der nøkkelen er rett, men identiteten motparten presenterer vel ei anna oppføring, slik at den rette nøkkelen aldri blir prøvd. Båe gir same linja, og difor kostar gissing ein ettermiddag.

Samanlikn paret før du rører nokon av nøklane. Match tunnelen, motpartens endepunkt, tidsvindauget og den eksterne konfigurasjonen, fordi to redundante tunnelar kan halde ulike nøklar og skjermen framfor deg er kanskje ikkje den som feila.

NAT-detektering er eit anna steg

NAT-detektering spør korleis pakkane blir skrivne om, ikkje kven motparten er. Ein kundegateway bak NAT autentiserer framleis rett når den konfigurerte identiteten er den motparten ventar, og eit NAT-problem viser seg som eit forslag- eller portavvik i staden for ein mislukka autentiseringssamanlikning.

Ikkje tak med ei gammal utsegn om éin leverandørversjon inn i ein aktuell utrulling. Kva NAT-traversering krev i din versjon, høyrer heime i eigen dokumentasjon, og uttrykket MAC-mismatch er ikkje bevis for eller mot det.

Avgjer ut frå paret, ikkje skjermen

Les båe konfigurasjonane side om side med hemmelegheiten sladda, og still så tre spørsmål. Er identiteten på kvar side nøyaktig det den andre ventar, teikn for teikn? Brukar båe endar same IKE-versjon og same autentiseringsmetode? Svarar den feilande tunnelen til konfigurasjonen du les? Eit nei på noko av dette avgjer reparasjonen utan at du rører hemmelegheiten.

Er alle tre reine, byt ut hemmelegheiten gjennom den godkjende arbeidsflyten i staden for å arbeide rundt han.

Etter at motparten har autentisert seg

Når autentiseringa lukkast, er den neste feilflata barnesikkerheitskoplinga: forslag og trafikkveljarar. Å rotere ein hemmelegheit som alt er godteken kan ikkje rette ein feil i barnet, og det forlenger avbrotet. Les tilstanden til barnet, så veljarane og dei verna områda på båe sider, og knyt rettleiinga i Cloud VPN feilsøking til steget som faktisk feila.

Korreler ferske loggar frå båe endar for same par og same vindauge. Éi side åleine gir ein dom utan den andre sida sitt innspel, og det er nettopp tvitydigheita som skapte meldinga i utgangspunktet.

Kva du ikkje bør slutte

Les ikkje meldinga som eit krav om å endre MAC-adresser, og ikkje publiser den delte nøkkelen når du ber om hjelp; eit utdrag som inneheld nøkkelen treng at nøkkelen blir fjerna, ikkje at loggen blir halden. Ikkje gå ut frå ein rutefeil heller, fordi motpartar som ikkje når kvarandre, gir ingen autentiseringssamanlikning i det heile. Og generaliser ikkje ei dokumentert avgrensing frå éin produktfamilie til kvar IPsec-implementasjon.

Skriv ned paret som feila, tunnelstanden før og etter, og kva av dei to tilhøva du endra. Den loggen gjer neste førekomst om til ein kontroll på fem minutt.