MAC stemmer ikke overens i IKE betyder, at kontrollen af den delte nøgle mislykkedes

Din Cloud VPN-log viser et forsøg med en delt nøgle efterfulgt af MAC mismatched, og den første impuls er ofte at lede efter et adresseproblem. I denne gren er MAC en meddelelsesautentificeringskode: en værdi beregnet over udvekslingen med den forhandlede nøgle. Modparten sammenlignede sin egen beregning med den værdi, den modtog, og de var forskellige. Der er ikke noget netværkskort involveret, og ingen interfaceindstilling ændrer den sammenligning.

I praksis fremkalder to betingelser det: hemmelighederne i de to ender er ikke den samme værdi, eller de identiteter, der bruges til at vælge hemmeligheden, svarer ikke til hinanden. Afgør hvilken ved at læse parret, ikke den enkelte tunnel.

Hvad trinnet beviser

Kontrollen kører, efter at begge sider har udvekslet startparametre og identificeret sig. Den vælger kandidat-delte nøgler til den lokale og fjernede identitet og forsøger at validere de modtagne autentificeringsdata; når ingen validerer, udsendes diagnosen. Det er en stærk udtalelse om autentificering og en svag om årsagen, fordi den ikke siger, hvilken side der er forkert.

Tidligere succes overføres ikke til denne kontrol. En fuldført IKE_SA_INIT eller en NAT-detektionsnyttelast, der returnerede de forventede værdier, beviser, at modparterne kan tale sammen. Det beviser intet om, hvorvidt de deler en hemmelighed.

To konfigurationsfejl, én meddelelse

Den første er en reel uoverensstemmelse i hemmeligheden, og det er normalt en fejl ved klargøring: en genereret værdi installeret på én konsol og skrevet igen på den anden, et efterfølgende tegn, der overlevede på den ene side, eller et citationstegn, der kom med en indsætning. Den anden er en identitetsuoverensstemmelse, hvor hemmeligheden er korrekt, men den identitet, modparten præsenterer, vælger en anden post, så den rigtige hemmelighed aldrig prøves. Begge giver den samme linje, og derfor koster gætteri en eftermiddag.

Sammenlign parret, før du rører nogen hemmelighed. Afstem tunnelen, modpartens slutpunkt, tidsvinduet og den fjernede konfiguration, fordi to redundante tunneler kan have forskellige hemmeligheder, og skærmen foran dig er måske ikke den, der fejlede.

NAT-detektion er et andet trin

NAT-detektion spørger, hvordan pakker omskrives, ikke hvem modparten er. En kundegateway bag NAT autentificerer stadig korrekt, når dens konfigurerede identitet er den, modparten forventer, og et NAT-problem viser sig som en uoverensstemmelse i forslag eller port i stedet for en mislykket autentificeringssammenligning.

Overfør ikke en gammel erklæring om én leverandørversion til en aktuel udrulning. Hvad NAT-gennemgang kræver i din version, hører til dens egen dokumentation, og udtrykket MAC mismatch er ikke bevis for eller imod.

Afgør ud fra parret, ikke skærmen

Læs begge konfigurationer side om side med hemmeligheden skjult, og stil derefter tre spørgsmål. Er identiteten på hver side præcis det, den anden forventer, tegn for tegn? Bruger begge ender samme IKE-version og samme autentificeringsmetode? Svarer den fejlende tunnel til den konfiguration, du læser? Et nej til et af dem afgør reparationen uden at røre hemmeligheden.

Hvis alle tre er rene, skal du erstatte hemmeligheden gennem den godkendte arbejdsgang i stedet for at redigere rundt om den.

Efter modparten autentificerer

Når autentificeringen lykkes, er den næste fejlflade den underordnede sikkerhedsassociation: forslag og trafikvælgere. At rotere en hemmelighed, der allerede er accepteret, kan ikke rette en underordnet fejl og forlænger afbrydelsen. Læs den underordnede tilstand, derefter vælgerne og de beskyttede områder på begge sider, og match fejlfinding af Cloud VPN-vejledningen til det trin, der faktisk fejlede.

Korrelér friske logfiler fra begge ender for det samme par og det samme vindue. En side alene giver en dom uden den andens input, og det er den tvetydighed, der skabte meddelelsen til at begynde med.

Hvad man ikke skal konkludere

Læs ikke meddelelsen som et krav om at ændre MAC-adresser, og offentliggør ikke den delte hemmelighed, mens du beder om hjælp; et uddrag, der indeholder nøglen, skal have nøglen fjernet, ikke loggen bevaret. Antag heller ikke en routingfejl, fordi modparter, der ikke kan nå hinanden, slet ikke skaber nogen autentificeringssammenligning. Og generaliser ikke en dokumenteret begrænsning fra én produktfamilie til enhver IPsec-implementering.

Registrér det fejlende par, tunnelens tilstand før og efter, og hvilken af de to betingelser du ændrede. Den registrering gør den næste forekomst til en fem minutters kontrol.