AWS Client VPN-reëls hoort by die bron, nie by die subnet nie

Personeel moet een toepassing in die VPC kan bereik en mag nie die databasis-listener op dieselfde instansie bereik nie, so iemand voeg 'n tweede openbare subnet vir die VPN-eindpunt by en sê die vereiste is nagekom. Subnetplasing verander roetering en beskikbaarheid. Dit gee of weerhou nie 'n enkele poort nie. Die toestemming wat die vereiste uitdruk, lê by die bestemming, in die bron se sekuriteitsgroep, en die VPN-grens verskaf die handvatsel waarna daardie reël verwys.

Subnetplasing is roetering, nie magtiging nie

Waar die eindpunt se netwerkkoppeling sit, bepaal watter roetetabel die kliëntverkeer dra en watter beskikbaarheidsones 'n fout oorleef. Dit sê niks oor watter poort op watter instansie daardie verkeer mag bereik nie. Twee kliënte wat met dieselfde subnet geassosieer is, kom steeds met dieselfde bronidentiteit aan, en die bron kan hulle nie aan die subnetnaam onderskei nie.

Begin eerder by die vereiste: wie roep, watter bron, watter dienspoort en watter rigting. Kies dan die reëlmodel wat daardie vier dinge by die bestemming kan uitdruk. Daardie benadering verwyder gewoonlik die ekstra subnet heeltemal uit die ontwerp.

Die Client VPN-koppelingsgroep is die handvatsel

Vir 'n subnet-geassosieerde AWS Client VPN-eindpunt is die gedokumenteerde reëling spesifiek. Pas die bedoelde sekuriteitsgroep op die eindpunt se teikennetwerk-koppelings toe en laat dan die vereiste verkeer in die bron se sekuriteitsgroep toe deur daardie Client VPN-groep as die bron te gebruik.

Konkreet: die toepassingsinstansie se groep laat die toepassingspoort vanaf die koppelingsgroep toe, en niks anders nie. AWS se prosedure vir brontoegang beskryf daardie verhouding, en dit is die moeite werd om dieselfde groepbeleid te handhaaf oor elke subnet waarmee die eindpunt assosieer, want 'n verouderde koppeling met 'n ander groep verbreed die grens stilweg.

Daardie reël verifieer niemand nie. Aanmelding is 'n aparte beheer, en die roete na die bron is 'n derde een. Al drie moet geld voordat 'n versoek aankom. Watter een ook al faal, bepaal watter regstelling korrek is, en 'n reëlverandering is slegs vir die eerste die regte antwoord.

Wat een koppelingsgroep nie kan onderskei nie

Elke kliënt agter dieselfde koppelingsgroep bereik die bron as dieselfde sekuriteitsgroepbron. Twee gebruikers met verskillende rolle is op daardie vlak nie onderskeibaar nie, maak nie saak hoe die groep genoem of gemerk is nie. Client VPN se eksterne-groepmagtiging beperk toegang per bestemmingsvoorvoegsel vir 'n gids- of SAML-groep, wat growwer is as 'n bronrol en as 'n netwerkgrens eerder as 'n identiteitstelsel beskou moet word.

Fyner onderskeidings hoort by die toepassing. 'n Databasis-listener wat vir die meeste personeel gesluit moet bly, word beter beskerm deur glad nie op die toegelate voorvoegsel bereikbaar te wees nie as deur te hoop dat die groep se lidmaatskap netjies bly.

Om die groep te hernoem skep nie 'n identiteit nie, en om dit per span te dupliseer vermenigvuldig net die koppelings wat geouditeer moet word.

Moet nie daardie reël na elke VPN-ontwerp kopieer nie

'n Selfbestuurde EC2 VPN-gateway, 'n geroteerde inspeksietoestel en bestuurde Client VPN is drie verskillende pakketroetes. Stel vas watter bronadres die bron werklik bereik, of vertaling tussenin plaasvind, en watter verwysingsmeganismes die diens op daardie roete ondersteun.

Om verkeer deur 'n middlebox te stuur, behou nie 'n sekuriteitsgroepverwysing vir die bron soos direkte instansie-tot-instansie-verkeer nie. AWS dokumenteer dat sulke ontwerpe eerder die toepaslike private bronadresse of CIDR's as 'n groepverwysing nodig kan hê. Die prosedure vir bestuurde Client VPN is nie bewys dat elke gateway se aangehegte groep as 'n universele identiteitstoken vir geforwardeerde pakkette werk nie.

'n NAT-hop op die roete is genoeg om die aanname te breek, en die fout lyk soos 'n reël wat teenwoordig is maar nooit pas nie.

Hersien die effektiewe grens

Lees elke sekuriteitsgroep wat aan die bron geheg is, want toelaatreëls kombineer en 'n eng reël kanselleer nie 'n breër een op 'n ander groep nie. Kyk dan na die netwerk-ACL, die gasheervuurmuur en die toepassing se eie magtiging, wat aparte lae met aparte foute is.

Sluit af met een toegelate versoek en een doelbewus uitgeslote versoek teen dieselfde bron. Die paar bewys die grens, terwyl 'n enkele suksesvolle verbinding net bewys dat iets oop is. Bevestig die roete, die effektiewe bron en die bedoelde dienspoort eerder as die subnet wat die eindpunt bevat.

Werkorde: skryf die vierdelige vereiste neer, heg die groep aan die koppelings, beperk die bronreël tot die poort, verifieer een toelating en een weiering, en oorweeg eers daarna om subnette vir roeteringsredes te verdeel.