AWS Client VPN: pieteikšanās izdodas, bet apakštīkls nav sasniedzams

Jūsu klients rāda Connected, sertifikāts ir derīgs, un intraneta lapa joprojām beidzas ar taimautu. Šī plaisa gandrīz nekad nav autentifikācija. AWS Client VPN autorizē galamērķus atsevišķi no pieteikšanās, un divi ierastie iemesli ir grupas vērtība, kas neatbilst identitātes sniedzēja nosūtītajai, un konkrētāka galamērķa kārtula, kas pārspēj plašo kārtulu. Abas ir redzamas endpoint konfigurācijā, kad zini, kur skatīties.

Pieteikšanās izdevās; kārtula nesaskanēja

Autentifikācija atbild, kas ir lietotājs. Autorizācijas kārtulas atbild, kuriem tīkla prefiksiem šī identitāte drīkst piekļūt. Lietotājs var izturēt pirmo un neizturēt otro, un klients dod gandrīz neko vairāk par savienojumu, kas paliek atvērts, kamēr katrs pieprasījums beidzas ar taimautu.

Sāciet ar pārbaudi, vai endpoint ir autorizācijas kārtula, kuras galamērķis ietver neizdevušos adresi. Ja atbilstošas kārtulas nav, savienojums darbojas pareizi; trūkst politikas.

No kurienes grupas vērtība patiesībā nāk

Active Directory gadījumā lauks access-group satur grupas SID, nevis tās attēlojamo nosaukumu. SAML federācijas gadījumā tas satur grupas ID vai nosaukumu, ko konfigurētais SAML grupas atribūts patiešām nes. Kopējiet vērtību no assertion vai direktorija meklēšanas, nevis no wiki lapas.

IAM grupa ir cita vadības plakne. Atļauja pārvaldīt Client VPN endpoint nepadara IAM grupu par lietotāja VPN grupu, un IAM grupas nosaukuma ielīmēšana laukā access-group nepārvērš to par AD SID vai SAML atribūta vērtību.

Līdzīgi nosaukta grupa citā direktorijā neko nepierāda. Pārbaudiet endpoint autentifikācijas metodi un lietotāja dalību vai assertion tajā pašā sistēmā.

Uzvar garākais prefikss, tostarp 0.0.0.0/0

Autorizācija tiek vērtēta pēc garākās prefiksa atbilstības, un kārtula visiem galamērķiem tiek vērtēta pēdējā, nevis pirmā. Pievienojiet kārtulu 10.46.0.0/16 Engineering un kārtulu 0.0.0.0/0 visiem, un lietotājs ārpus Engineering joprojām nevarēs sasniegt 10.46.20.10 caur plašo kārtulu.

Šeit labojums var aiziet greizi. Dzēšot šauro kārtulu, lietotāja piekļuve atgriežas, un tas apakštīkls tiek piešķirts arī katrai identitātei, ko aptver plašā kārtula. Izveidojiet grupu un tīklu matricu pirms kaut kā dzēšanas un pierakstiet, kurām grupām jāsasniedz kurš diapazons. Šīs kārtulas tikai atļauj; nav aizlieguma ieraksta, ar ko no plašas atļaujas izgriezt izņēmumu.

Izmaiņām vajag arī svaigu savienojumu, lai tās varētu godīgi novērtēt. Pēc kārtulu rediģēšanas pievienojiet klientu no jauna, pēc tam pārbaudiet vēlreiz.

Atdaliet autorizāciju no datu ceļa

Atbilstoša kārtula nav maršruts. Endpoint nepieciešams piesaistīts apakštīkls un maršrutu tabulas ieraksts galamērķim, un mērķa resursa drošības grupai jāpieņem trafiks. Atgriešanās trafikam un DNS arī jādarbojas.

Pārbaudiet lietotāju, kuram vajadzētu izdoties, un lietotāju, kuram vajadzētu palikt ārpusē. Abi var pieteikties, bet tikai viens sasniedz apakštīklu, un tieši šī atšķirība ir vajadzīgais pierādījums.

Ja IP adrese strādā, bet resursdatora nosaukums ne, apskatiet resolver pirms autorizācijas aizskaršanas. Ja neviens maršruts neaptver adresi, izlabojiet piesaisti vai maršrutu tabulu. Ja pakete ierodas un pakalpojums to noraida, nākamā pietura ir tā pakalpojuma politika. Autorizācijas matricas paplašināšana uz visiem lietotājiem paslēpj, kurš no šiem slāņiem patiešām bija salauzts.

Pirms biļetes aizvēršanas pierakstiet identitātes avotu, precīzu grupas vērtību, galamērķa prefiksus un maršrutu, kas pārvadā trafiku. Šis ieraksts pārvērš nākamo ziņojumu par pieslēgts, bet nav piekļuves divu minūšu salīdzinājumā, nevis vēl vienā minējumu kārtā.