AWS Client VPN: přihlášení projde, ale podsíť není dostupná

Klient hlásí Connected, certifikát je platný a stránka intranetu stále končí vypršením časového limitu. Tato mezera téměř nikdy není autentizace. AWS Client VPN autorizuje cíle odděleně od přihlášení a obvykle k tomu vedou dvě příčiny: hodnota skupiny, která neodpovídá tomu, co poslal poskytovatel identity, a konkrétnější pravidlo cíle, které přebije široké pravidlo. Obojí je vidět v konfiguraci endpointu, jakmile víte, kam se dívat.

Přihlášení prošlo; pravidlo nesedělo

Autentizace odpovídá na to, kdo je uživatel. Pravidla autorizace odpovídají na to, ke kterým síťovým prefixům tato identita smí dosáhnout. Uživatel může projít prvním a selhat ve druhém a klient vám nedá víc než spojení, které zůstává otevřené, zatímco každý požadavek vyprší.

Začněte tím, že ověříte, zda endpoint má pravidlo autorizace, jehož cíl obsahuje selhávající adresu. Pokud žádné odpovídající pravidlo není, spojení se chová správně; chybí politika.

Odkud hodnota skupiny skutečně pochází

V Active Directory drží pole access-group SID skupiny, ne její zobrazované jméno. Při federaci SAML drží ID nebo název skupiny, který nakonfigurovaný atribut skupiny SAML skutečně nese. Zkopírujte hodnotu z assertion nebo z dotazu do adresáře, ne z wiki stránky.

Skupina IAM je jiná řídicí rovina. Oprávnění spravovat endpoint Client VPN nedělá ze skupiny IAM uživatelovu VPN skupinu a vložení názvu skupiny IAM do pole access-group ho nepřeloží na SID v AD ani na hodnotu atributu SAML.

Skupina podobného jména v jiném adresáři nic nedokazuje. Zkontrolujte metodu autentizace endpointu a členství nebo assertion uživatele v tomtéž systému.

Vyhrává nejdelší prefix, včetně 0.0.0.0/0

Autorizace se vyhodnocuje podle nejdelší shody prefixu a pravidlo pro všechny cíle se vyhodnocuje jako poslední, ne první. Přidejte pravidlo 10.46.0.0/16 pro Engineering a pravidlo 0.0.0.0/0 pro všechny a uživatel mimo Engineering se přes široké pravidlo na 10.46.20.10 stále nedostane.

Tady se oprava může zvrtnout. Smazání úzkého pravidla vrátí uživateli přístup a také přidělí tuto podsíť každé identitě, kterou pokrývá široké pravidlo. Postavte matici skupin a sítí dřív, než cokoli smažete, a zapište, které skupiny mají dosáhnout na který rozsah. Tato pravidla pouze povolují; neexistuje záznam pro zamítnutí, kterým byste z širokého povolení vyřízli výjimku.

Změny také potřebují nové spojení, aby se daly poctivě posoudit. Po úpravě pravidel klienta znovu připojte a pak znovu otestujte.

Oddělte autorizaci od datové cesty

Pravidlo, které sedí, není trasa. Endpoint potřebuje přidruženou podsíť a záznam v routovací tabulce pro cíl a bezpečnostní skupina cílového prostředku musí provoz přijmout. Zpětný provoz a DNS také musí fungovat.

Otestujte uživatele, kterému se to má podařit, a uživatele, který má zůstat vyloučený. Oba se mohou přihlásit, ale jen jeden dosáhne na podsíť, a právě ten rozdíl je důkaz, který hledáte.

Pokud IP adresa funguje a název hostitele ne, podívejte se na resolver, než sáhnete na autorizaci. Pokud adresu nepokrývá žádná trasa, opravte přidružení nebo routovací tabulku. Pokud paket dorazí a služba ho odmítne, další zastávkou je politika té služby. Rozšíření autorizační matice na všechny uživatele skryje, která z těch vrstev byla skutečně rozbitá.

Než ticket zavřete, zaznamenejte zdroj identity, přesnou hodnotu skupiny, prefixy cíle a trasu, která provoz nese. Takový záznam promění příští hlášení o připojení bez přístupu ve srovnání na dvě minuty místo dalšího kola hádání.