Dlaczego potrzebujemy prywatnej podsieci w VPC?

Istnieją 4 scenariusze w konfiguracji AWS VPC. Ale spójrzmy na te dwa:

• Scenariusz 1: 1 podsieć publiczna.
• Scenariusz 2: 1 podsieć publiczna i 1 podsieć prywatna.

Ponieważ żadna instancja uruchomiona w podsieci publicznej nie ma EIP (chyba że jest przypisana), nie można jej już adresować z Internetu. Następnie:

• Dlaczego potrzebna jest prywatna podsieć?
• Jakie dokładnie są różnice między podsieciami prywatnymi i publicznymi?

Aktualizacja: pod koniec grudnia 2015 r. AWS ogłosił nową funkcję - zarządzaną bramę NAT dla VPC . Ta opcjonalna usługa zapewnia alternatywny mechanizm dostępu do Internetu dla instancji VPC w prywatnej podsieci, podczas gdy wcześniej typowym rozwiązaniem była instancja EC2 w publicznej podsieci w ramach VPC, działająca jako „instancja NAT”, zapewniająca translację adresów sieciowych ( technicznie, translacja adresów portów ) dla instancji w innych, prywatnych podsieciach, umożliwiając tym maszynom używanie publicznego adresu IP instancji NAT do wychodzącego dostępu do Internetu.

Nowa zarządzana usługa NAT nie zmienia zasadniczo zastosowania następujących informacji, ale ta opcja nie jest uwzględniona w poniższej treści. Wystąpienie NAT może być nadal używane zgodnie z opisem lub zamiast tego można udostępnić usługę zarządzanej bramy NAT. Rozszerzona wersja tej odpowiedzi, zawierająca więcej informacji o bramie NAT i jej porównaniu z instancją NAT, będzie wkrótce dostępna, ponieważ są one istotne dla paradygmatu podsieci prywatnej / publicznej w VPC.

Zauważ, że bramka internetowa i bramka NAT to dwie różne funkcje. Wszystkie konfiguracje VPC z dostępem do Internetu będą miały wirtualny obiekt bramy internetowej.

Zrozumienie różnicy między „prywatnymi” a „publicznymi” podsieciami w Amazon VPC wymaga zrozumienia ogólnego sposobu działania routingu IP i translacji adresów sieciowych (NAT) oraz sposobu ich implementacji w VPC.

Podstawowe rozróżnienie między publiczną i prywatną podsiecią w VPC jest definiowane przez domyślną trasę tej podsieci w tabelach routingu VPC.

Ta konfiguracja z kolei decyduje o ważności używania lub nieużywania publicznych adresów IP w instancjach w tej konkretnej podsieci.

Każda podsieć ma dokładnie jedną trasę domyślną, która może być tylko jedną z dwóch rzeczy:

• obiekt VPC „Internet Gateway” w przypadku „publicznej” podsieci lub
• urządzenie NAT - czyli albo bramka NAT, albo instancja EC2, pełniąca rolę „instancji NAT” w przypadku „prywatnej” podsieci.

Internet Bramka nie robić żadnych translacji adresów sieciowych dla instancji bez publicznych adresów IP tak instancją bez publicznego adresu IP nie można podłączyć zewnętrzny do Internetu - aby robić takie rzeczy jak pobieranie aktualizacji oprogramowania lub dostępu do innych zasobów AWS jak S3 ¹ i SQS - jeśli domyślną trasą w jego podsieci VPC jest obiekt bramy internetowej. Tak więc, jeśli jesteś instancją w „publicznej” podsieci, potrzebujesz publicznego adresu IP, aby wykonać znaczną liczbę rzeczy, które zwykle muszą robić serwery.

W przypadku instancji z tylko prywatnym adresem IP istnieje alternatywny sposób dostępu wychodzącego do Internetu. Tutaj właśnie wkracza Network Address Translation² i instancja NAT.

Maszyny w prywatnej podsieci mogą uzyskać dostęp do Internetu, ponieważ domyślną trasą w prywatnej podsieci nie jest obiekt VPC „Internet Gateway” - jest to instancja EC2 skonfigurowana jako instancja NAT.

Instancja NAT to instancja w publicznej podsieci z publicznym adresem IP i określoną konfiguracją. Istnieją AMI, które są gotowe do tego, lub możesz zbudować własne.

Gdy komputery z adresami prywatnymi wysyłają ruch na zewnątrz, ruch jest wysyłany przez VPC do instancji NAT, która zastępuje źródłowy adres IP w pakiecie (prywatny adres IP maszyny prywatnej) własnym publicznym adresem IP, wysyła ruch do Internetu, przyjmuje pakiety odpowiedzi i przekazuje je z powrotem na prywatny adres maszyny źródłowej. (Może również przepisać port źródłowy, aw każdym razie pamięta mapowania, więc wie, która maszyna wewnętrzna powinna otrzymywać pakiety odpowiedzi). Instancja NAT nie pozwala żadnemu „nieoczekiwanemu” ruchowi przychodzącemu na dotarcie do instancji prywatnych, chyba że zostało to specjalnie skonfigurowane.

Tak więc podczas uzyskiwania dostępu do zewnętrznego zasobu internetowego z prywatnej podsieci ruch przechodzi przez instancję NAT i wydaje się, że do miejsca docelowego pochodzi z publicznego adresu IP instancji NAT ... więc ruch odpowiedzi wraca do instancji NAT. Ani grupa zabezpieczeń przypisana do wystąpienia NAT, ani grupa zabezpieczeń przypisana do wystąpienia prywatnego nie muszą być skonfigurowane tak, aby „zezwalały” na ten ruch odpowiedzi, ponieważ grupy zabezpieczeń są stanowe. Zdają sobie sprawę, że ruch odpowiedzi jest skorelowany z sesjami utworzonymi wewnętrznie, więc jest automatycznie dozwolony. Nieoczekiwany ruch jest oczywiście odrzucany, chyba że grupa zabezpieczeń jest skonfigurowana tak, aby na to zezwalać.

W przeciwieństwie do konwencjonalnego routingu IP, w którym domyślna brama znajduje się w tej samej podsieci, sposób jej działania w VPC jest inny: instancja NAT dla dowolnej podsieci prywatnej jest zawsze w innej podsieci, a ta inna podsieć jest zawsze podsiecią publiczną, ponieważ instancja NAT musi mieć publiczny zewnętrzny adres IP, a jej domyślną bramą musi być obiekt VPC „Internet Gateway”.

Podobnie ... nie możesz wdrożyć instancji z publicznym adresem IP w prywatnej podsieci. To nie działa, ponieważ domyślna trasa w prywatnej podsieci jest (z definicji) instancją NAT (która wykonuje NAT w ruchu), a nie obiektem bramy internetowej (która nie działa). Ruch przychodzący z Internetu trafiałby na publiczny adres IP instancji, ale odpowiedzi próbowałyby skierować się na zewnątrz przez instancję NAT, co spowodowałoby porzucenie ruchu (ponieważ składałby się z odpowiedzi na połączenia, których nie jest świadomy, więc zostałby uznany za nieprawidłowy) lub przepisałby ruch odpowiedzi, aby używał własnego publicznego adresu IP, co nie działałoby, ponieważ źródło zewnętrzne nie akceptowałoby odpowiedzi pochodzących z adresu IP innego niż ten, z którym próbowali zainicjować komunikację .

W istocie zatem określenia „prywatne” i „publiczne” tak naprawdę nie dotyczą dostępności lub niedostępności z Internetu. Dotyczą one rodzajów adresów, które zostaną przypisane do instancji w tej podsieci, co jest istotne ze względu na potrzebę tłumaczenia - lub unikania tłumaczenia - tych adresów IP na potrzeby interakcji internetowych.

Ponieważ VPC ma niejawne trasy ze wszystkich podsieci VPC do wszystkich innych podsieci VPC, trasa domyślna nie odgrywa roli w wewnętrznym ruchu VPC. Instancje z prywatnymi adresami IP będą łączyć się z innymi prywatnymi adresami IP w VPC „z” ich prywatnego adresu IP, a nie „z” ich publicznego adresu IP (jeśli taki mają) ... o ile adres docelowy jest innym adresem prywatnym w ramach VPC.

Jeśli Twoje instancje z prywatnymi adresami IP nigdy, w żadnych okolicznościach, nie muszą generować wychodzącego ruchu internetowego, to technicznie mogą zostać wdrożone w „publicznej” podsieci i nadal będą niedostępne z Internetu ... ale w takiej konfiguracji, niemożliwe jest dla nich zainicjowanie ruchu wychodzącego w kierunku Internetu, który obejmuje połączenia z innymi usługami infrastruktury AWS, ponownie, jak S3 ¹ czy SQS.

^{1. W odniesieniu do S3, w szczególności stwierdzenie, że dostęp do Internetu jest zawsze wymagany, jest nadmiernym uproszczeniem, które z czasem będzie rosło i rozprzestrzeni się na inne usługi AWS, w miarę jak możliwości VPC będą nadal rosnąć i ewoluować. Istnieje stosunkowo nowa koncepcja zwana punktem końcowym VPCktóry umożliwia instancjom, w tym tym z tylko prywatnymi adresami IP, bezpośredni dostęp do S3 z wybranych podsieci w VPC, bez dotykania „Internetu” i bez używania instancji NAT lub bramy NAT, ale wymaga to dodatkowej konfiguracji i jest można używać tylko do uzyskiwania dostępu do zasobników w tym samym regionie AWS, co Twój VPC. Domyślnie S3 - która w chwili pisania tego tekstu jest jedyną usługą, która ujawniła możliwość tworzenia punktów końcowych VPC - jest dostępna tylko z wnętrza VPC przez Internet. Kiedy tworzysz punkt końcowy VPC, tworzy to listę przedrostków (pl-xxxxxxxx), których można użyć w tabelach tras VPC do wysyłania ruchu związanego z tą konkretną usługą AWS bezpośrednio do usługi za pośrednictwem wirtualnego obiektu „VPC Endpoint”. Rozwiązuje również problem ograniczenia dostępu wychodzącego do S3 dla konkretnej instancji, ponieważ lista prefiksów może być używana w wychodzących grupach zabezpieczeń zamiast docelowego adresu IP lub bloku - a punkt końcowy S3 VPC może podlegać dodatkowym oświadczeniom dotyczącym zasad , ograniczając dostęp do łyżki od wewnątrz, zgodnie z potrzebami.}

^{2. Jak zauważono w dokumentacji, tak naprawdę omawiamy tutaj translację portów i adresów sieciowych. Powszechne, choć technicznie nieco nieprecyzyjne, jest nazywanie połączonej operacji „NAT”. Jest to trochę podobne do sposobu, w jaki wielu z nas zwykło mówić „SSL”, kiedy w rzeczywistości mamy na myśli „TLS”. Wiemy, o czym mówimy, ale nie używamy najbardziej poprawnego słowa, aby to opisać. „Uwaga Używamy terminu NAT w tej dokumentacji, aby postępować zgodnie z powszechną praktyką IT, chociaż rzeczywistą rolą urządzenia NAT jest zarówno translacja adresów, jak i translacja adresów portów (PAT).”}

Sugerowałbym inny sposób - porzuć „prywatne” podsieci i instancje / bramy NAT. Nie są potrzebne. Jeśli nie chcesz, aby komputer był dostępny z Internetu, nie umieszczaj go w grupie zabezpieczeń, która umożliwia taki dostęp.

Rezygnując z instancji / bramy NAT, eliminujesz koszty eksploatacji instancji / bramy i eliminujesz ograniczenie prędkości (250 Mb lub 10 Gb).

Jeśli masz komputer, który również nie potrzebuje bezpośredniego dostępu do Internetu (i zapytałbym, jak go łatasz *), to jak najbardziej nie przypisuj publicznego adresu IP.

* Jeśli odpowiedzią tutaj jest jakiś rodzaj proxy, cóż, ponosisz koszty ogólne, ale każdy z nich jest dla siebie.

Nie mam reputacji dodawania komentarza do powyższej odpowiedzi Michaela, dlatego dodałem swój komentarz jako odpowiedź.

Warto zauważyć, że brama zarządzana przez AWS jest ~ 3 razy droższa niż dotychczas w porównaniu z uruchomieniem własnej instancji. Jest to oczywiście przy założeniu, że potrzebujesz tylko jednej instancji NAT (tj. Nie masz wielu instancji NAT skonfigurowanych do przełączania awaryjnego itp.), Co jest generalnie prawdziwe dla większości małych i średnich scenariuszy użycia. Zakładając miesięczny transfer danych 100 GB przez bramę NAT,

Miesięczny koszt zarządzanej instancji NAT = 33,48 USD / miesiąc (0,045 USD / godzinę * 744 godziny w miesiącu) + 4,50 USD (0,045 USD za GB przetworzonych danych * 100 GB) + 10 USD (0,10 USD / GB standardowych opłat za transfer danych AWS za wszystkie dane przesyłane przez Brama NAT) = 47,98 USD

Instancja t2.nano skonfigurowana jako instancja NAT = 4,84 USD / miesiąc (0,0065 USD * 744 godzin w miesiącu) + 10 USD (0,10 USD / GB standardowe opłaty za transfer danych AWS za wszystkie dane przesyłane przez instancję NAT) = 14,84 USD

To oczywiście zmienia się, gdy wybierasz nadmiarowe instancje NAT, ponieważ brama NAT zarządzana przez AWS ma wbudowaną nadmiarowość zapewniającą wysoką dostępność. Jeśli nie zależy Ci na dodatkowych 33 USD miesięcznie, zarządzana instancja NAT jest zdecydowanie warta zredukowanego bólu głowy związanego z brakiem konieczności utrzymywania innej instancji. Jeśli używasz instancji VPN (np. OpenVPN) w celu uzyskania dostępu do swoich instancji w ramach VPC, możesz po prostu skonfigurować tę instancję tak, aby działała także jako brama NAT, a wtedy nie musisz utrzymywać dodatkowej instancji tylko dla NAT ( chociaż niektórzy ludzie mogą krzywo patrzeć na pomysł połączenia VPN i NAT).

Odpowiedź Michaela - sqlbot zakłada niejawne założenie, że wymagane są prywatne adresy IP. Myślę, że warto zakwestionować to założenie - czy w ogóle musimy w ogóle używać prywatnych adresów IP? Przynajmniej jeden komentator zadał to samo pytanie.

Jaka jest zaleta serwera w prywatnej podsieci z instancją NAT [w porównaniu z serwerem [w] publicznej podsieci ze ścisłą polityką bezpieczeństwa? - abhillman 24 czerwca 2014 o 23:45

Wyobraź sobie scenariusz, w którym używasz VPC i przypisujesz publiczne adresy IP do wszystkich swoich instancji EC2. Nie martw się, to nie znaczy, że są one koniecznie osiągalne przez Internet, ponieważ używasz grup bezpieczeństwa do ograniczania dostępu dokładnie w taki sam sposób, jak działało z EC2 classic. Korzystając z publicznych adresów IP, zyskujesz możliwość łatwego udostępnienia niektórych usług ograniczonej liczbie odbiorców bez konieczności używania czegoś takiego jak ELB. Dzięki temu nie musisz konfigurować instancji NAT lub bramy NAT. A ponieważ potrzebujesz o połowę mniej podsieci, możesz wybrać mniejszą alokację CIDR dla swojego VPC lub utworzyć większe podsieci z tym samym rozmiarem VPC. A mniej podsieci oznacza, że ​​będziesz płacić mniej za ruch między AZ.

Więc dlaczego tego nie zrobimy? Dlaczego AWS mówi, że najlepszą praktyką jest używanie prywatnych adresów IP?

Amazon Web Services ma ograniczoną podaż publicznych adresów IPv4, ponieważ Internet jako całość ma ograniczoną podaż publicznych adresów IPv4. W ich najlepszym interesie jest używanie prywatnych adresów IP, które są faktycznie nieograniczone, zamiast nadmiernego zużywania rzadkich publicznych adresów IPv4. Możesz zobaczyć pewne dowody na to, jak AWS wycenia elastyczne adresy IP; EIP dołączony do instancji jest bezpłatny, ale niewykorzystany EIP kosztuje.

Ale na potrzeby dyskusji załóżmy, że nie obchodzi nas niedobór publicznych adresów IPv4 w Internecie. W końcu moja aplikacja jest wyjątkowa. Co się potem dzieje?

Istnieją tylko dwa sposoby dołączenia publicznego adresu IP do instancji EC2 w VPC.

1. Skojarzony publiczny adres IP

Możesz zażądać publicznego adresu IP podczas uruchamiania nowej instancji EC2. Ta opcja pojawia się jako pole wyboru w konsoli, jako flaga --associate-public-ip-address podczas korzystania z aws-cli oraz jako flaga AssociatePublicIpAddress w osadzonym obiekcie interfejsu sieciowego podczas korzystania z CloudFormation. W każdym przypadku publiczny adres IP jest przypisany do eth0(DeviceIndex = 0). Tego podejścia można używać tylko podczas uruchamiania nowej instancji. Ma to jednak pewne wady.

Wadą jest to, że zmiana grupy zabezpieczeń instancji korzystającej z osadzonego obiektu interfejsu sieciowego wymusi natychmiastową wymianę instancji, przynajmniej jeśli używasz CloudFormation.

Inną wadą jest to, że przypisany w ten sposób publiczny adres IP zostanie utracony po zatrzymaniu instancji.

2. Elastyczne IP

Ogólnie rzecz biorąc, elastyczne adresy IP są preferowanym podejściem, ponieważ są bezpieczniejsze. Masz gwarancję, że będziesz nadal używać tego samego adresu IP, nie ryzykujesz przypadkowego usunięcia jakichkolwiek instancji EC2, możesz dowolnie dołączać / odłączać elastyczne adresy IP w dowolnym momencie i masz swobodę zmiany grup zabezpieczeń zastosowanych do instancji EC2.

... Ale AWS ogranicza cię do 5 EIP na region. Możesz poprosić o więcej, a Twoja prośba może zostać spełniona. Ale AWS może równie prawdopodobnie odrzucić tę prośbę na podstawie rozumowania, o którym wspomniałem powyżej. Więc prawdopodobnie nie chcesz polegać na EIP, jeśli planujesz kiedykolwiek skalować swoją infrastrukturę poza 5 instancji EC2 na region.

Podsumowując, korzystanie z publicznych adresów IP niesie za sobą kilka fajnych korzyści, ale jeśli spróbujesz używać wyłącznie publicznych adresów IP, napotkasz problemy administracyjne lub związane ze skalowaniem. Mamy nadzieję, że pomoże to zilustrować i wyjaśnić, dlaczego najlepsze praktyki są takie, jakie są.