Niezgodność MAC w IKE oznacza, że kontrola klucza współdzielonego nie powiodła się

Dziennik Cloud VPN pokazuje próbę z kluczem współdzielonym, po której pojawia się informacja o niezgodności MAC, a pierwszy odruch to zwykle szukanie problemu z adresem. W tej gałęzi MAC to kod uwierzytelniania wiadomości: wartość obliczana na podstawie wymiany z wynegocjowanym kluczem. Partner porównał własne obliczenie z otrzymaną wartością i różniły się one. Żadna karta sieciowa nie bierze w tym udziału i żadne ustawienie interfejsu nie zmienia tego porównania.

W praktyce powodują to dwa warunki: klucze po obu stronach nie mają tej samej wartości albo tożsamości używane do wyboru klucza nie odpowiadają sobie. Rozstrzygnij który, czytając parę, a nie pojedynczy tunel.

Co dowodzi ten etap

Kontrola działa po wymianie parametrów początkowych przez obie strony i po ich przedstawieniu się. Wybiera klucze kandydujące dla tożsamości lokalnej i zdalnej i próbuje zweryfikować otrzymane dane uwierzytelniające; gdy żaden nie przejdzie weryfikacji, emitowana jest diagnostyka. To mocne stwierdzenie o uwierzytelnianiu i słabe o przyczynie, bo nie mówi, która strona jest błędna.

Wcześniejszy sukces nie przenosi się na tę kontrolę. Ukończony IKE_SA_INIT albo ładunek wykrywania NAT, który zwrócił oczekiwane wartości, dowodzi, że partnerzy mogą się komunikować. Nie dowodzi niczego o tym, czy dzielą klucz.

Dwa błędy konfiguracji, jeden komunikat

Pierwszy to rzeczywista niezgodność kluczy, zwykle wypadek przy wdrażaniu: wygenerowana wartość zainstalowana na jednej konsoli i przepisana na drugiej, znak na końcu, który przetrwał po jednej stronie, albo cudzysłów przyklejony podczas wklejania. Drugi to niezgodność tożsamości, w której klucz jest poprawny, ale tożsamość przedstawiana przez partnera wybiera inny wpis, więc właściwy klucz nigdy nie jest próbowany. Oba dają tę samą linię, dlatego zgadywanie kosztuje popołudnie.

Porównaj parę, zanim dotkniesz któregokolwiek klucza. Dopasuj tunel, punkt końcowy partnera, okno czasu i konfigurację zdalną, bo dwa nadmiarowe tunele mogą mieć różne klucze, a ekran przed tobą może nie być tym, który zawiódł.

Wykrywanie NAT to inny etap

Wykrywanie NAT pyta, jak przepisywane są pakiety, a nie kim jest partner. Brama klienta za NAT nadal uwierzytelnia się poprawnie, gdy skonfigurowana tożsamość jest tą, której oczekuje partner, a problem z NAT ujawnia się jako niezgodność propozycji lub portu, a nie jako nieudane porównanie uwierzytelniania.

Nie przenoś starego stwierdzenia o jednym wydaniu dostawcy do bieżącego wdrożenia. To, czego wymaga przechodzenie przez NAT w twoim wydaniu, należy do jego własnej dokumentacji, a sformułowanie niezgodność MAC nie jest dowodem za ani przeciw.

Rozstrzygaj na podstawie pary, nie ekranu

Przeczytaj obie konfiguracje obok siebie z zasłoniętym kluczem, a potem zadaj trzy pytania. Czy tożsamość po każdej stronie jest dokładnie tym, czego oczekuje druga strona, znak po znaku? Czy oba końce używają tej samej wersji IKE i tej samej metody uwierzytelniania? Czy zawodzący tunel odpowiada konfiguracji, którą czytasz? Nie na którekolwiek z nich rozstrzyga naprawę bez dotykania klucza.

Jeśli wszystkie trzy są w porządku, zastąp klucz przez zatwierdzony proces, zamiast obchodzić go edycją.

Po uwierzytelnieniu partnera

Gdy uwierzytelnianie się powiedzie, następną powierzchnią awarii jest skojarzenie bezpieczeństwa dziecka: propozycje i selektory ruchu. Rotacja klucza, który został już zaakceptowany, nie naprawi awarii dziecka i wydłuża awarię. Odczytaj stan dziecka, potem selektory i chronione zakresy po obu stronach, i dopasuj wskazówki rozwiązywania problemów Cloud VPN do etapu, który faktycznie zawiódł.

Skojarz świeże dzienniki z obu końców dla tej samej pary i tego samego okna. Jedna strona sama wydaje werdykt bez wkładu drugiej, i to jest właśnie niejednoznaczność, która pierwotnie wytworzyła komunikat.

Czego nie należy wnioskować

Nie czytaj komunikatu jako żądania zmiany adresów MAC i nie publikuj klucza współdzielonego, prosząc o pomoc; fragment zawierający klucz wymaga usunięcia klucza, a nie zachowania dziennika. Nie zakładaj też błędu routingu, bo partnerzy, którzy nie mogą się nawzajem osiągnąć, nie dają żadnego porównania uwierzytelniania. I nie uogólniaj udokumentowanego ograniczenia z jednej rodziny produktów na każdą implementację IPsec.

Zapisz zawodzącą parę, stan tunelu przed i po oraz to, który z dwóch warunków zmieniłeś. Taki zapis zamienia następne wystąpienie w pięciominutową kontrolę.