EAP via een VPN-gateway: wie beëindigt de methode

Helpdesktickets beschrijven een mislukte VPN-login en een RADIUS-beleid dat een sterkere methode eist alsof het hetzelfde probleem is, en dat is het niet. De gateway neemt inloggegevens aan en stuurt ze door, of hij draagt een EAP-gesprek tussen de client en de authenticatieserver. Wat daarvan gebeurt, bepaalt of een wijziging aan de serverkant überhaupt iets kan oplossen. Lees de uitwisseling voordat je de servergroep bewerkt.

Twee authenticatiepaden die er in een log hetzelfde uitzien

Op het eerste pad verzamelt de VPN-gateway een gebruikersnaam en wachtwoord en stuurt een RADIUS Access-Request met een wachtwoordattribuut. De authenticatieserver vergelijkt die met zijn opslag en antwoordt accepteren of weigeren. De client voert nooit een EAP-methode uit, omdat niets dat vroeg.

Op het tweede pad voeren de client en de authenticatieserver de EAP-methode van begin tot eind uit, en de gateway stuurt EAP-Message-attributen tussen hen door. De gateway beëindigt nog steeds het buitenste RADIUS-gesprek, maar de logica van de methode zit aan beide uiteinden.

Beide paden leveren een regel in een log op die zegt dat authenticatie is mislukt. Alleen het tweede kan worden beïnvloed door welke EAP-methode de server verkiest, en alleen het eerste door hoe de gateway het wachtwoord leest. Ze als uitwisselbaar behandelen is hoe teams een dag besteden aan het wijzigen van servergroepen voor een client die nooit PEAP zou spreken.

Waar de methode echt draait

RFC 3579 definieert de doorgeefregeling: de NAS draagt EAP-pakketten in RADIUS-attributen en heeft geen methodespecifieke code nodig voor elk EAP-type. Daarom kan een gateway PEAP en EAP-TLS ondersteunen zonder een van beide te implementeren.

Een gateway die een wachtwoord indient, draagt geen PEAP, ook al zou de backend PEAP van een andere client accepteren. PEAP aanzetten in het serverbeleid voegt geen methode toe aan een client die er nooit een heeft aangeboden.

PPP-authenticatie-instellingen horen bij de PPP-dienst. Ze herconfigureren niet stil elk IPsec- of oud XAuth-pad dat dezelfde AAA-server gebruikt, dus een wijziging die voor het ene toegangstype werkt, kan het andere ongemoeid laten.

Wat de NAS moet ondersteunen

Doorgeven verschuift de eis van methodecode naar dragerondersteuning. De gateway moet EAP over zijn VPN-protocol kunnen dragen, en de RADIUS-client erop moet EAP-Message-attributen van de betrokken groottes kunnen verzenden en ontvangen.

Bij IKEv2 maakt EAP deel uit van een gedefinieerde authenticatiestroom, en de identiteits- en vertrouwenscontroles van de server komen uit die stroom. Een PEAP-label dat uit een 802.1X-implementatie is geleend, wordt niet automatisch overgedragen, omdat de onderhandeling eromheen anders is.

De clientkant heeft ook eisen. Die moet voor de methode zijn geconfigureerd, het servercertificaat vertrouwen dat de methode presenteert, en inloggegevens hebben die de methode kan gebruiken. Een op certificaten gebaseerde methode zonder clientcertificaat mislukt voordat RADIUS iets ziet, en dat is een inrichtingsprobleem en geen serverbeleidsprobleem.

Lees één poging voordat je beleid wijzigt

Leg één goedgekeurde poging vast bij de gateway en bij de authenticatieserver. Zoek naar EAP-Message-attributen in het RADIUS-verzoek. Hun aanwezigheid zegt dat het doorgeefpad in gebruik is; hun afwezigheid wijst op een uitwisseling van inloggegevens.

Op een Linux-gateway laat een opname op de RADIUS-poort zien welke attributen op de draad staan:

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

Vergelijk daarna het afwijzingspunt. Een fout bij de gateway vóór elk RADIUS-pakket betekent dat de client en de gateway het niet eens waren over de methode. Een RADIUS-weigering met EAP-attributen betekent dat de uiteinden de methode hebben uitgevoerd en een van beide het resultaat weigerde.

Plan de migratie als één wijziging van begin tot eind

De methode wijzigen betekent de clientconfiguratie, de dragerondersteuning van de gateway, het methodebeleid van de server en de opslag van inloggegevens samen wijzigen. Doe dat in die volgorde en houd een werkend pad tot het nieuwe bewezen is. Een wijziging alleen aan de serverkant is een gok, en die breekt meestal de clients die werkten. Bereid de wijziging voor op één testidentiteit voordat je de groep aanraakt.

Noteer de combinatie die werkt: VPN-protocol, EAP-drager, methode van de peer, methode van de server, type inloggegevens en identiteitscontrole van de server.

Houd administratieve AAA-login gescheiden van VPN-authenticatie, tenzij de taak beide uitdrukkelijk omvat. Een wijziging bedoeld voor toegang op afstand mag je niet het vermogen ontnemen om het apparaat te beheren dat die beëindigt.