AWS - VPC & Networking Basic Information
AWS Networking in a Nutshell
VPC zawiera network CIDR jak 10.0.0.0/16 (z routing table i network ACL).
Ta sieć VPC jest podzielona na subnetworks, więc subnetwork jest bezpośrednio powiązana z VPC, routing table i network ACL.
Następnie, Network Interfaces przypisane do usług (jak instancje EC2) są połączone z subnetworks z security group(s).
Dlatego security group ograniczy otwarte porty network interfaces using it, niezależnie od subnetwork. A network ACL będzie ograniczać otwarte porty dla całej sieci.
Ponadto, aby uzyskać dostęp do Internetu, istnieją pewne interesujące konfiguracje do sprawdzenia:
Subnetwork może automatycznie przypisywać publiczne adresy IPv4
Instancja utworzona w sieci, która automatycznie przypisuje adresy IPv4, może go otrzymać
Internet gateway musi być przypisany do VPC
Można również użyć Egress-only internet gateways
Można również mieć NAT gateway w prywatnym subnecie, aby połączyć się z zewnętrznymi usługami z tego prywatnego subnetu, ale nie można ich osiągnąć z zewnątrz.
NAT gateway może być publiczny (dostęp do internetu) lub prywatny (dostęp do innych VPC)
VPC
Amazon Virtual Private Cloud (Amazon VPC) umożliwia uruchamianie zasobów AWS w wirtualnej sieci, którą zdefiniowałeś. Ta wirtualna sieć będzie miała kilka subnetów, Internet Gateways do dostępu do Internetu, ACLs, Security groups, IPs...
Subnets
Subnets pomagają w egzekwowaniu wyższego poziomu bezpieczeństwa. Logiczne grupowanie podobnych zasobów również pomaga w łatwości zarządzania infrastrukturą.
Prawidłowe CIDR są od maski sieci /16 do maski sieci /28.
Subnet nie może być jednocześnie w różnych strefach dostępności.
AWS rezerwuje pierwsze trzy adresy IP hosta każdego subnetu do wewnętrznego użytku AWS: pierwszy adres hosta jest używany dla routera VPC. Drugi adres jest zarezerwowany dla AWS DNS, a trzeci adres jest zarezerwowany na przyszłość.
Subnety, które mają bezpośredni dostęp do Internetu, nazywane są publicznymi, podczas gdy prywatne subnety nie mają.
Route Tables
Route tables określają trasowanie ruchu dla subnetu w VPC. Określają, który ruch sieciowy jest przekazywany do internetu lub do połączenia VPN. Zazwyczaj znajdziesz dostęp do:
Lokalny VPC
NAT
Internet Gateways / Egress-only Internet gateways (potrzebne do zapewnienia VPC dostępu do Internetu).
Aby uczynić subnet publicznym, musisz utworzyć i przypisać Internet gateway do swojego VPC.
VPC endpoints (do dostępu do S3 z prywatnych sieci)
Na poniższych obrazkach możesz sprawdzić różnice między domyślną siecią publiczną a prywatną:
ACLs
Network Access Control Lists (ACLs): Network ACLs to reguły zapory, które kontrolują ruch sieciowy przychodzący i wychodzący do subnetu. Mogą być używane do zezwalania lub blokowania ruchu do określonych adresów IP lub zakresów.
Najczęściej zezwala się/odmawia dostępu za pomocą security groups, ale jest to jedyny sposób na całkowite przerwanie ustanowionych reverse shells. Zmodyfikowana reguła w security groups nie zatrzymuje już ustanowionych połączeń.
Jednakże, to dotyczy całej sieci podsieci, bądź ostrożny przy zakazywaniu rzeczy, ponieważ potrzebna funkcjonalność może zostać zakłócona.
Security Groups
Security groups to wirtualna zapora, która kontroluje ruch sieciowy przychodzący i wychodzący do instancji w VPC. Relacja 1 SG do M instancji (zazwyczaj 1 do 1). Zazwyczaj używa się tego do otwierania niebezpiecznych portów w instancjach, takich jak port 22 na przykład:
Elastic IP Addresses
Elastic IP address to statyczny adres IPv4 zaprojektowany do dynamicznego przetwarzania w chmurze. Elastic IP address jest przypisany do twojego konta AWS i jest twój, dopóki go nie zwolnisz. Korzystając z Elastic IP address, możesz maskować awarię instancji lub oprogramowania, szybko przypisując adres do innej instancji na swoim koncie.
Connection between subnets
Domyślnie wszystkie subnety mają automatyczne przypisywanie publicznych adresów IP wyłączone, ale można je włączyć.
Lokalna trasa w tabeli tras umożliwia komunikację między subnetami VPC.
Jeśli łączysz subnet z innym subnetem, nie możesz uzyskać dostępu do subnetów połączonych z innym subnetem, musisz utworzyć połączenie bezpośrednio z nimi. To samo dotyczy internet gateways. Nie możesz przejść przez połączenie subnetu, aby uzyskać dostęp do internetu, musisz przypisać internet gateway do swojego subnetu.
VPC Peering
VPC peering pozwala na połączenie dwóch lub więcej VPC razem, używając IPV4 lub IPV6, jakby były częścią tej samej sieci.
Gdy połączenie peer jest ustanowione, zasoby w jednym VPC mogą uzyskać dostęp do zasobów w drugim. Połączenie między VPC jest realizowane przez istniejącą infrastrukturę sieciową AWS, więc jest wysoce dostępne bez wąskich gardeł przepustowości. Ponieważ połączenia peer działają jakby były częścią tej samej sieci, istnieją ograniczenia dotyczące zakresów bloków CIDR, które mogą być używane. Jeśli masz nakładające się lub duplikujące zakresy CIDR dla swojego VPC, nie będziesz mógł połączyć VPC razem. Każdy AWS VPC będzie komunikować się tylko ze swoim peer. Na przykład, jeśli masz połączenie peer między VPC 1 a VPC 2, oraz inne połączenie między VPC 2 a VPC 3, jak pokazano, wtedy VPC 1 i 2 mogą komunikować się bezpośrednio, podobnie jak VPC 2 i VPC 3, jednak VPC 1 i VPC 3 nie mogą. Nie możesz routować przez jedno VPC, aby dostać się do innego.
VPC Flow Logs
W twoim VPC możesz potencjalnie mieć setki lub nawet tysiące zasobów, które komunikują się między różnymi subnetami, zarówno publicznymi, jak i prywatnymi, a także między różnymi VPC przez połączenia VPC peering. VPC Flow Logs pozwalają na przechwytywanie informacji o ruchu IP, który przepływa między interfejsami sieciowymi twoich zasobów w VPC.
W przeciwieństwie do logów dostępu S3 i logów dostępu CloudFront, dane logów generowane przez VPC Flow Logs nie są przechowywane w S3. Zamiast tego, dane logów są wysyłane do CloudWatch logs.
Ograniczenia:
Jeśli masz połączenie VPC peered, będziesz mógł zobaczyć logi przepływu tylko dla VPC peered, które są w tym samym koncie.
Jeśli nadal uruchamiasz zasoby w środowisku EC2-Classic, niestety nie możesz uzyskać informacji z ich interfejsów.
Gdy VPC Flow Log zostanie utworzony, nie można go zmienić. Aby zmienić konfigurację VPC Flow Log, musisz go usunąć i utworzyć nowy.
Następujący ruch nie jest monitorowany i przechwytywany przez logi. Ruch DHCP w VPC, ruch z instancji przeznaczony dla serwera DNS Amazon.
Każdy ruch przeznaczony na adres IP domyślnego routera VPC oraz ruch do i z następujących adresów, 169.254.169.254, który jest używany do zbierania metadanych instancji, oraz 169.254.169.123, który jest używany do usługi synchronizacji czasu Amazon.
Ruch związany z licencją aktywacyjną Amazon Windows z instancji Windows.
Ruch między interfejsem load balancera sieciowego a interfejsem sieciowym punktu końcowego.
Dla każdego interfejsu sieciowego, który publikuje dane do grupy logów CloudWatch, będzie używany inny strumień logów. W każdym z tych strumieni będą dane zdarzeń logów przepływu, które pokazują zawartość wpisów logów. Każdy z tych logów przechwytuje dane w oknie około 10 do 15 minut.
VPN
Basic AWS VPN Components
Customer Gateway:
Customer Gateway to zasób, który tworzysz w AWS, aby reprezentować swoją stronę połączenia VPN.
Jest to zasadniczo fizyczne urządzenie lub aplikacja programowa po twojej stronie połączenia Site-to-Site VPN.
Podajesz informacje o routingu i publiczny adres IP swojego urządzenia sieciowego (takiego jak router lub zapora) do AWS, aby utworzyć Customer Gateway.
Służy jako punkt odniesienia do konfiguracji połączenia VPN i nie generuje dodatkowych opłat.
Virtual Private Gateway:
Virtual Private Gateway (VPG) to koncentrator VPN po stronie Amazon w połączeniu Site-to-Site VPN.
Jest przypisany do twojego VPC i służy jako cel dla twojego połączenia VPN.
VPG to punkt końcowy połączenia VPN po stronie AWS.
Obsługuje bezpieczną komunikację między twoim VPC a twoją siecią lokalną.
Site-to-Site VPN Connection:
Połączenie Site-to-Site VPN łączy twoją sieć lokalną z VPC przez bezpieczny tunel VPN IPsec.
Ten typ połączenia wymaga Customer Gateway i Virtual Private Gateway.
Jest używany do bezpiecznej, stabilnej i spójnej komunikacji między twoim centrum danych lub siecią a środowiskiem AWS.
Zazwyczaj używany do regularnych, długoterminowych połączeń i jest rozliczany na podstawie ilości danych przesyłanych przez połączenie.
Client VPN Endpoint:
Client VPN endpoint to zasób, który tworzysz w AWS, aby umożliwić i zarządzać sesjami VPN klienta.
Jest używany do umożliwienia indywidualnym urządzeniom (takim jak laptopy, smartfony itp.) bezpiecznego łączenia się z zasobami AWS lub twoją siecią lokalną.
Różni się od Site-to-Site VPN tym, że jest przeznaczony dla indywidualnych klientów, a nie do łączenia całych sieci.
Z Client VPN, każde urządzenie klienckie używa oprogramowania klienta VPN, aby nawiązać bezpieczne połączenie.
Site-to-Site VPN
Połącz swoją sieć lokalną z VPC.
VPN connection: Bezpieczne połączenie między twoim sprzętem lokalnym a twoimi VPC.
VPN tunnel: Zaszyfrowane połączenie, przez które dane mogą przechodzić z sieci klienta do lub z AWS.
Każde połączenie VPN zawiera dwa tunele VPN, które można jednocześnie używać dla wysokiej dostępności.
Customer gateway: Zasób AWS, który dostarcza informacji do AWS o twoim urządzeniu bramy klienta.
Customer gateway device: Fizyczne urządzenie lub aplikacja programowa po twojej stronie połączenia Site-to-Site VPN.
Virtual private gateway: Koncentrator VPN po stronie Amazon w połączeniu Site-to-Site VPN. Używasz virtual private gateway lub transit gateway jako bramy po stronie Amazon w połączeniu Site-to-Site VPN.
Transit gateway: Centrum tranzytowe, które może być używane do łączenia twoich VPC i sieci lokalnych. Używasz transit gateway lub virtual private gateway jako bramy po stronie Amazon w połączeniu Site-to-Site VPN.
Limitations
Ruch IPv6 nie jest obsługiwany dla połączeń VPN na virtual private gateway.
Połączenie VPN AWS nie obsługuje Path MTU Discovery.
Ponadto, weź pod uwagę następujące kwestie przy korzystaniu z Site-to-Site VPN.
Podczas łączenia swoich V
Last updated
