EAP přes VPN bránu: kdo ukončuje metodu

Tikety podpory popisují neúspěšné přihlášení VPN a politiku RADIUS vyžadující silnější metodu, jako by šlo o stejný problém, ale není. Brána buď přijme údaje a předá je dál, nebo vede rozhovor EAP mezi klientem a autentizačním serverem. Co z toho nastane, rozhoduje, zda změna na straně serveru může vůbec něco opravit. Přečtěte si výměnu, než upravíte skupinu serveru.

Dvě autentizační cesty, které v logu vypadají stejně

V první cestě VPN brána shromáždí jméno a heslo a pošle RADIUS Access-Request s atributem hesla. Autentizační server jej porovná se svým úložištěm a odpoví přijetím nebo odmítnutím. Klient nikdy nespustí metodu EAP, protože ho o to nic nepožádalo.

Ve druhé cestě klient a autentizační server spouštějí metodu EAP od začátku do konce a brána mezi nimi předává atributy EAP-Message. Brána stále ukončuje vnější rozhovor RADIUS, ale logika metody žije na obou koncích.

Obě cesty vytvoří v logu řádek, že autentizace selhala. Jen druhou může ovlivnit, kterou metodu EAP server preferuje, a jen první to, jak brána čte heslo. Považovat je za zaměnitelné znamená, že týmy stráví den změnou skupin serveru pro klienta, který nikdy neměl mluvit PEAP.

Kde metoda skutečně běží

RFC 3579 definuje průchozí uspořádání: NAS nese pakety EAP v atributech RADIUS a nepotřebuje kód specifický pro každý typ EAP. Proto brána může podporovat PEAP i EAP-TLS, aniž by kteroukoli implementovala.

Brána, která předává heslo, nenese PEAP, i kdyby backend přijal PEAP od jiného klienta. Zapnutí PEAP v politice serveru nepřidá metodu klientovi, který ji nikdy nenabídl.

Nastavení autentizace PPP patří službě PPP. Nenakonfigurují tiše každou cestu IPsec nebo staršího XAuth, která používá stejný server AAA, takže změna fungující pro jeden typ přístupu může druhý nechat nedotčený.

Co musí NAS podporovat

Průchod přesouvá požadavek z kódu metody na podporu nosiče. Brána musí umět nést EAP přes svůj protokol VPN a její klient RADIUS musí umět odesílat a přijímat atributy EAP-Message příslušných velikostí.

U IKEv2 je EAP součástí definovaného autentizačního toku a kontroly identity a důvěry serveru pocházejí z něj. Štítek PEAP vypůjčený z nasazení 802.1X se nepřenáší automaticky, protože vyjednávání kolem něj je jiné.

Strana klienta má také požadavky. Musí být nakonfigurována pro metodu, důvěřovat certifikátu serveru, který metoda předkládá, a mít údaje, které metoda umí použít. Metoda založená na certifikátu bez klientského certifikátu selže dřív, než RADIUS něco uvidí, což je problém zajištění, ne politiky serveru.

Přečtěte si jeden pokus před změnou politiky

Zachyťte jeden schválený pokus na bráně a na autentizačním serveru. Hledejte atributy EAP-Message v požadavku RADIUS. Jejich přítomnost říká, že se používá průchozí cesta; nepřítomnost ukazuje na výměnu údajů.

Na bráně Linux zachycení na portu RADIUS ukáže, které atributy jsou na drátě:

sudo tcpdump -ni any -X 'udp port 1812' -c 20

Pak porovnejte bod odmítnutí. Selhání na bráně před jakýmkoli paketem RADIUS znamená, že klient a brána se na metodě neshodli. Odmítnutí RADIUS s atributy EAP znamená, že konce metodu spustily a jeden z nich výsledek odmítl.

Naplánujte migraci jako jednu změnu od začátku do konce

Změna metody znamená změnit současně konfiguraci klienta, podporu nosiče na bráně, politiku metody na serveru a úložiště údajů. Dělejte to v tomto pořadí a udržujte funkční cestu, dokud se nová neprokáže. Změna jen na straně serveru je dohad a obvykle rozbije klienty, kteří fungovali. Připravte změnu na jedné testovací identitě, než se dotknete skupiny.

Zapište kombinaci, která funguje: protokol VPN, nosič EAP, metoda protějšku, metoda serveru, typ údajů a kontrola identity serveru.

Udržujte administrativní přihlášení AAA oddělené od autentizace VPN, pokud úkol výslovně nezahrnuje obojí. Změna určená pro vzdálený přístup by vám neměla vzít možnost spravovat zařízení, které ji ukončuje.