înregistrare Logare
Puncte:1
avatar Server

Restricționarea traficului între VPC-urile AWS

drapel za
Ralf

Am două VPC-uri: A și B.

Vreau ca orice nod din A să poată deschide o conexiune TCP la orice nod din B, dar nu invers. Orice nod din B trebuie, de asemenea, să poată deschide conexiuni de ieșire la gazdele publice de internet. Care este cel mai bun mod de a realiza acest lucru?

Caz de utilizare: VPC A conține multe servicii interne sensibile, iar VPC B conține noduri care rulează cod complet neîncrezat. VPC A trebuie să facă solicitări HTTP către VPC B, dar niciunul dintre serviciile interne nu trebuie să fie expus.

Peering-ul VPC permite conexiuni directe între orice noduri din A și B - acest lucru nu poate fi restricționat la nivel de rutare. Grupurile de securitate pot fi folosite pentru a bloca conexiunile de ieșire, dar este ușor de configurat, deoarece nu există nicio regulă DENY.

ACL-urile de rețea nu sunt utile aici, deoarece traficul de retur trebuie permis înapoi de la B -> A.

Există alte opțiuni? Ceva de genul unui gateway NAT, care permite doar deschiderea conexiunilor într-o singură direcție? AWS acceptă gateway-uri NAT private, dar nu găsesc nicio documentație pentru o configurație ca aceasta.

86
0 + 0
Puncte:3
Tim avatar Server
drapel gp
Tim

Nu ți-am citit răspunsul în detaliu, dar mi se pare un pic neplăcut. Nu știu deloc de ce utilizați gateway-uri NAT, acestea sunt doar pentru a permite instanțelor din subrețea privată să acceseze internetul.

O cheie aici este comunicarea cu o singură direcție, care sugerează cu tărie că grupurile de securitate sunt răspunsul. Soluția mea (fără să mă gândesc prea mult ar fi):

  • Peering VPC între cele două VPC-uri, intervale CIDR diferite
  • Tabel de rutare în ambele VPC-uri pentru a activa comunicațiile
  • Grupuri de securitate din VPC A pentru a permite traficul de ieșire către intervalele CIDR VPC B, dar nu și de intrare. Acest lucru va permite traficul de ieșire și traficul de întoarcere, dar nu și traficul inițiat în VPC A
  • Grupurile de securitate din VPC B permit traficul de intrare de la VPC A CIDR, dar nu permit traficul de ieșire. Acest lucru permite traficului să intre și îl permite să revină, dar nu permite traficului inițiat în A să ajungă la B
  • Gateway de internet în VPC B. Dacă nu aveți nevoie de internet pentru a accesa VPC B, atunci puteți utiliza un gateway NAT în VPC B.
0 + 0
drapel za
Ralf
Cea mai dificilă parte din această configurare este „Grupurile de securitate din VPC B permit traficul de intrare de la VPC A CIDR, dar nu permit ieșirea”. Trebuie să permit traficul de ieșire către internetul public de la VPC B, dar nu către VPC A. Deoarece nu există reguli „DENY” în grupurile de securitate, am soluția de a permite traficul de ieșire către o listă de 33 de blocuri CIDR care _ar trebui_ acoperă întregul acces public la internet. Gateway-urile NAT par să funcționeze perfect pentru traficul intern, chiar dacă nu este o configurare obișnuită.
0
Răspunde
Tim avatar
drapel gp
Tim
Vă sugerez cu tărie să faceți niște instruire AWS sau cel puțin să citiți despre grupurile de securitate. Acesta nu este un scenariu dificil, l-ați rezolvat într-un mod destul de bizar, care poate avea repercusiuni și vă va costa mai mult în taxe de date / NAT. Sunt destul de bine instruit / certificat / cu experiență cu AWS. Habar nu aveam că un gateway NAT ar putea face altceva decât să ofere acces la internet subrețele private - se pare că îl folosiți pentru a ocoli natura netranzitivă a AWS VPC. Aceasta este într-adevăr o problemă simplă și poate fi rezolvată cu o soluție simplă.
0
Răspunde
drapel za
Ralf
Gateway-ul NAT adaugă cheltuieli generale și costuri (neglijabile pentru acest caz de utilizare). Poate fi neconvențional, dar adaugă opțiuni pentru straturi suplimentare de securitate la nivel de subrețea, în loc de doar grupuri de securitate. În același mod, în scenariile mai tipice în care ați putea folosi o subrețea publică și o puteți proteja cu grupuri de securitate, obțineți o izolare mai bună cu subrețele private + gateway NAT pentru acces la internet. Același lucru este valabil și aici în mare măsură.
0
Răspunde
Tim avatar
drapel gp
Tim
Ok, orice funcționează pentru tine. Poate țineți minte că nu am auzit niciodată despre NAT Gateway să fie folosit așa înainte și pot exista dezavantaje care nu sunt evidente. Nu folosești cu adevărat cele mai bune practici, dar dacă funcționează pentru tine, grozav.
0
Răspunde
Puncte:0
avatar Server
drapel za
Ralf

Se pare că acest lucru poate funcționa prin adăugarea unui gateway NAT privat într-o subrețea dedicată.

Această configurație pare să funcționeze:

VPC A: 10.1.0.0/16

Subrețea A1: 10.1.1.0/24. Subrețeaua principală care conține nodurile din A.
Subrețea A2: 10.1.2.0/24. Subrețea dedicată pentru gateway-ul NAT.

VPC B: 10.2.0.0/16

Subrețea B1: 10.2.3.0/24: Subrețea principală care conține nodurile din B.

Gateway NAT privat în subrețeaua A2. (nat-1)
Peering VPC între VPC A și B. (pcx-1)

Tabel de rute pentru A1:

10.1.0.0/16 (A): local
10.2.3.0/24 (B1): nat-1

Tabel de rute pentru A2:

10.1.0.0/16 (A): local
10.2.3.0/24 (B1): pcx-1

Tabel de rute pentru B1:

10.2.0.0/16 (B): local
10.1.2.0/24 (A2): pcx-1

Deoarece nu există o rută directă între A1 și B1, tot traficul trebuie să treacă prin poarta NAT.Și gateway-ul NAT permite doar conexiuni de intrare de la același VPC, așa că nu există nicio modalitate ca un nod din B1 să deschidă o conexiune la un nod din A1.

Grupurile de securitate și ACL-urile de rețea pot fi folosite ca straturi suplimentare de securitate aici, iar configurația ar fi destul de simplă cu această împărțire în subrețele. Dar ar fi și redundant, deoarece nu există nicio rută de la B1 la A1.

0 + 0
Oscar De León avatar
drapel la
Oscar De León
Dacă nu există nicio rută de la B la A, atunci nu veți primi date de întoarcere. „Nu va ști unde să meargă”. Răspunsul lui Tim este corect.
0
Răspunde
drapel za
Ralf
Nu există nicio rută _directă_ de la B1 la A1. Există o rută de la B1 la A2, iar traficul de întoarcere trece înapoi prin acel gateway NAT.
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.