AWS Client VPN: prijava uspe, a podomrežje ostane nedosegljivo

Vaš odjemalec pravi Connected, potrdilo je veljavno, intranetna stran pa se še vedno konča s preseženim časom. Ta vrzel skoraj nikoli ni avtentikacija. AWS Client VPN odobri cilje ločeno od prijave, običajna dva vzroka pa sta vrednost skupine, ki se ne ujema s tisto, ki jo je poslal ponudnik identitete, in natančnejše pravilo cilja, ki premaga široko pravilo. Oboje je vidno v konfiguraciji endpointa, ko veste, kam gledati.

Prijava je uspela; pravilo se ni ujemalo

Avtentikacija odgovori, kdo je uporabnik. Pravila odobritve odgovorijo, do katerih omrežnih predpon sme ta identiteta doseči. Uporabnik lahko prestane prvo in pade pri drugem, odjemalec pa vam ne da veliko več kot povezavo, ki ostane vzpostavljena, medtem ko vsaka zahteva poteče.

Začnite s potrditvijo, da ima endpoint pravilo odobritve, katerega cilj vsebuje naslov, ki ne deluje. Če ustreznega pravila ni, se povezava obnaša pravilno; manjka politika.

Od kod vrednost skupine v resnici pride

V Active Directory polje access-group vsebuje SID skupine, ne njenega prikaznega imena. Pri federaciji SAML vsebuje ID ali ime skupine, ki jo konfigurirani atribut skupine SAML res prinaša. Vrednost kopirajte iz assertion ali iz poizvedbe v imeniku, ne s strani wiki.

Skupina IAM je druga krmilna ravnina. Dovoljenje za upravljanje endpointa Client VPN ne naredi skupine IAM uporabnikove VPN skupine, prilepitev imena skupine IAM v polje access-group pa ga ne pretvori v SID v AD ali vrednost atributa SAML.

Skupina s podobnim imenom v drugem imeniku ne dokazuje ničesar. Preverite način avtentikacije endpointa in uporabnikovo članstvo ali assertion v istem sistemu.

Zmaguje najdaljša predpona, tudi 0.0.0.0/0

Odobritev se ocenjuje po najdaljšem ujemanju predpone, pravilo za vse cilje pa se ocenjuje zadnje, ne prvo. Dodajte pravilo 10.46.0.0/16 za Engineering in pravilo 0.0.0.0/0 za vse, pa uporabnik zunaj Engineeringa prek širokega pravila še vedno ne doseže 10.46.20.10.

Tu lahko popravek gre narobe. Brisanje ozkega pravila vrne uporabnikov dostop in hkrati dodeli to podomrežje vsaki identiteti, ki jo pokriva široko pravilo. Zgradite matriko skupin in omrežij, preden karkoli izbrišete, in zapišite, katere skupine naj dosežejo katero območje. Ta pravila samo dovoljujejo; ni vnosa za zavrnitev, s katerim bi iz širokega dovoljenja izrezali izjemo.

Spremembe potrebujejo tudi novo povezavo, da jih je mogoče pošteno oceniti. Po urejanju pravil odjemalca znova povežite in nato znova preizkusite.

Ločite odobritev od podatkovne poti

Pravilo, ki se ujema, ni pot. Endpoint potrebuje pridruženo podomrežje in vnos v tabeli usmerjanja za cilj, varnostna skupina ciljnega vira pa mora promet sprejeti. Povratni promet in DNS morata prav tako delovati.

Preizkusite uporabnika, ki bi moral uspeti, in uporabnika, ki bi moral ostati izključen. Oba se lahko prijavita, a le eden doseže podomrežje, in prav ta razlika je dokaz, ki ga želite.

Če IP naslov deluje, ime gostitelja pa ne, poglejte resolver, preden se dotaknete odobritve. Če nobena pot ne pokriva naslova, popravite povezavo ali tabelo usmerjanja. Če paket prispe in ga storitev zavrne, je naslednja postaja politika te storitve. Širitev matrike odobritve na vse uporabnike skrije, katera od teh plasti je bila v resnici pokvarjena.

Preden zaprete zahtevek, zabeležite vir identitete, natančno vrednost skupine, predpone cilja in pot, ki nosi promet. Takšen zapis spremeni naslednje poročilo o povezanosti brez dostopa v primerjavo v dveh minutah namesto v še en krog ugibanja.