AWS Client VPN: prijava uspijeva, ali podmreža nije dostupna
Uspješna prijava na AWS Client VPN ne daje pristup svakoj podmreži. Provjerite vrijednost grupe i najspecifičnije pravilo odredišta prije nego proširite pristup.
Klijent kaže Connected, certifikat je važeći, a intranet stranica i dalje završava istekom vremena. Taj jaz gotovo nikad nije autentifikacija. AWS Client VPN autorizira odredišta odvojeno od prijave, a dva uobičajena uzroka su vrijednost grupe koja se ne poklapa s onim što je poslao davatelj identiteta i specifičnije pravilo odredišta koje pobjeđuje široko pravilo. Oba su vidljiva u konfiguraciji endpointa kad znate gdje tražiti.
Prijava je uspjela; pravilo se nije poklopilo
Autentifikacija odgovara ko je korisnik. Pravila autorizacije odgovaraju koje mrežne prefikse taj identitet smije dosegnuti. Korisnik može proći prvo i pasti na drugom, a klijent vam daje tek vezu koja ostaje aktivna dok svaki zahtjev istječe.
Počnite potvrdom da endpoint ima pravilo autorizacije čije odredište sadrži adresu koja ne prolazi. Ako nema odgovarajućeg pravila, veza se ponaša ispravno; nedostaje politika.
Odakle vrijednost grupe zapravo dolazi
U Active Directoryju polje access-group sadrži SID grupe, a ne njeno prikazano ime. U SAML federaciji sadrži ID ili naziv grupe koji konfigurirani SAML atribut grupe doista nosi. Kopirajte vrijednost iz assertion-a ili iz pretrage imenika, ne s wiki stranice.
IAM grupa je druga kontrolna ravnina. Dopuštenje za administraciju endpointa Client VPN ne čini IAM grupu korisnikovom VPN grupom, a lijepljenje naziva IAM grupe u polje access-group ne pretvara ga u AD SID ni u vrijednost SAML atributa.
Grupa sličnog naziva u drugom imeniku ne dokazuje ništa. Provjerite način autentifikacije endpointa i korisnikovo članstvo ili assertion u tom istom sustavu.
Najduži prefiks pobjeđuje, uključujući 0.0.0.0/0
Autorizacija se ocjenjuje prema najduljem podudaranju prefiksa, a pravilo za sva odredišta ocjenjuje se posljednje, ne prvo. Dodajte pravilo 10.46.0.0/16 za Engineering i pravilo 0.0.0.0/0 za sve, i korisnik izvan Engineeringa ipak ne može dosegnuti 10.46.20.10 kroz široko pravilo.
Ovdje popravak može poći po zlu. Brisanje uskog pravila vraća korisnikov pristup i također dodjeljuje tu podmrežu svakom identitetu obuhvaćenom širokim pravilom. Izradite matricu grupa i mreža prije nego išta obrišete i zapišite koje grupe trebaju dosezati koji raspon. Ta pravila samo dopuštaju; nema unosa za zabranu kojim biste izrezali iznimku iz širokog dopuštenja.
Promjene također traže novu vezu da bi se pošteno ocijenile. Ponovno spojite klijent nakon uređivanja pravila, pa testirajte opet.
Odvojite autorizaciju od putanje podataka
Pravilo koje se podudara nije ruta. Endpoint treba pridruženu podmrežu i unos u tablici usmjeravanja za odredište, a sigurnosna grupa ciljnog resursa mora prihvatiti promet. Povratni promet i DNS također moraju raditi.
Testirajte korisnika koji bi trebao uspjeti i korisnika koji bi trebao ostati izuzet. Oboje se mogu prijaviti, ali samo jedan doseže podmrežu, i ta razlika je dokaz koji tražite.
Ako IP adresa radi, a naziv hosta ne, pogledajte resolver prije nego dirate autorizaciju. Ako nijedna ruta ne pokriva adresu, popravite pridruživanje ili tablicu usmjeravanja. Ako paket stigne i servis ga odbije, politika tog servisa je sljedeća stanica. Proširivanje matrice autorizacije na sve korisnike skriva koji je od tih slojeva zapravo bio pokvaren.
Prije zatvaranja tiketa zabilježite izvor identiteta, točnu vrijednost grupe, prefikse odredišta i rutu koja nosi promet. Taj zapis pretvara sljedeću prijavu o spojenosti bez pristupa u usporedbu od dvije minute umjesto još jedne runde nagađanja.