MAC stämmer inte i IKE: kontrollen av den delade nyckeln misslyckades

Din Cloud VPN-logg visar ett försök med delad nyckel följt av meddelandet att MAC inte stämmer, och den första instinkten är ofta att leta efter ett adressproblem. I den här grenen är MAC en meddelandeautentiseringskod: ett värde som beräknas över utbytet med den förhandlade nyckeln. Motparten jämförde sin egen beräkning med värdet den tog emot, och de skilde sig. Inget nätverkskort är inblandat, och ingen gränssnittsinställning ändrar den jämförelsen.

Två förhållanden skapar detta i praktiken: nycklarna på de två ändarna är inte samma värde, eller identiteterna som används för att välja nyckeln stämmer inte överens. Avgör vilket genom att läsa paret, inte den enskilda tunneln.

Vad steget bevisar

Kontrollen körs efter att båda sidor har utbytt sina initialparametrar och identifierat sig. Den väljer kandidatnycklar för den lokala och den externa identiteten och försöker validera de mottagna autentiseringsuppgifterna; när ingen validerar skickas diagnosen ut. Det är ett starkt påstående om autentisering och ett svagt påstående om orsak, eftersom det inte säger vilken sida som är fel.

Tidigare framgång gäller inte för den här kontrollen. En slutförd IKE_SA_INIT, eller en NAT-detekteringsnyttolast som returnerade de förväntade värdena, bevisar att motparterna kan prata med varandra. Det bevisar ingenting om de delar en nyckel.

Två konfigurationsfel, ett meddelande

Det första är en verklig nyckelmismatch, och den är oftast en olycka vid etableringen: ett genererat värde installerat på en konsol och inskrivet igen på den andra, ett tecken i slutet som överlevde på ena sidan, eller ett citattecken som följde med en inklistring. Det andra är en identitetsmismatch, där nyckeln är korrekt men identiteten motparten presenterar väljer en annan post, så att rätt nyckel aldrig provas. Båda ger samma rad, och därför kostar gissande en eftermiddag.

Jämför paret innan du rör någon av nycklarna. Matcha tunneln, motpartens slutpunkt, tidsfönstret och den externa konfigurationen, eftersom två redundanta tunnlar kan hålla olika nycklar och skärmen framför dig kanske inte är den som misslyckades.

NAT-detektering är ett annat steg

NAT-detektering frågar hur paketen skrivs om, inte vem motparten är. En kundgateway bakom NAT autentiserar fortfarande korrekt när den konfigurerade identiteten är den motparten förväntar sig, och ett NAT-problem visar sig som ett förslags- eller portavvik i stället för en misslyckad autentiseringsjämförelse.

Bär inte med dig ett gammalt påstående om en leverantörsrelease in i en aktuell driftsättning. Vad NAT-traversering kräver i din release hör hemma i dess egen dokumentation, och uttrycket MAC-mismatch är inte bevis för eller emot det.

Avgör utifrån paret, inte skärmen

Läs båda konfigurationerna sida vid sida med hemligheten maskad och ställ sedan tre frågor. Är identiteten på varje sida exakt det den andra förväntar sig, tecken för tecken? Använder båda ändar samma IKE-version och samma autentiseringsmetod? Motsvarar den felande tunneln konfigurationen du läser? Ett nej på någon av dessa avgör reparationen utan att du rör hemligheten.

Om alla tre är rena, byt ut hemligheten genom det godkända arbetsflödet i stället för att arbeta runt den.

Efter att motparten har autentiserat

När autentiseringen lyckas är nästa felområde den underordnade säkerhetsassociationen: förslag och trafikväljare. Att rotera en hemlighet som redan har accepterats kan inte åtgärda ett barnfel, och det förlänger avbrottet. Läs barnets tillstånd, sedan väljarna och de skyddade intervallen på båda sidor, och koppla vägledningen i Cloud VPN-felsökning till det steg som faktiskt misslyckades.

Korrelera färska loggar från båda ändar för samma par och samma fönster. En sida ensam ger en dom utan den andra sidans bidrag, och det är precis den tvetydighet som skapade meddelandet från början.

Vad du inte bör dra för slutsatser

Läs inte meddelandet som ett krav på att ändra MAC-adresser, och publicera inte den delade nyckeln när du ber om hjälp; ett utdrag som innehåller nyckeln behöver nyckeln borttagen, inte loggen behållen. Anta inte heller ett routningsfel, eftersom motparter som inte når varandra inte ger någon autentiseringsjämförelse alls. Och generalisera inte en dokumenterad begränsning från en produktfamilj till varje IPsec-implementering.

Anteckna paret som misslyckades, tunnelstatusen före och efter, och vilket av de två förhållandena du ändrade. Den anteckningen gör nästa förekomst till en kontroll på fem minuter.