Fórumok
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."
Egy külön (nem default) vpc-ben vannak. (Nem én csináltam amúgy őket.) Ami talán zavaró lesz, az az, hogy a subnet-jük nem azonos.
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.
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?
ha technikailag megoldhato is szerintem nem praktikus, hiszen ket lehetoseged lenne;
- felsorolni minden hostot a tanusítványban (web felol info leak, folosleges plusz komplexitas es es kotottseg)
- wildcard
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/
Köszii!
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.
Delete, közben rájöttem, hogy hülyeséget kérdeztem :)
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?
jól