AWS Client VPN: aanmelding slaag, maar die subnet bly onbereikbaar

Jou kliënt sê Connected, die sertifikaat is geldig, en die intranetblad keer steeds terug met 'n tydsverloop. Daardie gaping is byna nooit bekragtiging nie. AWS Client VPN magtig bestemmings afsonderlik van aanmelding, en die twee gewone oorsake is 'n groepwaarde wat nie ooreenstem met wat die identiteitsverskaffer gestuur het nie, en 'n meer spesifieke bestemmingsreël wat die breë reël wen. Albei is sigbaar in die eindpuntkonfigurasie sodra jy weet waar om te kyk.

Die aanmelding het geslaag; die reël het nie gepas nie

Bekragtiging beantwoord wie die gebruiker is. Magtigingsreëls beantwoord watter netwerkvoorvoegsels daardie identiteit mag bereik. 'n Gebruiker kan die eerste slaag en die tweede faal, en die kliënt gee jou min meer as 'n verbinding wat bly staan terwyl elke versoek 'n tydsverloop kry.

Begin deur te bevestig dat die eindpunt 'n magtigingsreël het waarvan die bestemming die falende adres bevat. As daar geen passende reël is nie, werk die verbinding korrek; die beleid ontbreek.

Waar die groepwaarde werklik vandaan kom

Met Active Directory hou die access-group-veld die groep se SID, nie sy vertoonnaam nie. Met SAML-federasie hou dit die groep-ID of -naam wat die gekonfigureerde SAML-groepkenmerk werklik dra. Kopieer die waarde uit die bewering of die gidsnavraag, nie uit 'n wiki-bladsy nie.

'n IAM-groep is 'n ander beheervlak. Toestemming om 'n Client VPN-eindpunt te administreer maak nie 'n IAM-groep 'n gebruiker se VPN-groep nie, en om 'n IAM-groepnaam in die access-group-veld te plak vertaal dit nie na 'n AD SID of 'n SAML-kenmerkwaarde nie.

'n Groep met 'n soortgelyke naam in 'n ander gids bewys niks. Kontroleer die eindpunt se bekragtigingsmetode en die gebruiker se lidmaatskap of bewering in daardie selfde stelsel.

Langste voorvoegsel wen, ook 0.0.0.0/0

Magtiging word volgens die langste voorvoegsel geëvalueer, en die reël vir alle bestemmings word laas geëvalueer, nie eerste nie. Voeg 'n 10.46.0.0/16-reël vir Engineering by en 'n 0.0.0.0/0-reël vir almal, en 'n gebruiker buite Engineering kan steeds nie 10.46.20.10 deur die breë reël bereik nie.

Dit is waar 'n regmaak verkeerd kan gaan. Om die nou reël te skrap herstel die gebruiker se toegang en verleen ook daardie subnet aan elke identiteit wat deur die breë reël gedek word. Bou die groep-tot-netwerk-matriks voordat jy iets skrap, en skryf neer watter groepe veronderstel is om watter reeks te bereik. Hierdie reëls is slegs-toelaat; daar is geen weier-inskrywing om 'n uitsondering uit 'n breë toelating te kerf nie.

Veranderinge vereis ook 'n vars verbinding om regverdig beoordeel te word. Herverbind die kliënt nadat jy reëls gewysig het, en toets dan weer.

Skei magtiging van die datapad

'n Reël wat pas, is nie 'n roete nie. Die eindpunt benodig 'n geassosieerde subnet en 'n roetetabelinskrywing vir die bestemming, en die teikenbron se sekuriteitsgroep moet die verkeer aanvaar. Terugkeerverkeer en DNS moet ook werk.

Toets 'n gebruiker wat behoort te slaag en 'n gebruiker wat uitgesluit moet bly. Albei kan aanmeld terwyl slegs een die subnet bereik, en daardie verskil is die bewys wat jy wil hê.

As 'n IP-adres werk maar 'n gasheernaam nie, kyk na die resolver voordat jy aan magtiging raak. As geen roete die adres dek nie, maak die assosiasie of roetetabel reg. As die pakket aankom en die diens weier dit, is daardie diens se beleid die volgende stop. Om die magtigingsmatriks na alle gebruikers te verbreed, verberg watter van daardie lae werklik gebreek was.

Voordat jy die kaartjie sluit, teken die identiteitsbron, die presiese groepwaarde, die bestemmingsvoorvoegsels en die roete wat die verkeer dra, aan. Daardie rekord maak die volgende verslag oor verbind maar sonder toegang 'n vergelyking van twee minute in plaas van nog 'n ronde raaiwerk.