Mám službu běžící na určitém portu na instanci EC2 v privátním IP rozsahu.
Chtěli bychom, aby třetí strana (zákazník) mohla s touto hostitelskou službou komunikovat přes site-to-site VPN ze svého prostředí.
Samozřejmě problém je, že nemohou integrovat náš privátní rozsah do své sítě, a tak nám doporučili zpřístupnit naši službu v rámci sdíleného adresního rozsahu.
Mé počáteční zkoumání mě vedlo k myšlence, že by mohlo jít o špatnou cestu – Privátní NAT Gateway – protože to vypadá, že je vhodnější pro odchozí spojení, maskování mé privátní adresy a vypadalo by, že klient vidí adresu NAT Gateway. Některé články také naznačily potřebu Transit Gateway mezi VPC a Site-to-Site VPN.
Zdá se, že nejvíce slibným řešením je provoz v Load Balanceru v jiné podsíti s CIDR v sdíleném rozsahu a přesměrování portu na mou EC2 instanci v jiné privátní podsíti. Tímto způsobem má NLB v rozsahu sdílené adresy, ale může být směrován na EC2 instanci v její privátní podsíti.
Další možnosti:
- Místo Network Load Balanceru může být provozován malý NAT/Firewall appliance nebo EC2 instance určená pro přesměrování portů přes iptables
- AWS Private Link – nakonec mě zajímá, jestli je toto jednodušší a levnější řešení, lze se vzdát site-to-site VPN apod. Nevím přesně, co by toto řešení vyžadovalo
- Je Network Load Balancer správný nástroj, nebo by Gateway Load Balancer byl správnější?
- jiní…?
Mám podezření, že AWS Private Link by mohl být nejjednodušší/nejlevnější řešení, ale vzhledem k tomu, že toto pravděpodobně nebude poslední případ, kdy budu řešit tento problém, snažím se rozumně rozhodnout mezi přístupy.
Další úvahy – mám také určitá požadavky na odolnost, protože chci, aby služba byla dostupná i v záložní oblastiAvailability Zone pokud bude potřeba. A také náklady.
Jak byste vyřešili problém zpřístupnění služby v privátním CIDR prostřednictvím sdíleného CIDR aby byla dostupná přes site-to-site VPN?
Je sítě vašeho zákazníka na AWS?
NLB zní jako dobrý přístup, ale Private Link by mohl být jednodušší a levnější.
Pokud má zákazník AWS, doporučený přístup je použít Private Link a umožnit jejich AWS účtu využívat službu koncové bodové služby Private Link. To by udrželo přístup zcela soukromý.
Pokud nemají AWS, máte několik možností:
- ověřený přístup AWS
- zpřístupnit aplikaci z internetu pomocí veřejného proxy (load balancer, cloud front atd).
Rozdíl mezi těmito možnostmi je opravdu ve správě proxy a zabezpečení od AWS nebo vlastnoručně.
Myslím, že mají přítomnost na AWS, zmínili možnost použití Private Link.
Mám dojem, že možná stále budu potřebovat NLB nebo GLB, aby poskytly VPC Endpoint Service pro připojení Private Link. Jakékoliv osvícení by bylo vítáno.
Pokud je zákazníkova síť na AWS, nejvhodnější je PrivateLink. Máte NLB před EC2 a zaregistrujete NLB do nové VPC endpoint služby. Politika endpointu může specifikovat ID účtů, aby omezila, které účty se mohou připojit. Také můžete přijmout jejich žádost o připojení dříve, než bude navázáno spojení. Vytvoří si VPC endpoint cílení na vaše jméno služby endpointu. Podle vzpomínek je potřeba, aby SG NLB povolovalo příchozí spojení z IP adres služby endpointu.
Další vhodná možnost je VPC Lattice, i když jsem ji ještě nevyzkoušel. Mělo by umožnit přesné směrování mezi zdrojovými pracovními zatíženími ve dvou odlišných VPC, patřících různým účtům, dokonce i napříč Organizacemi. Umožňuje směrovat specifický provoz bez propojení VPC (TGW, VPC peering, VPGW) a obejít NACL. Regule SG stále platí, i když nejsem jistý, co to přesně znamená.
Pokud nejste na AWS, je vhodnou volbou site-to-site VPN, pokud chcete zpřístupnit službu na internetu i s omezením na veřejnou IP adresu zákazníka nebo nějakým ověřovacím workflow. Nicméně, VPN odhalí více na soukromé úrovni, je tedy potřeba více zabezpečit pomocí statických rout, NACL, omezení SG jiných služeb, nebo jak jste zmínil, vytvořením nového NLB ve nové VPC, ale pak bude potřeba směrovat mezi NLB VPC a VPC s pracovní zátěží. Toto činí PrivateLink podstatně elegantnější.