Az ügyfél Connected állapotot mutat, a tanúsítvány érvényes, az intranet oldal mégis időtúllépéssel áll le. Ez a rés szinte soha nem hitelesítési probléma. Az AWS Client VPN a célpontokat a bejelentkezéstől elkülönítve jogosítja, és a két szokásos ok egy csoportérték, amely nem egyezik az identitásszolgáltató által küldöttel, valamint egy specifikusabb célszabály, amely felülírja a széles szabályt. Mindkettő látható az endpoint konfigurációjában, ha tudjuk, hol keressük.

A bejelentkezés sikerült; a szabály nem egyezett

A hitelesítés arra válaszol, ki a felhasználó. A jogosultsági szabályok arra válaszolnak, mely hálózati előtagokat érheti el ez az identitás. A felhasználó átmehet az elsőn és elbukhat a másodikon, az ügyfél pedig alig ad többet egy kapcsolatnál, amely fennmarad, miközben minden kérés időtúllépésbe fut.

Kezdje annak ellenőrzésével, hogy az endpointnak van-e olyan jogosultsági szabálya, amelynek célpontja tartalmazza a hibás címet. Ha nincs egyező szabály, a kapcsolat helyesen viselkedik; a házirend hiányzik.

Honnan származik valójában a csoportérték

Active Directory esetén az access-group mező a csoport SID-jét tartalmazza, nem a megjelenített nevét. SAML-összevonás esetén azt a csoportazonosítót vagy nevet tartalmazza, amelyet a beállított SAML-csoportattribútum ténylegesen hordoz. Az értéket az assertionből vagy a címtárkeresésből másolja, ne egy wikioldalról.

Az IAM-csoport másik vezérlési sík. Az engedély Client VPN endpoint adminisztrálására nem teszi az IAM-csoportot a felhasználó VPN-csoportjává, és az IAM-csoportnév beillesztése az access-group mezőbe nem fordítja le AD SID-dé vagy SAML-attribútumértékké.

Egy hasonló nevű csoport egy másik címtárban semmit sem bizonyít. Ellenőrizze az endpoint hitelesítési módszerét és a felhasználó tagságát vagy assertionjét ugyanabban a rendszerben.

A leghosszabb előtag nyer, a 0.0.0.0/0-t is beleértve

A jogosultság kiértékelése a leghosszabb előtag-egyezés szerint történik, és a minden célpontra vonatkozó szabályt utoljára értékelik, nem először. Adjon hozzá egy 10.46.0.0/16 szabályt az Engineeringnek és egy 0.0.0.0/0 szabályt mindenkinek, és az Engineeringen kívüli felhasználó továbbra sem éri el a 10.46.20.10-et a széles szabályon keresztül.

Itt mehet félre egy javítás. A szűk szabály törlése visszaadja a felhasználó hozzáférését, és ugyanazt az alhálózatot minden identitásnak is megadja, amelyre a széles szabály kiterjed. Építse fel a csoport-hálózat mátrixot, mielőtt bármit töröl, és írja le, mely csoportoknak melyik tartományt kell elérniük. Ezek a szabályok csak engedélyeznek; nincs tiltó bejegyzés, amellyel kivételt vághatna ki egy széles engedélyből.

A változtatásokhoz friss kapcsolat is kell az igazságos elbíráláshoz. A szabályok szerkesztése után csatlakoztassa újra az ügyfelet, majd teszteljen újra.

Válassza szét a jogosultságot az adatúttól

Az egyező szabály nem útvonal. Az endpointnak szüksége van egy társított alhálózatra és egy útválasztási táblabejegyzésre a célponthoz, és a cél-erőforrás biztonsági csoportjának el kell fogadnia a forgalmat. A visszafelé irányuló forgalomnak és a DNS-nek is működnie kell.

Teszteljen egy felhasználót, akinek sikerülnie kell, és egyet, akinek ki kell maradnia. Mindketten be tudnak jelentkezni, miközben csak az egyik éri el az alhálózatot, és ez a különbség a bizonyíték, amit keres.

Ha egy IP-cím működik, de egy hosztnév nem, nézze meg a resolver-t, mielőtt a jogosultsághoz nyúl. Ha egyetlen útvonal sem fedi le a címet, javítsa a társítást vagy az útválasztási táblát. Ha a csomag megérkezik, és a szolgáltatás elutasítja, a következő állomás annak a szolgáltatásnak a házirendje. A jogosultsági mátrix minden felhasználóra való kiterjesztése elrejti, melyik réteg volt valójában hibás.

Mielőtt lezárja a ticketet, rögzítse az identitásforrást, a pontos csoportértéket, a cél-előtagokat és a forgalmat vivő útvonalat. Ez a feljegyzés a következő csatlakozva, de hozzáférés nélkül jelentést kétperces összehasonlítássá teszi egy újabb találgatási kör helyett.

Kapcsolódó cikkek