Praktični primeri – Modul 25 – Cloud mreže

Primeri koriste AWS nazive. Za primere 1–4 nije potreban cloud nalog — to su vežbe planiranja i zaključivanja, iste kakve rade cloud i mrežni inženjeri pre izrade bilo kakvog resursa.

Primer 1 – Planiranje VPC-a i subneta za hibridno okruženje

Situacija: Firma ima lokalnu mrežu 10.10.0.0/16 i mreže poslovnica 192.168.0.0/16. Treba isplanirati produkcioni VPC za aplikaciju u dve zone, sa javnim, aplikacionim i subnetima baze, koji će biti povezan VPN-om sa lokalnom mrežom.

Korak 1 — izbor opsega VPC-a: 10.20.0.0/16. Ne preklapa se ni sa 10.10.0.0/16 ni sa 192.168.0.0/16, i ostavlja prostor za testni VPC 10.21.0.0/16.

Korak 2 — raspodela subneta (šema: treći oktet kodira sloj i zonu, lako za pamćenje i za pisanje pravila):

Od 256 mogućih /24 subneta iskorišćeno je šest — ogromna rezerva za nove slojeve i zone.

Korak 3 — sumarizacija za lokalnu mrežu: lokalni ruter može imati jednu rutu 10.20.0.0/16 ka VPN-u za ceo VPC (Modul 5 — sumarizacija ruta).

Zaključak: Planiranje adresa u cloud-u je isti VLSM/subnetting posao kao u Modulu 5 — uz dve razlike: 5 rezervisanih adresa po subnetu i vezu subneta sa zonom dostupnosti.

Primer 2 – Kuda ide paket? Tabele ruta i longest prefix match

Tabele ruta za VPC iz Primera 1:

rt-javni (pridružena javni-a i javni-b):

rt-app-a (pridružena app-a):

rt-baza (pridružena baza-a i baza-b):

Odluke za paket poslat sa servera u app-a:

Odluka za paket sa baze (baza-a) ka 151.101.1.69: jedino poklapanje bi bilo 0.0.0.0/0, ali takve rute u rt-baza nema → paket se odbacuje. Baza namerno nema izlaz na internet.

Zaključak: Tri različite tabele ruta daju tri različita „ponašanja" subneta. Bezbednosna odluka „baza nema pristup internetu" sprovedena je rutiranjem, pre bilo kakvog firewall pravila.

Primer 3 – Dijagnostika: „veb server nije dostupan sa interneta"

Situacija: Nova EC2 instanca sa nginx-om u subnetu javni-a. Iz pregledača se sajt ne otvara (istek vremena).

Sistematska provera pet uslova iz Teme 7, od mreže ka instanci:

Uzrok: tabela rt-javni je napravljena, ali nije pridružena subnetu javni-a, pa subnet koristi main tabelu bez izlaza na internet.

Ispravka: pridružiti rt-javni subnetu (u AWS CLI-ju: aws ec2 associate-route-table --route-table-id <rt-javni> --subnet-id <javni-a>).

Zaključak: Istek vremena (a ne „odbijena veza") ukazuje da paketi ne stižu ili se odgovori ne vraćaju — tipično ruta, SG ili NACL. Redosled provere kao u Modulu 20: od mreže (ruta, gateway) ka pravilima (NACL, SG) i na kraju ka servisu na instanci (systemctl status nginx).

Primer 4 – Security group-e sa referencama i NACL za subnet baze

Security group-e (stateful, samo allow):

Kada se doda treći aplikacioni server sa sg-app, automatski dobija pristup bazi — nijedno pravilo se ne menja.

NACL za subnete baze (stateless, dodatni sloj):

Zašto oba sloja: ako neko greškom doda pravilo „TCP 5432 iz 0.0.0.0/0" u sg-baza, NACL i dalje propušta samo aplikacione subnete, a baza ionako nema rutu ka internetu (Primer 2). Tri nezavisna sloja — rutiranje, NACL i SG — štite bazu (defense in depth, Modul 16).

Primer 5 – Site-to-site VPN između centrale i VPC-a

Parametri veze (AWS Site-to-Site VPN sa BGP-om):

Deo konfiguracije rutera centrale (Cisco IOS, uprošćeno — ceo IPsec deo je kao u Modulu 15, a AWS daje gotovu konfiguraciju za preuzimanje):

interface Tunnel1
 ip address 169.254.10.2 255.255.255.252
 tunnel source GigabitEthernet0/0
 tunnel destination <AWS adresa tunela 1>
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile AWS-VPN
!
router bgp 65010
 neighbor 169.254.10.1 remote-as 64512
 neighbor 169.254.11.1 remote-as 64512
 network 10.10.0.0 mask 255.255.0.0
 network 192.168.0.0 mask 255.255.0.0

(Za network naredbe u BGP-u mreže moraju postojati u tabeli rutiranja rutera, npr. kao sumarne statičke rute ka Null0. Drugi tunel, Tunnel2, podešava se isto sa adresama 169.254.11.x.)

Na strani AWS-a: u tabelama ruta rt-app-a, rt-app-b i rt-baza uključuje se propagacija ruta sa virtual private gateway-a, pa se rute 10.10.0.0/16 i 192.168.0.0/16 pojavljuju automatski, sa BGP-a.

Provera: show ip bgp summary na ruteru centrale — oba suseda u stanju Established; show ip route bgp — ruta 10.20.0.0/16 preko jednog od tunela. U AWS konzoli oba tunela imaju status UP.

Zaključak: Za mrežnog inženjera cloud VPN nije ništa novo — IPsec iz Modula 15, BGP iz Modula 12 i sumarizacija iz Modula 5. Nova je samo „druga strana", upravljana usluga provajdera, i obaveza da oba tunela rade.

Poslovni scenario – Prelazak veb prodavnice „Apoteka Plus" u cloud

Situacija: Lanac apoteka ima veb prodavnicu na dva servera u sopstvenoj server sali. Tokom akcija sajt postaje spor, a jednom je bio nedostupan šest sati zbog kvara napajanja. Sistem zaliha (ERP) mora ostati lokalno, ali ga prodavnica koristi za proveru stanja artikala.

Odluke:

1. Model: hibridni cloud — prodavnica u javnom cloud-u (region najbliži korisnicima, u skladu sa zaštitom podataka), ERP lokalno.
2. Adresni plan: lokalno 10.10.0.0/16; VPC 10.20.0.0/16 sa šest subneta u dve zone (Primer 1).
3. Dostupnost: Application Load Balancer u obe zone; najmanje dve aplikacione instance po zoni uz automatsko skaliranje; upravljana baza sa rezervnom kopijom u drugoj zoni.
4. Izlaz na internet: NAT gateway u svakoj zoni (plaćanje karticama preko spoljnog API-ja).
5. Veza sa ERP-om: site-to-site VPN sa BGP-om i dva tunela (Primer 5); kasnije, ako saobraćaj poraste, namenska veza sa VPN-om kao rezervom.
6. Bezbednost: SG-ovi sa referencama i NACL za bazu (Primer 4); administracija samo preko VPN-a; WAF ispred load balancer-a; MFA i posebni IAM nalozi.
7. Nadzor i troškovi: VPC Flow Logs, zapis o API pozivima, upozorenja o budžetu i oznake projekat=prodavnica, okruzenje=prod; cela mreža opisana Terraform-om u Git-u (Modul 24).

Rezultat: Tokom sledeće akcije broj aplikacionih instanci automatski raste sa 4 na 10 i vraća se na 4 posle akcije. Kada zona a ima kratak prekid, prodavnica radi iz zone b. Troškovi su predvidivi zahvaljujući budžetu i oznakama, a lokalna server sala više ne mora da drži opremu za vršna opterećenja.