Aldoni uzanton al VPN-grupo mem ne donas aliron
Grupa membreco estas unu kondiĉo, ne permeso. Rigardu, kion la enirejo efektive kongruigis, legu la akceptan aŭ malakceptan rikordon, kaj testu ambaŭ rezultojn.
Vi metis la konton en la ĝustan grupon, la ensaluto sukcesis, kaj la konekto ankoraŭ estas rifuzata, aŭ ĝi konektiĝas kaj atingas nenion utilan. La kutima reago estas aldoni la uzanton al pliaj grupoj ĝis io cedos, kaj tiel organizoj donas multe pli ol la bileto petis. Grupa membreco estas unu enigo en la rajtigan decidon, neniam la decido mem: la enirejo kolektas kelkajn faktojn pri la seanco, kongruigas ilin kun ordigita politiko kaj nur tiam decidas, kion la seanco rajtas tuŝi. Se alia kondiĉo malsukcesis, ŝanĝi la grupon ŝanĝas nenion krom via elmetiĝo.
Grupa membreco estas kondiĉo, ne permeso
En RADIUS la grupo alvenas kiel rajtiga atributo, kaj atributoj priskribas la seancos anstataŭ permesi ĝin. La servilo respondas per Access-Accept aŭ Access-Reject; ĉe akcepto ĝi povas aldoni Filter-Id, Class aŭ la tunelajn atributojn el RFC 2868, kaj la reta aparataro ĉe la alia flanko interpretas ilin laŭ la decido de la fabrikanto. Nenio en la protokolo mapas grupon al plena aliro; tiun mapadon skribas tiu, kiu agordis la politikon sur la enirejo aŭ la retalira servilo, kaj ĝi povas esti same mallarĝa kiel unu gastiganto.
Tial identa grupa nomo kondutas malsame sur du sistemoj. Microsoft NPS kunmetas retajn politikojn el kondiĉoj, limigoj kaj agordoj kaj taksas ilin laŭ difinita ordo. OpenVPN Access Server havas sian propran modelon de grupoj kaj aliraj reguloj, dum komunuma OpenVPN-servilo ofte transdonas la tutan demandon al client-connect-skripto aŭ al dosiero en client-config-dir. Ĉiu konsumas grupon; neniu dividas la prioritatologikon de la alia.
Decidas la regulo, kiu kongruis, ne la grupo, kiun vi atendis
Plej multaj motoroj haltas ĉe la unua kongrua politiko aŭ ĉe la plej specifa. Se politiko 3 rifuzas kaj politiko 7 permesas, la seanco povas malsukcesi sen iam atingi la regulon, kiu lasus ĝin trairi. La ordo estas reala agordo sur NPS kaj plej multaj retaliraj kontrolproduktoj, kaj ĝi moviĝas dum jaroj.
La kondiĉoj, kiuj iras kun la grupo, estas la alia duono. Aparata stato, aŭtentiga metodo, finita MFA, fonta reto, subjekto de atestilo aŭ tempofenestro povas esti en la sama politiko. Kiam unu mankas, la politiko ne kongruas, la motoro falas kaj validas la implicita rifuzo. El la sidloko de la uzanto ŝajnas, ke la grupo estas ignorata; el la sidloko de la motoro la grupo neniam estis demandita.
Detaloj de la dosierujo kreas la saman iluzion. Politiko, kiu kongruas laŭ membreco en Windows-grupoj, legas la SID-ojn en la ĵetono de la uzanto, kaj tie estas listigitaj nur sekurecaj grupoj, distribua grupo neniam aperas. La ĉefa grupo portiĝas en propra kampo anstataŭ en la listo, do politiko fiksita al ĝi povas silente malsukcesi.
Legu la akceptan aŭ malakceptan rikordon antaŭ ol tuŝi grupon
Demandu unue unu aferon: ĉu la peto entute atingis la rajtigan stadion? Sur NPS la respondo estas en la eventprotokolo, kie 6272 registras donitan aliron, 6273 rifuzon kaj 6274 peton, kiun la servilo forĵetis antaŭ ol taksi politikon. Tiuj tri numeroj dividas la problemon en tri malsamajn esplorojn, kaj nur unu temas pri grupoj.
| 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 |
Kiam la protokolo ne atingeblas, demandu la servilon rekte kaj legu, kion ĝi redonas. Respondo sen Filter-Id kaj sen tunelaj atributoj signifas, ke la servilo konsideras la seancos ordinara kaj la enirejo aplikas proprajn regulojn. Respondo kun atributoj, kiujn la plenum-punkto ne realigas, estas alia fuŝo: la rajtigo pasis kaj la aparato ignoris la rezulton.
radtest alice 'password' 10.0.0.5 0 testing123Komparu la redonitajn atributojn kun tiuj, kiujn la enirejo dokumentas, ne kun tio, kion sugestas la grupa nomo. Tiu komparo kutime apartigas politikan problemon de plenumproblemo.
Ŝanĝo de grupo ne efikas retrospektive
Rajtigaj atributoj redoniĝas unufoje, kiam la seanco aŭtentiĝas. La enirejo konservas ilin ĉe la seanco kaj ne relegas la dosierujon por ĉiu paketo, tial establita seanco daŭre funkcias post kiam vi forigas iun el grupo, dum nova povas malsukcesi.
Por ke la ŝanĝo efiku, vi bezonas novan rajtigan decidon, ne nur freŝajn ŝlosilojn. Kie la servilo subtenas dinamiĉan rajtigon RFC 5176, Disconnect-Request aŭ CoA-Request al UDP 3799 devigas la seancos esti retaksata; alie malkonektu la klienton kaj lasu ĝin rekonekti. Reinterkonsento renovigas la tunelajn ŝlosilojn kaj kutime lasas la rajtigan rezulton netuŝita.
Riparu la kondiĉon, ne la grupon
Kiam vi scias, kiu politiko ekagis, la riparo kutime malgrandas: reordigu rifuzon, kiu ombrumas la celatan permeson, aldonu la mankan aparatan aŭ MFA-kondiĉon al la politiko, kiun vi celis, aŭ skribu mallarĝan regulon por la unu rimedo anstataŭ promocii la uzanton en grupon, kiu portas dek aliajn.
Mallonga buklo tenas la ŝanĝon honesta:
- Reproduktu la rifuzon kun la originala konto kaj notu la eventan ID antaŭ ol ŝanĝi ion.
- Ŝanĝu unu objekton, politikan ordon, unu kondiĉon aŭ unu grupon, kaj notu kiun.
- Malfermu novan seancos, konfirmu ke la permeso aperas en la protokolo kaj ke la rimedo vere malfermiĝas.
- Testu uzanton, kiu ankoraŭ devus esti rifuzata, por ke la riparo ne hazarde larĝigis la politikon.
Se la permeso estas ĝusta kaj la rimedo tamen ne malfermiĝas, la problemo translokiĝis al enkursigado aŭ nomrezolucio en la momento, kiam la rajtigo pasis. Tenu la du fuŝojn aparte kaj la sekva bileto daŭros minutojn, ne posttagmezon.