AWS Client VPN: sisselogimine õnnestub, aga alamvõrku ei saa
Edukas AWS Client VPN-i sisselogimine ei anna õigust igale alamvõrgule. Enne juurdepääsu laiendamist kontrollige grupi väärtust ja kõige täpsemat sihtkoha reeglit.
Teie klient näitab Connected, sertifikaat on kehtiv ja intraneti leht lõpeb ikka ajalõpuga. See vahe on peaaegu kunagi autentimine. AWS Client VPN autoriseerib sihtkohad sisselogimisest eraldi ning tavaliselt on kaks põhjust: grupiväärtus, mis ei vasta identiteedipakkuja saadetule, ja täpsem sihtkoha reegel, mis võidab laia reegli. Mõlemad on lõpp-punkti konfiguratsioonis näha, kui tead, kuhu vaadata.
Sisselogimine õnnestus; reegel ei klappinud
Autentimine vastab, kes on kasutaja. Autoriseerimisreeglid vastavad, millistele võrguprefiksitele see identiteet pääseb. Kasutaja võib esimese läbida ja teise juures ebaõnnestuda ning klient annab teile vaid ühenduse, mis püsib, samal ajal kui iga päring lõpeb ajalõpuga.
Alustage kinnitades, et lõpp-punktil on autoriseerimisreegel, mille sihtkoht sisaldab ebaõnnestuvat aadressi. Kui sobivat reeglit pole, käitub ühendus õigesti; puudu on poliitika.
Kust grupi väärtus tegelikult tuleb
Active Directory puhul sisaldab väli access-group grupi SID-i, mitte selle kuvanime. SAML-föderatsiooni puhul sisaldab see grupi ID-d või nime, mida konfigureeritud SAML-i grupiatribuut tegelikult kannab. Kopeerige väärtus assertionist või kataloogi päringust, mitte viki lehelt.
IAM-grupp on teine juhtimistasand. Õigus hallata Client VPN-i lõpp-punkti ei tee IAM-grupist kasutaja VPN-gruppi ning IAM-grupi nime kleepimine väljale access-group ei muuda seda AD SID-iks ega SAML-i atribuudi väärtuseks.
Sarnase nimega grupp teises kataloogis ei tõesta midagi. Kontrollige lõpp-punkti autentimismeetodit ja kasutaja liikmelisust või assertioni samas süsteemis.
Võidab pikim prefiks, sealhulgas 0.0.0.0/0
Autoriseerimist hinnatakse pikima prefiksi järgi ning kõigi sihtkohtade reeglit hinnatakse viimasena, mitte esimesena. Lisage Engineeringule reegel 10.46.0.0/16 ja kõigile reegel 0.0.0.0/0, ning väljaspool Engineeringut olev kasutaja ei pääse ikkagi laia reegli kaudu aadressile 10.46.20.10.
Siin võib parandus valesti minna. Kitsa reegli kustutamine taastab kasutaja juurdepääsu ja annab selle alamvõrgu ka igale identiteedile, mille lai reegel katab. Koostage grupi ja võrgu maatriks enne, kui midagi kustutate, ja pange kirja, millised grupid peaksid millisele vahemikule pääsema. Need reeglid ainult lubavad; laiast lubast erandi lõikamiseks pole keelamiskirjet.
Muudatused vajavad õiglaseks hindamiseks ka värsket ühendust. Ühendage klient pärast reeglite muutmist uuesti ja testige siis uuesti.
Eraldage autoriseerimine andmete teest
Kattuv reegel ei ole marsruut. Lõpp-punkt vajab seotud alamvõrku ja sihtkoha jaoks marsruutimistabeli kirjet ning sihtressursi turvagrupp peab liikluse vastu võtma. Ka tagasiliiklus ja DNS peavad toimima.
Testige kasutajat, kellel peaks õnnestuma, ja kasutajat, kes peaks välja jääma. Mõlemad saavad sisse logida, kuid ainult üks pääseb alamvõrku, ja see erinevus on tõestus, mida soovite.
Kui IP-aadress töötab, aga hostinimi mitte, vaadake enne autoriseerimise puutumist resolverit. Kui ükski marsruut aadressi ei kata, parandage seos või marsruutimistabel. Kui pakett saabub ja teenus keeldub sellest, on järgmine peatus selle teenuse poliitika. Autoriseerimismaatriksi laiendamine kõigile kasutajatele varjab, milline neist kihtidest tegelikult katki oli.
Enne pileti sulgemist kirjutage üles identiteediallikas, täpne grupiväärtus, sihtkoha prefiksid ja liiklust kandev marsruut. See kirje muudab järgmise teate ühendatud, kuid juurdepääs puudub kaheminutiliseks võrdluseks veel ühe oletusringi asemel.