Neslaganje MAC u IKE-u znači da je provjera zajedničkog ključa neuspješna

Vaš Cloud VPN dnevnik pokazuje pokušaj sa zajedničkim ključem nakon kojeg slijedi MAC mismatched, a prvi instinkt često je traženje problema s adresom. U ovoj grani MAC je kod za autentifikaciju poruke: vrijednost izračunata nad razmjenom s dogovorenim ključem. Partner je uporedio svoj izračun s primljenom vrijednošću i one su se razlikovale. Ovdje nije uključena mrežna kartica i nijedna postavka interfejsa ne mijenja to poređenje.

U praksi to izazivaju dva uslova: tajne na dva kraja nisu ista vrijednost ili se identiteti koji se koriste za odabir tajne ne poklapaju. Odredite koji tako što ćete pročitati par, a ne pojedinačni tunel.

Šta faza dokazuje

Provjera se izvršava nakon što su obje strane razmijenile početne parametre i predstavile se. Ona bira kandidatske zajedničke ključeve za lokalni i udaljeni identitet i pokušava validirati primljene podatke autentifikacije; kada nijedan ne prođe, dijagnostika se ispisuje. To je jaka tvrdnja o autentifikaciji i slaba o uzroku, jer ne kaže koja je strana pogriješila.

Raniji uspjeh se ne prenosi u ovu provjeru. Završen IKE_SA_INIT, ili NAT payload za otkrivanje koji je vratio očekivane vrijednosti, dokazuje da partneri mogu razgovarati. Ne dokazuje ništa o tome dijele li tajnu.

Dvije konfiguracijske greške, jedna poruka

Prva je stvarno neslaganje tajne i obično je nezgoda pri provizioniranju: generirana vrijednost instalirana na jednoj konzoli i ponovno otkucana na drugoj, znak na kraju koji je preživio na jednoj strani, ili navodnik koji je došao s lijepljenjem. Druga je neslaganje identiteta, gdje je tajna ispravna ali identitet koji partner predstavlja odabire drugi unos, pa se ispravna tajna nikada ne isproba. Obje daju isti red, zato nagađanje košta jedno popodne.

Uporedite par prije nego što dodirnete bilo koju tajnu. Uskladite tunel, krajnju tačku partnera, vremenski prozor i udaljenu konfiguraciju, jer dva redundantna tunela mogu držati različite tajne a ekran pred vama možda nije onaj koji je pao.

NAT otkrivanje je druga faza

NAT otkrivanje pita kako se paketi prepisuju, a ne ko je partner. Korisnički gateway iza NAT-a i dalje se ispravno autentifikuje kada je njegov konfigurisani identitet onaj koji partner očekuje, a problem s NAT-om se pojavljuje kao neslaganje predloga ili porta, a ne kao neuspjelo poređenje autentifikacije.

Ne prenosite staru tvrdnju o jednom izdanju dobavljača u trenutno postavljanje. Ono što NAT prolaz zahtijeva u vašem izdanju pripada njegovoj vlastitoj dokumentaciji, a fraza MAC mismatch nije dokaz za ili protiv.

Odlučite iz para, a ne sa ekrana

Pročitajte obje konfiguracije jednu uz drugu s uklonjenom tajnom, pa postavite tri pitanja. Je li identitet na svakoj strani tačno ono što druga očekuje, slovo po slovo? Koriste li oba kraja istu verziju IKE-a i istu metodu autentifikacije? Odgovara li tunel koji pada konfiguraciji koju čitate? Ne na bilo koje od njih odlučuje popravku bez diranja tajne.

Ako su sva tri čista, zamijenite tajnu kroz odobreni radni tok umjesto da uređujete oko nje.

Nakon što se partner autentifikuje

Kada autentifikacija uspije, sljedeća površina kvara je dijete sigurnosne asocijacije: predlozi i selektori saobraćaja. Rotiranje tajne koja je već prihvaćena ne može popraviti kvar djeteta i produžava prekid. Pročitajte stanje djeteta, zatim selektore i zaštićene opsege na obje strane, i uskladite smjernice rješavanja problema Cloud VPN-a s fazom koja je zaista pala.

Povežite svježe dnevnike s oba kraja za isti par i isti prozor. Jedna strana sama daje presudu bez ulaza druge, a to je dvosmislenost koja je prvobitno stvorila poruku.

Šta ne treba zaključiti

Ne čitajte poruku kao zahtjev za promjenom MAC adresa i ne objavljujte zajedničku tajnu dok tražite pomoć; izvod koji sadrži ključ mora imati uklonjen ključ, a ne sačuvan dnevnik. Ne pretpostavljajte ni grešku usmjeravanja, jer partneri koji ne mogu doći jedan do drugog uopće ne stvaraju poređenje autentifikacije. I ne generalizujte dokumentirano ograničenje jednog proizvodnog roda na svaku IPsec implementaciju.

Zabilježite par koji je pao, stanje tunela prije i poslije i koji ste od dva uslova promijenili. Taj zapis pretvara sljedeću pojavu u petominutnu provjeru.