Amazon kimenő forgalom egy IP címen át

Tudtok javasolni leírást arról, hogy azt hogyan érdemes megoldani, hogy ha van több (2-3) amazonos (EC2) virtuális gép, azonos funkcionalitással, akkor ne a bemenő forgalmat (mert arra van load balancer), hanem a kimenő forgalmat egyetlen IP címen keresztül tudjuk kivezetni? (Nem vagyok nagy spiller efféle ügyekben, úgyhogy lehet, hogy ez alapvető kérdés; mintha a NAT gateway témához lenne köze.)

Hozzászólások

VPC-ben vannak az EC2-k? Szerintem kell egy VPC privát subnettel és egy NAT gateway amihez hozzárendelsz egy IP-t, és kell egy public subnet a load balancernek ahol eléri az internet gatewayt.

"Everything fails, all the time."

Igen, azonos VPC ID-jük van. Köszi!

Az oké, de arra gondoltam fentebb, hogy a default vpc-ben vannak, vagy csináltál egy külön custom vpc-t? Ha a defaultban vannak, akkor előbb érdemes csinálni egy custom vpc-t a subnetekkel, route táblával, balancerrel, satöbbi. Aztán a custom vpc-be áttenni az ec2-ket.

"Everything fails, all the time."

Ugye azt jól gondolom, hogy a load balancereket nem szokás arra használni, hogy több, egészen eltérő URL-t is egyetlen load balancer mögé tegyünk? (Pontosabban: attól nem fogjuk megúszni kevesebb tanúsítvánnyal, hogy több szervert is bepakolunk egyetlen load balancer mögé?)

attol fugg. pl;

ha az  ssl terminalas a loadbalanceren tortenik es a tobbi komponens kozott onalairt tanusitvanyokal megy a hitelesites akkor 1db megvasarolt/letsencryptes cert kell csak aminek a teljes tanusito lanca a user bongeszojeben is ott kell legyen.

https://goo.gl/muWzKz (digitalocean)

Szuper. Ha jól értem, akkor: ha az ssl terminálás a load balanceren történik, akkor a load balancer/többi komponens között lehet önaláírt tanúsítványokkal a kapcsolat. (Esetleg van valami white paper vagy egyéb összefoglaló, nem túl részletekbe menő leírás e témáról?) Az teljesen kizárt, hogy a többi komponens felé is ugyanaz a tanúsítvány működjön, mint ami a load balanceren van?

Első kérdésre a válasz:igen.

De ettől függetlenül a cert-et a kiszolgált domainre kéred (mondjuk letsencrypt-el akár full ingyen és full automatán).

Tehát n darab cert kell, ezt persze egyetlen revproxy is tudja terminálni, n darab virtualhosttal (apache terminológia szerint)

Gábriel Ákos

Ha pl. van minden AZ-ben 1 privát subnet akár 1 NAT gateway is képes ellátni a kimenő forgalmat de nem célszerű. Mi mindig csinálunk 1 Internet gateway-t mind a 3 publikus subnethez, és külön NAT gateway-t minden privát subnethez (per AZ) 

Mi 1 ALB-t használunk rengeteg backend szerverhez de a tanúsítványnak ehhez sok köze nincs. Ha nem akarsz sokat kezelni akkor wildcard vagy SAN (multi domain) tanúsítvány kell 

https://aws.amazon.com/blogs/aws/new-application-load-balancer-sni/

egyrészt használhatsz wildcardos certet, másrészt egy certet több load balancerrel is használhatsz, így ha a terhelés/logikai szeparáció indokolja akkor pl. külön subdomain-eken levő szolgáltatásoknak lehet külön-külön load balancere úgy, hogy egy darab certed van.

Szerkesztve: 2020. 04. 09., cs - 19:14

Nem nyitok új szálat, ha nem baj, mert lazán kapcsolódik: egy VPC-n belül van több subnetem (public, private, és olyan private amin van nat gw), van olyan EC2 instance aminek 2db interfésze van az alábbiak szerint:

eth0 - public (itt kap egy EIP-et is)

eth1 - private (natgw _nélküli_)

A VPC dhcp-jétől az eth1 is kap def. gw-t valamiért, amitől így néz ki a route tábla:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.2.2.1        0.0.0.0         UG    100    0        0 eth1
0.0.0.0         10.2.0.1        0.0.0.0         UG    100    0        0 eth0

...

Ez nyilván fejbe is veri a public/eth0 forgalmát, és ezzel a külső kapcsolatot. Ez érthető is, és ezer megoldás van rá, hogy OS szinten kezeljem. Én a mellett döntöttem, hogy az eth1-nél a dhcp default route opcióját nem veszem figyelembe, és ezzel persze a probléma meg is van oldva.

Viszont nem akarok erre minden gépnél figyelni, illetve kicsit zavar, hogy VPC szinten nem értem a dolog működését. Szóval a kérdés valójában az, hogy aws VPC/dhcp (vagy inkább VPC/route table?) szinten miért történik ez a dolog, és lehet e ellene tenni?

Van ugye egy IGW-m is, ami látszólag nincs az említett privát subneten (nincs edge assosciation). Viszont úgy sejtem, hogy az IGW az VPC szintű szolgáltatás, azaz tökmindegy, hogy van e edge assoc., vagy hogy van e 0.0.0.0/0 -s route bejegyzés subnet route táblájában (egyébként nyilván nincs). Szóval ha egy VPC-n van IGW, akkor ha tetszik, ha nem, minden benne létrehozott subnetben lesz default gw a dhcp optionben. Jól gondolom?

Azt hiszem maga a design a hibás: VPC-n belüli subnetek összekötése miatt teljesen felesleges két lábú EC2 instrance-eket csinálni, a VPC routerén keresztül mindenki lát mindenkit úgyis, az izolációt pedig security groupokkal/network ACL-ekkel kell megoldani. Így a kérdéses EC2 gépen is csak 1db interface lenne (a public), szóval a kérdésnek ez esetben nincs relevanciája. Jól értem, hogy ez lenne a best practice erre a felállásra?