strongSwan EAP: tożsamość IKE a oczekiwana nazwa AAA

Klient strongSwan EAP może zweryfikować dwie nazwy serwera. remote.id obejmuje bramę IKE, a local.aaa_id — serwer EAP; to nie to samo pole.

Uwierzytelnianie EAP przez IKEv2 może wymagać od klienta zweryfikowania dwóch różnych nazw serwera w jednym połączeniu. Brama kończąca IKE przedstawia jedną tożsamość, a zaplecze EAP kończące wewnętrzną wymianę TLS może przedstawić inną. W strongSwan mieszkają one w różnych blokach konfiguracji, a nazwa w niewłaściwym bloku daje błąd, który wygląda jak problem z certyfikatem. Właśnie odczytanie, która weryfikacja się nie powiodła, wskazuje, który blok zmienić.

Jedno połączenie, dwie tożsamości serwera

Pierwsza tożsamość należy do wymiany IKE. Klient wybiera adres i oczekuje, że druga strona udowodni określoną tożsamość, zwykle nazwę z certyfikatu bramy.

Druga należy do EAP. Z PEAP lub TTLS klient buduje tunel TLS do serwera uwierzytelniania wewnątrz IKE SA, i ten wewnętrzny serwer przedstawia własny certyfikat. Gdy zaplecze jest osobnym hostem, jego nazwa różni się od nazwy bramy. Klient, który sprawdza tylko pierwszą nazwę, akceptuje wszystko, co twierdzi druga. A klient skonfigurowany z jedną nazwą w obu miejscach zawodzi, gdy tylko te dwie naprawdę się różnią.

Obie nazwy pochodzą z konfiguracji operatora, a nie z certyfikatu, który usuwa błąd. Zapytanie operatora o szczegóły wdrożenia jest szybsze niż zgadywanie dwóch nazw hostów.

Które pole należy do której warstwy

W swanctl adres i tożsamość IKE to osobne ustawienia, a tożsamość EAP jest trzecia.

Adres zdalny wybiera, dokąd trafiają pakiety, a tożsamość zdalna mówi, co musi udowodnić druga strona. Oczekiwanie EAP jest zapisywane pod blokiem local, ponieważ opisuje wymianę EAP tego klienta, a nie zachowanie IKE drugiej strony. Właśnie to umiejscowienie jest czytane błędnie. Nazwa stoi w konfiguracji klienta, opisując serwer, i dlatego wygląda na umieszczoną nie tam.

connections {
    office {
        remote_addrs = vpn.example.com
        local {
            auth = eap-peap
            aaa_id = auth.example.com
        }
        remote {
            auth = pubkey
            id = vpn.example.com
        }
    }
}

Ten fragment nie jest pełnym połączeniem; materiał zaufania, dane uwierzytelniające i zasady połączeń podrzędnych nadal muszą być obecne. Skopiowanie go dosłownie do działającego pliku zastąpiłoby ustawienia, których jeszcze potrzebujesz.

Dlaczego aaa_id mieszka pod local

Blok local opisuje, co ta strona robi podczas uwierzytelniania, w tym metodę, której użyje, oraz tożsamość, której oczekuje od drugiej strony dla tej metody. Nic w nim nie twierdzi, że serwer AAA działa na tej samej maszynie.

Wartość domyślna zaostrza pułapkę. Gdy nie ustawiono jawnej wartości, oczekiwana tożsamość AAA podąża za tożsamością zdalną, więc wdrożenie z jedną nazwą działa i ukrywa różnicę. Jawna wartość ma znaczenie tylko wtedy, gdy wdrożenie EAP naprawdę kończy się gdzie indziej. Ustawienie jej na inną nazwę bez tego powodu tworzy błąd, którego operator nie może odtworzyć. Przeczytaj wdrożenie, zanim wymyślisz drugą nazwę.

Utrzymuj wartość identyczną z tym, co naprawdę twierdzi certyfikat zaplecza, łącznie z formą nazwy. Kropka na końcu lub wildcard, który nie obejmuje hosta, wystarczą, by sprawdzenie się nie powiodło.

Interfejsy, które nie potrafią wyrazić podziału

Profil NetworkManager nie jest tym samym interfejsem konfiguracji co swanctl. Wtyczka za nim udostępnia węższy zestaw kontroli tożsamości, a to, które istnieją, zależy od zainstalowanej wersji.

Ma to znaczenie, gdy wdrożenie naprawdę potrzebuje dwóch nazw. Pole oznaczone jako tożsamość serwera może skonfigurować jedną warstwę, a nie drugą, więc profil może wyglądać poprawnie i mimo to zawieść wewnętrzne sprawdzenie. Sprawdź, co obsługuje zainstalowana wtyczka, zanim założysz, że profil potrafi wyrazić ten układ. Jeśli nie potrafi, wybór należy do operatora: inna ścieżka dostarczania albo poprawiony projekt tożsamości serwera. Osłabienie PEAP lub akceptacja dowolnej nazwy zmienia politykę uwierzytelniania zamiast ją naprawiać.

Alternatywa nie jest czymś, co się wymyśla na kliencie. Poproś o obsługiwany układ na piśmie, a potem zachowaj tę odpowiedź razem z profilem.

Odróżnij niezgodność tożsamości od wygasłego certyfikatu

Niezgodność nazwy i wygasły certyfikat to różne błędy, a dziennik je rozróżnia. Przeczytaj komunikat, zanim zdecydujesz, które pole zmienić.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 50 --no-pager

Ustawienie zamierzonej tożsamości AAA nie odnawia certyfikatu ani nie buduje zaufania do jego wystawcy, a odnowienie certyfikatu nie poprawia błędnej oczekiwanej nazwy. Przeczytaj, która weryfikacja się nie powiodła, zanim zmienisz kolejne pole tożsamości. Następnie przeładuj konfigurację i potwierdź, że wczytane połączenie pokazuje ustawioną wartość, bo zmieniony plik, który nigdy nie został wczytany, nie zmienia niczego. Zapisz obie nazwy i ich warstwy w notatkach wdrożeniowych.

Powiązane artykuły