Naudotojo pridėjimas prie VPN grupės savaime nesuteikia prieigos
Narystė grupėje yra viena sąlyga, o ne leidimas. Pažiūrėkite, ką iš tikrųjų sugretino tinklų sietuvas, perskaitykite priėmimo arba atmetimo įrašą ir išbandykite abu rezultatus.
Paskyra tinkamoje grupėje, prisijungimas pavyko, bet ryšys atmetamas arba nieko naudaus nepasiekia. Įprasta reakcija — pridėti naudotoją prie daugiau grupių, kol kas nors atsileis, ir taip organizacijos suteikia daugiau, nei prašė bilietas. Narystė grupėje yra vienas autorizacijos sprendimo įvestis, niekada pats sprendimas: sietuvas surenka faktus apie sesiją, sugretina juos su tvarkinga politika ir tik tada nusprendžia, ką sesija gali liesti. Jei nepavyko kita sąlyga, grupės keitimas keičia tik jūsų paviršių.
Narystė grupėje yra sąlyga, o ne leidimas
RADIUS grupė ateina kaip autorizacijos atributas, o atributai aprašo sesiją, o ne leidžia ją. Serveris atsako Access-Accept arba Access-Reject; priimdamas jis gali pridėti Filter-Id, Class arba RFC 2868 tunelio atributus, o kitame gale esanti tinklo įranga juos interpretuoja taip, kaip nusprendė gamintojas. Protokole niekas neatvaizduoja grupės į visišką prieigą; tą atvaizdavimą rašo tas, kas nustatė politiką sietuve ar tinklo prieigos serveryje.
Todėl tas pats grupės pavadinimas dviejose sistemose elgiasi skirtingai. Microsoft NPS sudaro tinklo politikas iš sąlygų, apribojimų ir nustatymų bei vertina jas nustatyta tvarka. OpenVPN Access Server turi savo grupių ir prieigos taisyklių modelį, o bendruomenės OpenVPN serveris dažnai visą klausimą perduoda client-connect scenarijui arba client-config-dir failui.
Sprendžia taisyklė, kuri sutapo, o ne grupė, kurios tikėjotės
Dauguma variklių sustoja ties pirmąja atitinkama politika arba ties konkrečiausia. Jei politika 3 atmeta, o politika 7 leidžia, sesija gali nepavykti net nepasiekus taisyklės, kuri būtų ją praleidusi. Tvarka yra tikras nustatymas NPS ir daugumoje tinklo prieigos kontrolės produktų, ir laikui bėgant slenka.
Sąlygos, kurios eina su grupe, yra kita pusė. Įrenginio būsena, autentifikavimo metodas, baigtas MFA, šaltinio tinklas, sertifikato subjektas ar laiko langas gali būti toje pačioje politikoje. Jei vienos trūksta, politika nesutampa, variklis krinta žemyn ir galioja numatytasis atmetimas. Iš naudotojo vietos atrodo, kad grupė ignoruojama; iš variklio vietos grupės net nebuvo klausta.
Katalogo detalės sukuria tą pačią iliuziją. Politika, kuri sutampa pagal Windows grupės narystę, skaito SID žetoną, o ten išvardytos tik saugumo grupės, platinimo grupė niekada nepasirodo. Pirminė grupė laikoma atskirame lauke, ne sąraše, todėl prie jos pritvirtinta politika gali tyliai nepavykti.
Perskaitykite priėmimo arba atmetimo įrašą prieš liesdami grupę
Pirmiausia vienas klausimas: ar užklausa apskritai pasiekė autorizacijos etapą? NPS atsakymas yra įvykių žurnale, kur 6272 žymi suteiktą prieigą, 6273 atmetimą, o 6274 užklausą, kurią serveris išmetė prieš vertindamas politiką. Šie trys skaičiai dalija problemą į tris skirtingus tyrimus, ir tik vienas jų apie grupes.
| 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 |
Kai žurnalas nepasiekiamas, klauskite serverio tiesiogiai ir skaitykite atsakymą. Atsakymas be Filter-Id ir be tunelio atributų reiškia, kad serveris sesiją laiko eiline, o sietuvas taiko savo taisykles. Atsakymas su atributais, kurių vykdymo taškas neįgyvendina, yra kita gedimas: autorizacija praėjo, o įrenginys nepaisė rezultato.
radtest alice 'password' 10.0.0.5 0 testing123Palyginkite grąžintus atributus su tais, kuriuos dokumentuoja sietuvas, o ne su tuo, ką siūlo grupės pavadinimas. Šis palyginimas dažniausiai atskiria politikos problemą nuo vykdymo problemos.
Grupės keitimas neveikia atgaline data
Autorizacijos atributai grąžinami vieną kartą, autentifikuojant sesiją. Sietuvas juos saugo sesijoje ir neskaito katalogo iš naujo kiekvienam paketui, todėl nusistovėjusi sesija veikia ir toliau pašalinus ką nors iš grupės.
Kad pakeitimas įsigaliotų, reikia naujo autorizacijos sprendimo, o ne tik naujų raktų. Jei serveris palaiko RFC 5176 dinaminę autorizaciją, Disconnect-Request arba CoA-Request į UDP 3799 priverčia sesiją perskaičiuoti; kitu atveju atjunkite klientą ir leiskite prisijungti iš naujo. Derybos iš naujo atnaujina tunelio raktus ir paprastai palieka autorizacijos rezultatą.
Taisykite sąlygą, o ne grupę
Kai žinote, kuri politika suveikė, taisymas dažniausiai nedidelis: perkelkite atmetimą, kuris užstoja norimą leidimą, pridėkite trūkstamą įrenginio ar MFA sąlygą į numatytą politiką, arba parašykite siaurą taisyklę vienam ištekliui, o ne pakelkite naudotoją į grupę su dešimčia kitų.
Trumpas ciklas palaiko pakeitimą sąžiningą:
- Atkurkite atmetimą su pradine paskyra ir užrašykite įvykio ID prieš ką nors keisdami.
- Pakeiskite vieną objektą, politikų tvarką, vieną sąlygą arba vieną grupę, ir pažymėkite kurią.
- Atidarykite naują sesiją, patvirtinkite, kad leidimas matomas žurnale ir išteklius tikrai atsidaro.
- Išbandykite naudotoją, kuris vis dar turi būti atmetamas, kad taisymas netyčia neišplėstų politikos.
Jei leidimas teisingas, o išteklius vis tiek neatsidaro, problema persikėlė į maršrutizavimą ar vardų sprendimą tuo metu, kai autorizacija praėjo. Laikykite abu gedimus atskirai ir kitas bilietas užtruks minutes, o ne popietę.