AWS Client VPN: kuingia kunafanikiwa lakini subnet haifikiki

Mteja wako anasema Connected, cheti ni halali, na ukurasa wa intranet bado unaishia kwa kukosa muda. Pengo hilo mara nyingi si uthibitishaji. AWS Client VPN huidhinisha maeneo lengwa kwa njia tofauti na kuingia, na sababu mbili za kawaida ni thamani ya kikundi isiyolingana na ile iliyotumwa na mtoa utambulisho na kanuni mahususi zaidi ya lengwa inayoshinda kanuni pana. Zote mbili zinaonekana katika usanidi wa endpoint ukiwa unajua wapi pa kuangalia.

Kuingia kulifanikiwa; kanuni haikulingana

Uthibitishaji hujibu ni nani mtumiaji. Kanuni za idhini hujibu ni kiambishi awali kipi cha mtandao utambulisho huo unaweza kufikia. Mtumiaji anaweza kupita la kwanza na kushindwa la pili, na mteja hukupa zaidi ya muunganisho unaobaki wazi wakati kila ombi linaishia kwa kukosa muda.

Anza kwa kuthibitisha kwamba endpoint ina kanuni ya idhini ambayo lengwa lake lina anwani inayoshindwa. Ikiwa hakuna kanuni inayolingana, muunganisho unafanya kazi ipasavyo; sera ndiyo inayokosekana.

Thamani ya kikundi inatoka wapi kwa kweli

Katika Active Directory, sehemu ya access-group ina SID ya kikundi, sio jina lake la kuonyesha. Katika shirikisho la SAML, ina kitambulisho au jina la kikundi ambalo sifa ya kikundi ya SAML iliyosanidiwa hubeba kwa kweli. Nakili thamani kutoka kwa assertion au utafutaji wa saraka, sio kutoka ukurasa wa wiki.

Kikundi cha IAM ni ngazi nyingine ya udhibiti. Ruhusa ya kusimamia endpoint ya Client VPN haifanyi kikundi cha IAM kuwa kikundi cha VPN cha mtumiaji, na kubandika jina la kikundi cha IAM kwenye sehemu ya access-group hakukibadilishi kuwa SID ya AD au thamani ya sifa ya SAML.

Kikundi chenye jina linalofanana katika saraka nyingine hakithibitishi chochote. Kagua mbinu ya uthibitishaji ya endpoint na uanachama au assertion ya mtumiaji katika mfumo huo huo.

Kiambishi awali kirefu zaidi kinashinda, ikiwemo 0.0.0.0/0

Idhini hutathminiwa kwa ulinganifu wa kiambishi awali kirefu zaidi, na kanuni ya maeneo lengwa yote hutathminiwa mwisho, sio kwanza. Ongeza kanuni 10.46.0.0/16 kwa Engineering na kanuni 0.0.0.0/0 kwa kila mtu, na mtumiaji aliye nje ya Engineering bado hawezi kufikia 10.46.20.10 kupitia kanuni pana.

Hapa ndipo marekebisho yanaweza kwenda kombo. Kufuta kanuni nyembamba hurudisha ufikiaji wa mtumiaji na pia hukipa subnet hiyo kila utambulisho unaofunikwa na kanuni pana. Jenga matriki ya kikundi-hadi-mtandao kabla ya kufuta chochote, na andika ni vikundi vipi vinapaswa kufikia masafa gani. Kanuni hizi huruhusu tu; hakuna kipengele cha kukataa cha kukata ubaguzi kutoka kwa ruhusa pana.

Mabadiliko pia yanahitaji muunganisho mpya ili yatathminiwe kwa haki. Unganisha tena mteja baada ya kuhariri kanuni, kisha jaribu tena.

Tenganisha idhini na njia ya data

Kanuni inayolingana sio njia. Endpoint inahitaji subnet iliyounganishwa na kipengele cha jedwali la njia kwa lengwa, na kikundi cha usalama cha rasilimali lengwa lazima kikubali trafiki. Trafiki ya kurudi na DNS pia lazima vifanye kazi.

Jaribu mtumiaji anayepaswa kufanikiwa na mtumiaji anayepaswa kubaki nje. Wote wanaweza kuingia wakati mmoja tu anafikia subnet, na tofauti hiyo ndiyo ushahidi unaoutaka.

Ikiwa anwani ya IP inafanya kazi lakini jina la mwenyeji halifanyi kazi, angalia resolver kabla ya kugusa idhini. Ikiwa hakuna njia inayofunika anwani hiyo, rekebisha muunganisho au jedwali la njia. Ikiwa pakiti inafika na huduma inaikataa, kituo kinachofuata ni sera ya huduma hiyo. Kupanua matriki ya idhini kwa watumiaji wote huficha tabaka gani kati ya hizo lilikuwa limevunjika kweli.

Kabla ya kufunga tiketi, andika chanzo cha utambulisho, thamani kamili ya kikundi, viambishi awali vya lengwa na njia inayobeba trafiki. Rekodi hiyo hubadilisha ripoti inayofuata ya kuunganishwa lakini hakuna ufikiaji kuwa ulinganisho wa dakika mbili badala ya mzunguko mwingine wa kukisia.