MAC komt niet overeen in IKE: de controle van de gedeelde sleutel is mislukt

Je Cloud VPN-logboek toont een poging met een gedeelde sleutel, direct gevolgd door de melding dat de MAC niet overeenkomt, en de eerste neiging is vaak om een adresprobleem te zoeken. In deze vertakking is MAC een berichtauthenticatiecode: een waarde die over de uitwisseling met de onderhandelde sleutel wordt berekend. De peer vergeleek zijn eigen berekening met de waarde die hij ontving, en die verschilden. Er is geen netwerkkaart bij betrokken, en geen enkele interface-instelling verandert die vergelijking.

Twee omstandigheden veroorzaken dit in de praktijk: de sleutels aan beide uiteinden zijn niet dezelfde waarde, of de identiteiten waarmee de sleutel wordt gekozen komen niet overeen. Bepaal welke van de twee door het paar te lezen, niet de enkele tunnel.

Wat deze fase bewijst

De controle draait nadat beide zijden hun initiële parameters hebben uitgewisseld en zich hebben geïdentificeerd. Hij kiest kandidaatsleutels voor de lokale en externe identiteit en probeert de ontvangen authenticatiegegevens te valideren; als geen enkele kandidaat klopt, wordt de diagnose afgegeven. Dat is een sterke uitspraak over authenticatie en een zwakke uitspraak over de oorzaak, want hij zegt niet welke kant fout zit.

Eerder succes geldt niet voor deze controle. Een afgeronde IKE_SA_INIT, of een NAT-detectiepayload die de verwachte waarden teruggaf, bewijst dat de peers met elkaar kunnen praten. Het bewijst niets over de vraag of zij een sleutel delen.

Twee configuratiefouten, één melding

De eerste is een echte sleutelmismatch, en meestal is het een fout bij het inrichten: een gegenereerde waarde die op de ene console is geïnstalleerd en op de andere opnieuw is getypt, een teken aan het eind dat aan één kant bleef staan, of een aanhalingsteken dat meeliftte met een plakactie. De tweede is een identiteitsmismatch, waarbij de sleutel correct is maar de identiteit die de peer presenteert een andere vermelding kiest, zodat de juiste sleutel nooit wordt geprobeerd. Beide leveren dezelfde regel op, en daarom kost gokken een middag.

Vergelijk het paar voordat je een van beide sleutels aanraakt. Laat de tunnel, het peer-eindpunt, het tijdvenster en de externe configuratie overeenkomen, want twee redundante tunnels kunnen verschillende sleutels bevatten en het scherm voor je is misschien niet dat van de mislukte tunnel.

NAT-detectie is een andere fase

NAT-detectie vraagt hoe pakketten worden herschreven, niet wie de peer is. Een klantgateway achter NAT authenticeert nog steeds correct wanneer de geconfigureerde identiteit de identiteit is die de peer verwacht, en een NAT-probleem verschijnt als een voorstel- of poortmismatch in plaats van als een mislukte authenticatievergelijking.

Neem een oude uitspraak over één leveranciersrelease niet mee naar een huidige implementatie. Wat NAT-traversal in jouw release vereist, hoort in de eigen documentatie daarvan, en de term MAC-mismatch is geen bewijs voor of tegen.

Beslis op basis van het paar, niet van het scherm

Lees beide configuraties naast elkaar met het geheim weggelaten en stel dan drie vragen. Is de identiteit aan elke kant precies wat de andere kant verwacht, teken voor teken? Gebruiken beide uiteinden dezelfde IKE-versie en dezelfde authenticatiemethode? Komt de falende tunnel overeen met de configuratie die je leest? Een nee op een van deze vragen bepaalt de reparatie zonder dat je het geheim aanraakt.

Als alle drie schoon zijn, vervang dan het geheim via de goedgekeurde werkwijze in plaats van eromheen te werken.

Nadat de peer zich heeft geauthenticeerd

Zodra authenticatie slaagt, is het volgende storingsvlak de onderliggende security-associatie: voorstellen en verkeersselectoren. Een geheim roteren dat al is geaccepteerd kan een fout in de onderliggende SA niet oplossen, en het verlengt de storing. Lees de status van de onderliggende SA, dan de selectoren en beschermde bereiken aan beide zijden, en koppel de richtlijnen uit Cloud VPN-probleemoplossing aan de fase die daadwerkelijk is mislukt.

Correleer verse logboeken van beide uiteinden voor hetzelfde paar en hetzelfde tijdvenster. Eén kant alleen geeft een oordeel zonder de inbreng van de andere kant, en dat is precies de dubbelzinnigheid die de melding oorspronkelijk veroorzaakte.

Wat je hieruit niet moet concluderen

Lees de melding niet als een eis om MAC-adressen te wijzigen, en publiceer het gedeelde geheim niet als je om hulp vraagt; een fragment met de sleutel moet de sleutel eruit hebben, niet het logboek erin. Ga ook niet uit van een routeringsfout, want peers die elkaar niet kunnen bereiken leveren helemaal geen authenticatievergelijking op. En generaliseer een gedocumenteerde beperking van de ene productfamilie niet naar elke IPsec-implementatie.

Leg het falende paar vast, de tunnelstatus voor en na, en welke van de twee omstandigheden je hebt gewijzigd. Dat verslag maakt van de volgende keer een controle van vijf minuten.