EAP genom en VPN-gateway: vem avslutar metoden
En VPN-gateway avslutar antingen inloggningsuppgifterna eller vidarebefordrar EAP till RADIUS. Vilken väg din klient använder avgör om en ändring av serverpolicyn kan hjälpa.
Supportärenden beskriver en misslyckad VPN-inloggning och en RADIUS-policy som kräver en starkare metod som om det vore samma problem, och det är det inte. Gatewayen tar antingen emot inloggningsuppgifter och vidarebefordrar dem, eller så för den en EAP-konversation mellan klienten och autentiseringsservern. Vilket av dem som sker avgör om en ändring på serversidan alls kan åtgärda något. Läs utbytet innan du redigerar servergruppen.
Två autentiseringsvägar som ser likadana ut i en logg
På den första vägen samlar VPN-gatewayen in ett användarnamn och ett lösenord och skickar en RADIUS Access-Request med ett lösenordsattribut. Autentiseringsservern jämför det med sitt lager och svarar acceptera eller avvisa. Klienten kör aldrig en EAP-metod, eftersom ingenting bad den om det.
På den andra vägen kör klienten och autentiseringsservern EAP-metoden från ände till ände, och gatewayen vidarebefordrar EAP-Message-attribut mellan dem. Gatewayen avslutar fortfarande den yttre RADIUS-konversationen, men metodens logik finns vid de två ändpunkterna.
Båda vägarna ger en rad i loggen som säger att autentiseringen misslyckades. Bara den andra kan påverkas av vilken EAP-metod servern föredrar, och bara den första av hur gatewayen läser lösenordet. Att behandla dem som utbytbara är varför team lägger en dag på att byta servergrupper för en klient som aldrig skulle tala PEAP.
Var metoden faktiskt körs
RFC 3579 definierar genomföringsordningen: NAS:en bär EAP-paket i RADIUS-attribut och behöver ingen metodspecifik kod för varje EAP-typ. Därför kan en gateway stödja PEAP och EAP-TLS utan att implementera någon av dem.
En gateway som skickar in ett lösenord bär inte PEAP, även om backend skulle acceptera PEAP från en annan klient. Att slå på PEAP i serverpolicyn lägger inte till en metod för en klient som aldrig har erbjudit en.
PPP-autentiseringsinställningar hör till PPP-tjänsten. De konfigurerar inte tyst om varje IPsec- eller äldre XAuth-väg som använder samma AAA-server, så en ändring som fungerar för en åtkomsttyp kan lämna den andra orörd.
Vad NAS:en måste stödja
Genomföringen flyttar kravet från metodkod till bärarstöd. Gatewayen måste kunna bära EAP över sitt VPN-protokoll, och RADIUS-klienten på den måste kunna skicka och ta emot EAP-Message-attribut i de aktuella storlekarna.
För IKEv2 är EAP en del av ett definierat autentiseringsflöde, och serverns identitets- och förtroendekontroller kommer från det flödet. En PEAP-etikett lånad från en 802.1X-utrullning överförs inte automatiskt, eftersom förhandlingen runt den är annorlunda.
Klientsidan har också krav. Den måste vara konfigurerad för metoden, lita på det servercertifikat som metoden presenterar och ha inloggningsuppgifter som metoden kan använda. En certifikatbaserad metod utan klientcertifikat misslyckas innan RADIUS ser något, och det är ett etableringsproblem och inte ett serverpolicyproblem.
Läs ett försök innan du ändrar policyn
Fånga ett enda godkänt försök vid gatewayen och vid autentiseringsservern. Leta efter EAP-Message-attribut i RADIUS-begäran. Att de finns säger att genomföringsvägen används; att de saknas pekar på ett utbyte av inloggningsuppgifter.
På en Linux-gateway visar en inspelning på RADIUS-porten vilka attribut som ligger på ledningen:
sudo tcpdump -ni any -X 'udp port 1812' -c 20
Jämför sedan avvisningspunkten. Ett fel vid gatewayen före något RADIUS-paket betyder att klienten och gatewayen inte var överens om metoden. En RADIUS-avvisning med EAP-attribut betyder att ändpunkterna körde metoden och att en av dem avvisade resultatet.
Planera migreringen som en enda ändring från ände till ände
Att byta metod betyder att ändra klientkonfigurationen, gatewayens bärarstöd, serverns metodpolicy och lagret av inloggningsuppgifter tillsammans. Gör det i den ordningen och behåll en fungerande väg tills den nya är bevisad. En ändring bara på serversidan är en gissning, och den bryter oftast de klienter som fungerade. Förbered ändringen på en testidentitet innan du rör gruppen.
Anteckna kombinationen som fungerar: VPN-protokoll, EAP-bärare, peer-metod, servermetod, typ av inloggningsuppgift och serveridentitetskontroll.
Håll administrativ AAA-inloggning åtskild från VPN-autentisering om inte uppgiften uttryckligen omfattar båda. En ändring avsedd för fjärråtkomst bör inte ta bort din möjlighet att administrera enheten som avslutar den.