Käyttäjän lisääminen VPN-ryhmään ei yksinään anna pääsyä
Ryhmäjäsenyys on yksi ehto, ei käyttöoikeus. Katso, mitä yhdyskäytävä todella sovitti, lue hyväksyntä- tai hylkäystietue ja testaa molemmat lopputulokset.
Laitoit tilin oikeaan ryhmään, kirjautuminen onnistui, ja yhteys evätään silti, tai se muodostuu eikä tavoita mitään hyödyllistä. Tavallinen reaktio on lisätä käyttäjä useampiin ryhmiin, kunnes jokin antaa periksi, ja niin organisaatiot myöntävät paljon enemmän kuin tiketti pyysi. Ryhmäjäsenyys on yksi syöte valtuutuspäätökseen, ei koskaan päätös itse: yhdyskäytävä kerää muutaman tosiasian istunnosta, sovittaa ne järjestettyyn käytäntöön ja päättää vasta sitten, mihin istunto saa koskea. Jos jokin muu ehto epäonnistui, ryhmän muuttaminen ei muuta mitään paitsi altistustasi.
Ryhmäjäsenyys on ehto, ei käyttöoikeus
RADIUSissa ryhmä saapuu valtuutusattribuuttina, ja attribuutit kuvaavat istuntoa sen sijaan että myöntäisivät sen. Palvelin vastaa Access-Accept tai Access-Reject; hyväksyessään se voi liittää Filter-Id:n, Classin tai RFC 2868:n tunneliatribuutit, ja toisessa päässä oleva verkkolaite tulkitsee ne valmistajan päätöksen mukaan. Mikään protokollassa ei yhdistä ryhmää täyteen pääsyyn; sen yhdistämisen kirjoittaa se, joka määritti käytännön yhdyskäytävälle tai verkon käyttöoikeuspalvelimelle, ja se voi olla kapea kuin yksi isäntä.
Siksi sama ryhmän nimi käyttäytyy eri tavoin kahdessa järjestelmässä. Microsoft NPS kokoaa verkkokäytännöt ehdoista, rajoituksista ja asetuksista ja arvioi ne määrätyssä järjestyksessä. OpenVPN Access Serverilla on oma ryhmä- ja käyttösääntömallinsa, kun taas yhteisön OpenVPN-palvelin usein siirtää koko kysymyksen client-connect-skriptille tai client-config-dir-tiedostolle. Jokainen kuluttaa ryhmän; mikään ei jaa toisen prioriteettilogiikkaa.
Ratkaisee sääntö, joka osui, ei ryhmä, jota odotit
Useimmat moottorit pysähtyvät ensimmäiseen osuvaan käytäntöön tai kaikkein tarkimpaan. Jos käytäntö 3 hylkää ja käytäntö 7 sallii, istunto voi epäonnistua koskaan saavuttamatta sääntöä, joka olisi päästänyt sen läpi. Järjestys on todellinen asetus NPS:ssä ja useimmissa verkon käytönvalvontatuotteissa, ja se liukuu vuosien myötä.
Ryhmän mukana kulkevat ehdot ovat toinen puoli. Laitteen tila, todennusmenetelmä, suoritettu MFA, lähiverkko, varmenteen kohde tai aikaväli voivat olla samassa käytännössä. Kun yksi niistä ei täyty, käytäntö ei osu, moottori putoaa läpi ja oletushylkäys astuu voimaan. Käyttäjän istuimelta näyttää siltä kuin ryhmä jätettäisiin huomiotta; moottorin istuimelta ryhmältä ei kysytty lainkaan.
Hakemiston yksityiskohdat tuottavat saman harhan. Windows-ryhmäjäsenyyteen osuva käytäntö lukee käyttäjän tokenin SIDit, ja siellä luetellaan vain suojausryhmät, jakeluryhmä ei koskaan ilmesty. Ensisijainen ryhmä kulkee omassa kentässään eikä luettelossa, joten siihen kiinnitetty käytäntö voi epäonnistua äänettömästi.
Lue hyväksyntä- tai hylkäystietue ennen kuin kosket ryhmään
Kysy ensin yhtä asiaa: pääsikö pyyntö ylipäätään valtuutusvaiheeseen? NPS:ssä vastaus on tapahtumalokissa, jossa 6272 kirjaa myönnetyn pääsyn, 6273 hylkäyksen ja 6274 pyynnön, jonka palvelin hylkäsi ennen käytännön arviointia. Ne kolme numeroa jakavat ongelman kolmeen eri tutkintaan, ja vain yksi niistä koskee ryhmiä.
| What the record shows | What it means | Where to look next |
|---|---|---|
| 6272, access granted | Authentication and authorization both succeeded | Routes, split tunnel, DNS, per-resource rules |
| 6273, access denied | A policy matched and denied, or nothing matched and the default denied | The conditions of the policy that fired, in order |
| 6274, request discarded | The request never reached authorization | Shared secret, NAS client entry, proxy chain, malformed attributes |
Kun loki ei ole ulottuvilla, kysy palvelimelta suoraan ja lue, mitä se palauttaa. Vastaus ilman Filter-Id:tä ja ilman tunneliatribuutteja kertoo, että palvelin pitää istuntoa tavallisena ja yhdyskäytävä soveltaa omia sääntöjään. Vastaus, jossa on attribuutteja, joita toimeenpanopiste ei toteuta, on toinen vika: valtuutus meni läpi ja laite jätti tuloksen huomiotta.
radtest alice 'password' 10.0.0.5 0 testing123Vertaa palautettuja attribuutteja niihin, jotka yhdyskäytävä dokumentoi, älä siihen, mitä ryhmän nimi vihjaa. Tämä vertailu erottaa yleensä käytäntöongelman toimeenpano-ongelmasta.
Ryhmän muutos ei ole taannehtiva
Valtuutusattribuutit palautetaan kerran, kun istunto todennetaan. Yhdyskäytävä tallentaa ne istuntoon eikä lue hakemistoa uudelleen joka paketille, siksi vakiintunut istunto toimii edelleen, kun poistat jonkun ryhmästä, ja uusi voi epäonnistua vanhan vielä toimiessa.
Jotta muutos astuisi voimaan, tarvitaan uusi valtuutuspäätös, ei vain tuoreet avaimet. Jos palvelin tukee RFC 5176:n dynaamista valtuutusta, Disconnect-Request tai CoA-Request UDP-porttiin 3799 pakottaa istunnon uudelleenarviointiin; muuten katkaise asiakas ja anna sen yhdistää uudelleen. Uudelleenneuvottelu päivittää tunneliavaimet ja jättää valtuutustuloksen yleensä ennalleen.
Korjaa ehto, älä ryhmää
Kun tiedät, mikä käytäntö laukesi, korjaus on yleensä pieni: järjestä uudelleen hylkäys, joka varjostaa aiottua sallintaa, lisää puuttuva laite- tai MFA-ehto käytäntöön, jota tarkoitit, tai kirjoita kapea sääntö yhdelle resurssille sen sijaan että nostat käyttäjän ryhmään, joka kantaa kymmenen muuta.
Lyhyt silmukka pitää muutoksen rehellisenä:
- Toista hylkäys alkuperäisellä tilillä ja kirjoita tapahtuman ID muistiin ennen kuin muutat mitään.
- Muuta yhtä objektia, käytäntöjärjestystä, yhtä ehtoa tai yhtä ryhmää, ja kirjaa mikä.
- Avaa uusi istunto, vahvista että myönnytys näkyy lokissa ja että resurssi todella avautuu.
- Testaa käyttäjää, joka pitäisi yhä hylätä, ettei korjaus vahingossa laajentanut käytäntöä.
Jos myönnytys on oikein eikä resurssi silti avaudu, ongelma on siirtynyt reititykseen tai nimien selvitykseen sillä hetkellä, kun valtuutus meni läpi. Pidä ne kaksi vikaa erillään, niin seuraava tiketti vie minuutteja eikä iltapäivää.