AWS Client VPN: oanmelde slagget, mar it subnet is net berikber

Jo klient seit Connected, it sertifikaat is jildich, en de intranet-side rint noch hieltyd op in time-out. Dat gat is hast nea autentikaasje. AWS Client VPN autorisearret bestimmingen apart fan oanmelding, en de twa gewoane oarsaken binne in groepswearde dy’t net oerienkomt mei wat de identiteitsprovider stjoerde en in mear spesifike bestimmingsregel dy’t de brede regel ferslacht. Beide binne te sjen yn de endpoint-konfiguraasje as jo witte wêr’t jo sjogge moatte.

De oanmelding slagge; de regel paste net

Autentikaasje antwurdet wa’t de brûker is. Autorisaasjeregels antwurdzje hokker netwurkfoarheaksels dy identiteit berikke mei. In brûker kin de earste helje en de twadde misse, en de klient jout jo amper mear as in ferbining dy’t oerein bliuwt wylst elk fersyk op in time-out rint.

Begjin mei te befêstigjen dat de endpoint in autorisaasjeregel hat wêrfan de bestimming it mislearjende adres befettet. As der gjin passende regel is, docht de ferbining it goed; it belied ûntbrekt.

Wêr’t de groepswearde echt wei komt

Mei Active Directory hâldt it fjild access-group de SID fan ’e groep, net syn werjefte namme. Mei SAML-federatie hâldt it de groeps-ID of namme dy’t it konfigurearre SAML-groepsattribút eins draacht. Kopiearje de wearde út ’e assertion of út ’e gidsopsyk, net fan in wikiside.

In IAM-groep is in oar kontrôleflak. Tastimming om in Client VPN-endpoint te behearjen makket in IAM-groep gjin VPN-groep fan in brûker, en in IAM-groepsnamme yn it fjild access-group plakke fertaalt it net nei in AD SID of in SAML-attribútwearde.

In groep mei in ferlykbere namme yn in oare gids bewissiget neat. Kontrolearje de autentikaasjemetoade fan ’e endpoint en it lidmaatskip of de assertion fan ’e brûker yn itselde systeem.

Langste foarheaksel wint, ek 0.0.0.0/0

Autorisaasje wurdt beoardiele troch de langste foarheaksel-oerienkomst, en de regel foar alle bestimmingen wurdt lêst beoardiele, net earst. Foegje in regel 10.46.0.0/16 foar Engineering ta en in regel 0.0.0.0/0 foar elkenien, en in brûker bûten Engineering kin noch hieltyd net 10.46.20.10 berikke fia de brede regel.

Hjir kin in repaasje ferkeard gean. It fuortheljen fan ’e smelle regel herstelt de tagong fan ’e brûker en jout dat subnet ek oan elke identiteit dy’t de brede regel beslacht. Bou de groep-nei-netwurk-matriks foardat jo eat fuorthelje, en skriuw op hokker groepen hokker berik berikke moatte. Dizze regels litte allinnich ta; der is gjin wegering-ynfier om in útsûndering út in brede tastimming te snijen.

Feroarings freegje ek in farske ferbining om earlik beoardiele te wurden. Ferbynje de klient opnij nei it bewurkjen fan regels, en test dan opnij.

Skied autorisaasje fan it datapad

In regel dy’t past is gjin rûte. De endpoint hat in keppele subnet en in rûte-tabel-ynfier foar de bestimming nedich, en de befeiligingsgroep fan ’e doelmiddel moat it ferkear akseptearje. Weromferkear en DNS moatte ek wurkje.

Test in brûker dy’t slagje moat en in brûker dy’t útsletten bliuwe moat. Beide kinne oanmelde wylst mar ien it subnet berikt, en dat ferskil is it bewiis dat jo wolle.

As in IP-adres wurket mar in hostnamme net, sjoch dan nei de resolver foardat jo oan autorisaasje komme. As gjin rûte it adres beslacht, reparearje dan de keppeling of de rûte-tabel. As it pakket oankomt en de tsjinst wegeret it, dan is it belied fan dy tsjinst de folgjende stop. It ferbreedzjen fan ’e autorisaasjemetriks nei alle brûkers ferberget hokker fan dy lagen echt stikken wie.

Foardat jo it ticket slute, skriuw de identiteitsboarne, de krekte groepswearde, de bestimmingsfoarheaksels en de rûte dy’t it ferkear draacht op. Dat ferslach makket it folgjende berjocht oer ferbûn mar gjin tagong in ferliking fan twa minuten ynstee fan noch in rûnte rieden.