Rregullat e AWS Client VPN i përkasin burimit, jo nënrrjetit
Një nënrrjet i dytë nuk kufizon një port. Vendosni rregullin në grupin e sigurisë së burimit dhe përdorni grupin e shoqërimit të endpoint-it si origjinë.
Stafi duhet të arrijë një aplikacion në VPC dhe nuk duhet të arrijë dëgjuesin e bazës së të dhënave në të njëjtin instancë, kështu që dikush shton një nënrrjet të dytë publik për endpoint-in e VPN-së dhe e shpall kërkesën të plotësuar. Vendosja e nënrrjetit ndryshon rrugëtimin dhe disponueshmërinë. Nuk jep dhe nuk mohon asnjë port të vetëm. Leja që shpreh kërkesën jeton në destinacion, në grupin e sigurisë së burimit, dhe kufiri i VPN-së siguron dorezën të cilës i referohet ai rregull.
Vendosja e nënrrjetit është rrugëtim, jo autorizim
Ku ndodhet shoqërimi i rrjetit të endpoint-it përcakton cila tabelë rrugëtimi mbart trafikun e klientëve dhe cilat zona disponueshmërie i mbijetojnë një dështimi. Nuk thotë asgjë për cilën portë në cilën instancë mund të arrijë ai trafik. Dy klientë të shoqëruar me të njëjtin nënrrjet vijnë përsëri me të njëjtin identitet origjine, dhe burimi nuk mund t'i dallojë ata sipas emrit të nënrrjetit.
Filloni nga kërkesa: kush telefonon, cili burim, cila portë shërbimi dhe cili drejtim. Pastaj zgjidhni modelin e rregullit që mund t'i shprehë ato katër gjëra në destinacion. Ky këndvështrim zakonisht e heq nënrrjetin shtesë plotësisht nga projektimi.
Grupi i shoqërimit i Client VPN është doreza
Për një endpoint AWS Client VPN të shoqëruar me nënrrjet, rregullimi i dokumentuar është konkret. Zbato grupin e synuar të sigurisë në shoqërimet e rrjetit objektiv të endpoint-it, pastaj lejo trafikun e nevojshëm në grupin e sigurisë së burimit duke përdorur atë grup Client VPN si origjinë.
Konkretisht, grupi i instancës së aplikacionit lejon portën e aplikacionit nga grupi i shoqërimit, dhe asgjë tjetër. Procedura e aksesit në burim e AWS përshkruan atë marrëdhënie, dhe ia vlen të mbahet e njëjta politikë grupi në çdo nënrrjet me të cilin endpoint-i shoqërohet, sepse një shoqërim i vjetëruar me një grup tjetër e zgjeron kufirin në heshtje.
Ai rregull nuk vërteton askënd. Hyrja është një kontroll i veçantë, dhe rruga drejt burimit është e treta. Të tre duhet të jenë të vërteta para se të mbërrijë një kërkesë. Cili dështon përcakton cila korrigjim është i saktë, dhe ndryshimi i rregullit është përgjigja e saktë vetëm për të parin.
Çfarë nuk mund të dallojë një grup i vetëm shoqërimi
Çdo klient pas të njëjtit grup shoqërimi arrin burimin si i njëjti origjinë e grupit të sigurisë. Dy përdorues me role të ndryshme janë të padallueshëm në atë shtresë, pavarësisht si quhet ose etiketohet grupi. Autorizimi i grupeve të jashtme në Client VPN kufizon aksesin sipas parashtesës së destinacionit për një grup drejtorie ose SAML, që është më i trashë se një rol burimi dhe duhet trajtuar si kufi rrjeti, jo si sistem identiteti.
Dallimet më të imta i përkasin aplikacionit. Një dëgjues i bazës së të dhënave që duhet të mbetet i mbyllur për pjesën më të madhe të stafit mbrohet më mirë duke mos qenë fare i arritshëm në parashtesën e lejuar sesa duke shpresuar se anëtarësia në grup mbetet e rregullt.
Riemërtimi i grupit nuk krijon identitet, dhe dublikimi i tij për çdo ekip vetëm sa shton shoqërimet që duhen audituar.
Mos e kopjoni atë rregull në çdo projekt VPN
Një portë EC2 VPN e vetëmenaxhuar, një pajisje inspektimi e rrugëtuar dhe një Client VPN i menaxhuar janë tre rrugë të ndryshme paketash. Përcaktoni cila adresë origjine arrin vërtet në burim, nëse ndodh përkthim në mes dhe cilat mekanizma referimi mbështet shërbimi në atë rrugë.
Kalimi i trafikut nëpërmjet një pajisjeje ndërmjetëse nuk e ruan një referencë të grupit të sigurisë së origjinës ashtu si e bën trafiku i drejtpërdrejtë mes instancave. AWS dokumenton se projektime të tilla mund të kenë nevojë për adresat private të origjinës ose CIDR-të e duhura në vend të një reference grupi. Procedura e Client VPN të menaxhuar nuk është provë që grupi i bashkangjitur i çdo porte funksionon si shenjë identiteti universale për paketat e përcjella.
Një hop NAT në rrugë mjafton për të thyer supozimin, dhe dështimi duket si një rregull që ekziston por nuk përputhet kurrë.
Rishikoni kufirin efektiv
Lexoni çdo grup sigurie të bashkangjitur burimit, sepse rregullat e lejimit kombinohen dhe një rregull i ngushtë nuk e anulon një më të gjerë në një grup tjetër. Pastaj kontrolloni ACL-në e rrjetit, firewall-in e hostit dhe autorizimin e vetë aplikacionit, që janë shtresa të veçanta me gabime të veçanta.
Përfundoni me një kërkesë të lejuar dhe një kërkesë të përjashtuar qëllimisht ndaj të njëjtit burim. Çifti dëshmon kufirin, ndërsa një lidhje e suksesshme e vetme dëshmon vetëm se diçka është e hapur. Konfirmoni rrugën, origjinën efektive dhe portën e synuar të shërbimit, jo nënrrjetin që përmban endpoint-in.
Rendi i punës: shkruani kërkesën në katër pjesë, bashkangjitni grupin shoqërimeve, kufizoni rregullin e burimit në portë, verifikoni një leje dhe një refuzim, dhe vetëm pastaj merrni parasysh ndarjen e nënrrjeteve për arsye rrugëtimi.