OpenVPN: nieudane uwierzytelnienie HMAC pakietu – która warstwa?

Dwa błędy są zgłaszane tym samym słownictwem i prawie nie mają nic wspólnego. Jeden to pakiet, którego znacznik uwierzytelnienia nie został zweryfikowany; drugi to osoba, której dane logowania odrzucono. Potraktowanie pierwszego jak drugiego wysyła cię na poszukiwanie hasła, które nigdy nie było problemem.

Komunikat nazywa warstwę, a pożyteczna praca polega na ustaleniu której, zanim zastąpisz jakikolwiek materiał. Zestawienie kandydatów obok siebie to najszybszy sposób, by zobaczyć różnicę.

Dwa błędy, które dzielą jedno słowo

Błąd uwierzytelnienia pakietu powstaje podczas przetwarzania ruchu: znacznik lub skrót na odebranym pakiecie nie zgadzał się z tym, co obliczył odbiorca. Odrzucenie konta następuje po przeanalizowaniu wymiany logowania i wskazuje użytkownika, a nie pakiet. Trzeci komunikat, o niemożności znalezienia HMAC w pakiecie przychodzącym, jest znowu inny, bo tam pakiet dotarł całkowicie bez oczekiwanego elementu uwierzytelnienia. Pełny prefiks dziennika mówi, który z trzech masz, a prefiks zwykle jest pierwszą rzeczą usuwaną, gdy błąd wkleja się do zgłoszenia.

Różnica zmienia naprawę. Jeden wymaga zgodnych ustawień kanału, drugi stanu konta, a trzeci profilu, który nie pasuje do osiągniętego odbiornika.

Porównaj, co faktycznie wczytał działający proces

Poprawny plik na dysku nic nie dowodzi o procesie, który wystartował przed jego edycją. Sprawdź wybrany profil, punkt końcowy, z którym się połączył, oraz czy usługa została od tego czasu przeładowana. Potwierdź też, że punkt końcowy należy do profilu, bo inna instancja lub inna usługa może nasłuchiwać tam, gdzie stary plik oczekuje czegoś innego.

Ponowny eksport obsługiwanego profilu z tego samego źródła to tanie porównanie, bo usuwa rozjazd między tym, co uważasz za skonfigurowane, a tym, co klient naprawdę wysyła. Generowanie nowego materiału klucza to znacznie większy krok i pomaga tylko wtedy, gdy obie strony przyjmą go razem. Zastąpienie jednej strony lokalnie odtwarza niezgodność, którą próbowałeś usunąć.

Porównaj kanał sterujący z kanałem danych

Dwa mechanizmy uwierzytelniają różne części połączenia i konfiguruje się je osobno, jak dokumentacja opcji 2.6 opisuje. tls-auth dodaje HMAC do pakietów kanału sterującego i przyjmuje argument kierunku, który u obu partnerów musi być przeciwny, podczas gdy tls-crypt zamiast tego chroni kanał sterujący współdzielonym kluczem. Żaden z nich nie jest własną kontrolą integralności kanału danych. Przy szyfrze danych AEAD ta kontrola jest wbudowana w szyfr, więc osobny auth skrót nie jest używany tak jak przy szyfrze innym niż AEAD.

Co oznacza, że wiersz auth skopiowany z działającego wdrożenia nie-AEAD może być nieistotny we wdrożeniu AEAD, a wdrożenie AEAD nadal może zawieść na kanale sterującym, jeśli tls-auth klucz lub jego kierunek jest błędny. Porównuj każde ustawienie z partnerem, a nie z zapamiętaną konfiguracją.

Porównaj poprawkę z właściwością, której się wyrzekasz

Wyłączenie uwierzytelnienia pakietów wycisza ostrzeżenie i usuwa kontrolę, która znalazła niezgodność, co nie jest tym samym co naprawa profilu. Zapytaj, z jakiej właściwości rezygnujesz i czy projekt się bez niej utrzyma.

Przeczytaj pierwsze istotne zdarzenie po obu stronach, zanim cokolwiek zmienisz, a potem zmień tylko tę niezgodność, którą ono nazywa.

Jeśli następna próba dojdzie do błędu certyfikatu lub logowania, to postęp, a nie regresja: warstwa pakietów już się zgadza, a połączenie poszło dalej. Zapisz ustawienia, które spowodowały zmianę, aby następna osoba odziedziczyła wyjaśnienie, a nie zagadkę.