Probleemoplossing voor webverificatie op een draadloze LAN-controller (WLC)

Downloadopties

PDF (650.1 KB)
Met Adobe Reader op diverse apparaten bekijken
ePub (505.9 KB)
Bekijken in diverse apps op iPhone, iPad, Android, Sony Reader of Windows Phone
Mobi (Kindle) (404.3 KB)
Op Kindle-apparaat of via Kindle-app op meerdere apparaten bekijken

Bijgewerkt:20 maart 2024

Document-id:108501

Inclusief taalgebruik

De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.

Over deze vertaling

Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.

Inhoud

Inleiding

Voorwaarden

Vereisten

Gebruikte componenten

Verwante producten

Web verificatie op WLC’s

Probleemoplossing voor webverificatie

Gerelateerde informatie

Inleiding

Dit document beschrijft tips om problemen met webverificatie op te lossen in een Wireless LAN Controller (WLC)-omgeving.

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

Beheer en provisioning van draadloze access points (CAPWAP).
Hoe u Lichtgewicht access point (LAP) en WLC kunt configureren voor basisbediening.
Basiskennis van webverificatie en hoe webverificatie op WLC’s te configureren.

Raadpleeg voor informatie over het configureren van webverificatie op WLC’s het configuratievoorbeeld van de draadloze LAN-controller-webverificatie.

Gebruikte componenten

De informatie in dit document is gebaseerd op een WLC 5500 die firmware versie 8.3.121 uitvoert.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Verwante producten

Dit document kan ook met deze hardware worden gebruikt:

Cisco 5500 Series wireless controllers
Cisco 8500 Series wireless controllers
Cisco 2500 Series wireless controllers
Cisco Aironet 3500 Series WLAN-controller
Cisco Aironet 4000 Series draadloze LAN-controller
Cisco Flex 7500 Series draadloze controllers
Cisco draadloze servicesmodule 2 (WiSM2)

Web verificatie op WLC’s

Web authenticatie is een Layer 3-beveiligingsfunctie die ervoor zorgt dat de controller geen IP-verkeer toestaat, behalve DHCP-gerelateerde pakketten/Domain Name System (DNS)-gerelateerde pakketten, van een bepaalde client totdat die client op de juiste wijze een geldige gebruikersnaam en wachtwoord heeft geleverd, met uitzondering van verkeer dat is toegestaan via een pre-auth toegangscontrolelijst (ACL). Web authenticatie is het enige beveiligingsbeleid dat de client in staat stelt om een IP-adres te krijgen voor verificatie. Het is een eenvoudige authenticatiemethode zonder de noodzaak van een supplicant of client utility. Web verificatie kan lokaal op een WLC of via een RADIUS-server worden uitgevoerd. Web authenticatie wordt meestal gebruikt door klanten die een gast-toegangsnetwerk willen implementeren.

Web authenticatie begint wanneer de controller het eerste TCP HTTP (poort 80) GET pakket van de client onderschept. Opdat de webbrowser van de client zo ver kan komen, moet de client eerst een IP-adres verkrijgen en een vertaling van de URL naar het IP-adres (DNS-resolutie) voor de webbrowser uitvoeren. Dit laat de webbrowser weten welk IP-adres om de HTTP GET te verzenden.

Wanneer webverificatie is ingesteld op het WLAN, blokkeert de controller al het verkeer (totdat het verificatieproces is voltooid) vanaf de client, behalve voor DHCP- en DNS-verkeer. Wanneer de client de eerste HTTP GET naar TCP-poort 80 verstuurt, wordt de client door de controller omgeleid naar https://192.0.2.1/login.html (als dit de virtuele IP is die is geconfigureerd) voor verwerking. Dit proces leidt uiteindelijk tot de login webpagina.

Opmerking: Wanneer u een externe webserver gebruikt voor webverificatie, hebben WLC-platforms een pre-authenticatie ACL nodig voor de externe webserver.

In deze sectie wordt de omleiding van de webverificatie in detail uitgelegd.

Web-autorisatieproces

U opent de webbrowser en typt een URL in, bijvoorbeeld http://www.example.com. De client stuurt een DNS-verzoek voor deze URL om het IP voor de bestemming te krijgen. WLC geeft de DNS-aanvraag door aan de DNS-server en DNS-server reageert met een DNS-antwoord, dat het IP-adres van de bestemming www.example.com bevat, dat op zijn beurt wordt doorgestuurd naar de draadloze clients.
De client probeert vervolgens een TCP verbinding te openen met het IP-adres van de bestemming. Het stuurt een TCP/SYN-pakket naar het IP-adres van www.example.com.
De WLC heeft regels geconfigureerd voor de client en kan daarom fungeren als een proxy voor www.example.com. Het stuurt een TCP SYN-ACK pakket terug naar de client met bron als IP-adres van www.example.com. De client stuurt een TCP-ACK-pakket terug om de driewegs TCP-handdruk te voltooien en de TCP-verbinding is volledig tot stand gebracht.
De client stuurt een HTTP GET-pakket naar www.example.com. De WLC onderschept dit pakket en verstuurt het voor omleidingsbehandeling. De HTTP applicatie gateway bereidt een HTML body voor en verstuurt het terug als het antwoord op de HTTP GET gevraagd door de client. Deze HTML maakt de client naar de standaard webpagina URL van de WLC, bijvoorbeeld http://<Virtual-Server-IP>/login.html.
De client sluit de TCP-verbinding met het IP-adres, bijvoorbeeld www.example.com.
De client wil nu naar http://<virtualip>/login.html gaan en probeert dus een TCP-verbinding te openen met het virtuele IP-adres van de WLC. Het verzendt een TCP SYN-pakket voor 192.0.2.1 (wat hier ons virtuele IP is) naar de WLC.
De WLC reageert met een TCP SYN-ACK en de client stuurt een TCP-ACK terug naar de WLC om de handdruk te voltooien.
De client stuurt een HTTP GET voor /login.html bestemd voor 192.0.2.1 om de inlogpagina aan te vragen.
Dit verzoek is toegestaan tot de webserver van de WLC en de server reageert terug met de standaard login pagina. De client ontvangt de inlogpagina in het browservenster waar de gebruiker kan doorgaan en inloggen.

In dit voorbeeld is het IP-adres van de client 192.168.68.94. De client loste de URL naar de webserver waartoe ze toegang had, 10.1.0.13. Zoals u kunt zien, deed de client de drieweg-handdruk om de TCP-verbinding op te starten en stuurde vervolgens een HTTP GET-pakket dat begon met pakket 96 (00 is het HTTP-pakket). Dit werd niet geactiveerd door de gebruiker, maar was het besturingssysteem geautomatiseerde portal detectie triggers (zoals we kunnen raden via de gevraagde URL). De controller onderschept de pakketten en antwoordt met code 200. Het code 200-pakket bevat een doorverwijzing naar een URL:

<HTML><HEAD>
<TITLE> Web Authentication Redirect</TITLE>
<META http-equiv="Cache-control" content="no-cache">
<META http-equiv="Pragma" content="no-cache">
<META http-equiv="Expires" content="-1">
<META http-equiv="refresh" content="1; URL=https://192.0.2.1/login.html?redirect=http://captive.apple.com/hotspot-detect.html">
</HEAD></HTML>

Het sluit dan de TCP verbinding door de handdruk met drie richtingen.

De client start vervolgens de HTTPS-verbinding naar de doorgestuurde URL die het verstuurt naar 192.0.2.1, wat het virtuele IP-adres is van de controller. De client moet het servercertificaat valideren of negeren om de SSL-tunnel te kunnen openen. In dit geval is het een zelfondertekend certificaat, dus de klant negeerde het. De login webpagina wordt verzonden door deze SSL-tunnel. Packet 112 begint met de transacties.

Packet 112 begint met de transacties

U hebt de optie om de domeinnaam voor het virtuele IP adres van de WLC te configureren. Als u de domeinnaam voor het virtuele IP-adres configureert, wordt deze domeinnaam in het HTTP OK-pakket van de controller teruggestuurd naar het HTTP GET-pakket van de client. Vervolgens moet u een DNS-resolutie uitvoeren voor deze domeinnaam. Zodra het een IP-adres uit de DNS-resolutie krijgt, probeert het een TCP-sessie te openen met dat IP-adres, dat een IP-adres is dat op een virtuele interface van de controller is geconfigureerd.

Uiteindelijk wordt de webpagina door de tunnel doorgegeven aan de client en stuurt de gebruiker de gebruikersnaam/het wachtwoord terug via de SSL-tunnel (Secure Sockets Layer).

Web authenticatie wordt uitgevoerd via een van deze drie methoden:

Gebruik een interne webpagina (standaard).
Gebruik een aangepaste inlogpagina.
Gebruik een inlogpagina van een externe webserver.

Opmerkingen:
- De aangepaste web authenticatie bundel heeft een limiet van maximaal 30 tekens voor bestandsnamen. Zorg ervoor dat geen bestandsnamen binnen de bundel groter zijn dan 30 tekens.

- Vanaf WLC release 7.0, als webverificatie is ingeschakeld op het WLAN en u ook CPU ACL-regels hebt, nemen de op client gebaseerde webverificatieregels altijd een hogere prioriteit zolang de client niet is geverifieerd in de staat WebAuth_Reqd. Zodra de client naar de Run-status gaat, worden de CPU ACL-regels toegepast.

- Als CPU ACL’s in de WLC zijn ingeschakeld, is daarom in deze omstandigheden een acceptatieregel voor de virtuele interface IP vereist (in ELKE richting):
- Wanneer de CPU ACL geen regel ALLE toestaan voor beide richtingen heeft.
- Als er een voorkeursregel voor het toestaan van ALL bestaat, maar er ook een DENY-regel voor haven 443 of 80 bestaat.

- De acceptatieregel voor het virtuele IP moet zijn voor TCP-protocol en poort 80 als SecureWeb is uitgeschakeld, of poort 443 als SecureWeb is ingeschakeld. Dit is nodig om de client toegang te geven tot het virtuele IP-adres na succesvolle verificatie wanneer CPU-ACL’s zijn geïnstalleerd.