AWS Client VPN: входът минава, но подмрежата е недостъпна

Клиентът ви казва Connected, сертификатът е валиден, а страницата на интранета все още завършва с таймаут. Тази разлика почти никога не е автентикация. AWS Client VPN оторизира дестинациите отделно от входа и обичайните две причини са стойност на групата, която не съвпада с изпратената от доставчика на идентичност, и по-конкретно правило за дестинация, което надделява над общото. И двете се виждат в конфигурацията на endpoint, щом знаете къде да гледате.

Входът мина; правилото не съвпадна

Автентикацията отговаря кой е потребителят. Правилата за оторизация отговарят до кои мрежови префикси тази идентичност може да достигне. Потребителят може да мине първото и да се провали на второто, а клиентът ви дава само връзка, която остава вдигната, докато всяка заявка завършва с таймаут.

Започнете с потвърждение, че endpoint има правило за оторизация, чиято дестинация съдържа проблемния адрес. Ако няма съвпадащо правило, връзката се държи правилно; липсва политиката.

Откъде всъщност идва стойността на групата

При Active Directory полето access-group съдържа SID на групата, а не показваното ѝ име. При SAML федерация то съдържа ID или име на групата, което конфигурираният SAML атрибут за група действително носи. Копирайте стойността от assertion или от справката в директорията, не от wiki страница.

Групата IAM е друга равнина на управление. Разрешението да администрирате endpoint на Client VPN не прави групата IAM VPN група на потребителя и поставянето на име на IAM група в полето access-group не го превръща в SID на AD или в стойност на SAML атрибут.

Група с подобно име в друга директория не доказва нищо. Проверете метода за автентикация на endpoint и членството или assertion на потребителя в същата система.

Печели най-дългият префикс, включително 0.0.0.0/0

Оторизацията се оценява по най-дълго съвпадение на префикс, а правилото за всички дестинации се оценява последно, не първо. Добавете правило 10.46.0.0/16 за Engineering и правило 0.0.0.0/0 за всички, и потребител извън Engineering пак не може да достигне 10.46.20.10 през общото правило.

Тук едно поправяне може да се обърка. Изтриването на тясното правило връща достъпа на потребителя и също дава тази подмрежа на всяка идентичност, обхваната от общото правило. Постройте матрицата група–мрежа, преди да изтриете нещо, и запишете кои групи трябва да достигат кой диапазон. Тези правила само разрешават; няма запис за отказ, с който да изрежете изключение от общо разрешение.

Промените също изискват нова връзка, за да бъдат оценени честно. Свържете клиента отново след редактиране на правилата и тествайте пак.

Отделете оторизацията от пътя на данните

Съвпадащо правило не е маршрут. Endpoint се нуждае от свързана подмрежа и запис в таблицата за маршрутизация за дестинацията, а групата за сигурност на целевия ресурс трябва да приема трафика. Обратният трафик и DNS също трябва да работят.

Тествайте потребител, който трябва да успее, и потребител, който трябва да остане изключен. И двамата могат да влязат, но само единият достига подмрежата, и точно тази разлика е доказателството, което ви трябва.

Ако IP адрес работи, а име на хост не, погледнете resolver-а, преди да пипате оторизацията. Ако никой маршрут не покрива адреса, поправете асоциацията или таблицата за маршрутизация. Ако пакетът пристигне и услугата го откаже, политиката на тази услуга е следващата спирка. Разширяването на матрицата за оторизация до всички потребители скрива кой от тези слоеве всъщност е бил счупен.

Преди да затворите тикета, запишете източника на идентичност, точната стойност на групата, префиксите на дестинацията и маршрута, който носи трафика. Този запис превръща следващия сигнал за свързаност без достъп в сравнение за две минути вместо още един кръг догадки.