Teorija – Modul 25 – Cloud mreže

Napomena: svaka tema u ovom dokumentu sadrži sedam elemenata: (1) jednostavno objašnjenje, (2) stručno objašnjenje, (3) primer iz svakodnevnog života, (4) primer iz poslovnog IT okruženja, (5) praktičnu vežbu ili napomenu, (6) najčešće greške, (7) pitanje za proveru znanja.

Primeri koriste AWS nazive jer su najrasprostranjeniji; Tema 13 daje odgovarajuće nazive u Azure-u i Google Cloud-u. Cene i uslovi besplatnog korišćenja menjaju se, pa ih uvek proverite na zvaničnom sajtu provajdera.

Tema 1 – Šta je cloud computing

1. Jednostavno objašnjenje

Cloud znači da serveri, mreže i skladište ne stoje u vašoj server sali, već ih iznajmljujete od provajdera preko interneta — kad vam trebaju, koliko vam treba, i plaćate samo ono što koristite.

2. Stručno objašnjenje

Prema NIST definiciji (SP 800-145), cloud computing ima pet osnovnih osobina: samousluga na zahtev (resurse pravite sami, preko konzole ili API-ja), širok mrežni pristup, deljenje resursa između više korisnika (multi-tenancy), brza elastičnost (povećanje i smanjenje kapaciteta) i merena usluga (plaćanje po potrošnji). Modeli usluga:

Model podeljene odgovornosti (shared responsibility): provajder odgovara za bezbednost samog cloud-a (data centri, fizička mreža, hipervizori), a korisnik za bezbednost u cloud-u (podešavanje mreže, security group-a, operativnih sistema, pristupa, podataka). Pogrešno podešena security group je odgovornost korisnika, ne provajdera.

3. Primer iz svakodnevnog života

Umesto kupovine automobila (sopstvena server sala) koristite taksi ili rent-a-car (cloud): plaćate vožnju, ne brinete o servisu motora — ali i dalje vi birate kuda idete i da li ćete zaključati vrata.

4. Primer iz poslovnog IT okruženja

Web prodavnica ima deset puta veći saobraćaj za vreme praznične akcije. U cloud-u se broj servera automatski povećava tokom akcije i smanjuje posle nje, pa firma ne kupuje opremu koja bi ostatak godine stajala neiskorišćena.

5. Praktična vežba / napomena

Za tri servisa koje koristite (npr. e-pošta, skladište fajlova, virtuelni server) odredite da li su IaaS, PaaS ili SaaS i ko je odgovoran za podešavanje pristupa.

6. Najčešće greške

• Uverenje da je „provajder zadužen za bezbednost" svega što je u cloud-u.
• Poistovećivanje cloud-a sa „tuđim serverom" — bez razumevanja elastičnosti, API-ja i naplate po potrošnji.
• Zanemarivanje troškova: resurs koji niko ne koristi, a nije obrisan, i dalje se naplaćuje.

7. Pitanje za proveru znanja

P: Ko je, prema modelu podeljene odgovornosti, odgovoran za to što je SSH port virtuelne mašine otvoren prema celom internetu? O: Korisnik — podešavanje mreže i pravila filtriranja (security group) je bezbednost „u" cloud-u, koja je odgovornost korisnika.

Tema 2 – Public, private, hybrid i multi-cloud

1. Jednostavno objašnjenje

Cloud može biti javan (deljen, kod velikog provajdera), privatan (samo za jednu firmu), ili kombinacija — deo servisa lokalno, a deo u javnom cloud-u.

2. Stručno objašnjenje

• Public cloud — infrastruktura provajdera (AWS, Azure, GCP) deljena između mnogo korisnika, uz logičko razdvajanje; nema početnog ulaganja, plaćanje po potrošnji.
• Private cloud — cloud model (samousluga, elastičnost, API) na infrastrukturi namenjenoj jednoj organizaciji, u sopstvenom ili iznajmljenom data centru (npr. OpenStack, VMware, Proxmox klaster iz Modula 21 kao jednostavan primer).
• Hybrid cloud — lokalno okruženje ili privatni cloud povezani sa javnim cloud-om u jednu celinu: zajednički adresni plan, rutiranje preko VPN-a ili namenske veze, zajednička autentifikacija.
• Multi-cloud — istovremena upotreba više javnih provajdera (npr. AWS i Azure), radi izbegavanja zavisnosti od jednog provajdera ili korišćenja najboljih usluga svakog.

Za mrežnog inženjera hybrid i multi-cloud znače: planiranje adresa bez preklapanja između svih okruženja, povezivanje (Tema 12), dosledna bezbednosna pravila i nadzor preko svih lokacija.

3. Primer iz svakodnevnog života

Stanovanje: sopstveni stan (lokalno), iznajmljen stan (javni cloud), i vikendica koju koristite uz stan (hibridno) — a stvari prenosite između njih istim putem.

4. Primer iz poslovnog IT okruženja

Banka zadržava sistem sa podacima klijenata u sopstvenom data centru (regulatorni zahtevi), a web i mobilnu aplikaciju drži u javnom cloud-u; dve lokacije povezuje redundantnom namenskom vezom i VPN-om kao rezervom — hibridni model.

5. Praktična vežba / napomena

Razmislite koji servisi firme u kojoj radite (ili neke poznate firme) bi mogli da pređu u javni cloud, a koji bi morali da ostanu lokalno — i zbog čega.

6. Najčešće greške

• Adresni opseg u cloud-u koji se preklapa sa lokalnom mrežom — kasnije je povezivanje nemoguće bez NAT-a ili prenumeracije.
• Hibridno okruženje sa različitim bezbednosnim pravilima na dve strane.
• Multi-cloud „za svaki slučaj", bez stvarne potrebe — duplira složenost i troškove.

7. Pitanje za proveru znanja

P: Šta je hybrid cloud i koji je mrežni preduslov za njega? O: Kombinacija lokalnog (ili privatnog) okruženja i javnog cloud-a povezanih u celinu; mrežni preduslovi su adresni plan bez preklapanja i veza između okruženja (VPN ili namenska veza).

Tema 3 – Regioni i zone dostupnosti

1. Jednostavno objašnjenje

Provajder ima data centre širom sveta, grupisane po regionima. Svaki region ima više odvojenih zona; ako jedna zona otkaže, druge nastavljaju da rade.

2. Stručno objašnjenje

Region je geografska oblast sa više data centara (npr. eu-central-1 Frankfurt, eu-west-1 Irska). Zona dostupnosti (Availability Zone, AZ) je jedan ili više data centara unutar regiona sa nezavisnim napajanjem, hlađenjem i mrežom, povezanih sa ostalim zonama brzim vezama male latencije. Posledice za mrežu:

• VPC postoji u jednom regionu (u AWS-u i Azure-u), a u AWS-u je svaki subnet vezan za jednu zonu.
• Visoka dostupnost zahteva resurse u najmanje dve zone (subneti, instance, NAT gateway po zoni, load balancer preko više zona).
• Izbor regiona utiče na latenciju ka korisnicima, cenu i pravne zahteve o lokaciji podataka (npr. GDPR).

Naziv zone (npr. eu-central-1a) je vezan za nalog — isto slovo kod dva različita naloga može označavati različite fizičke zone; zato AWS nudi i stabilan AZ ID (npr. euc1-az1).

3. Primer iz svakodnevnog života

Firma koja drži rezervne kopije dokumenata u dve zgrade u istom gradu: požar u jednoj zgradi ne uništava sve, a obe zgrade su dovoljno blizu da se dokumenti lako prenose.

4. Primer iz poslovnog IT okruženja

Aplikacija radi na dve instance u zoni a i dve u zoni b, iza load balancer-a. Kada zona a ima prekid napajanja, load balancer šalje sav saobraćaj u zonu b i korisnici ne primećuju prekid.

5. Praktična vežba / napomena

U Delu 1 laboratorije projektujete subnete u dve zone dostupnosti — za svaki javni i privatni subnet postoji „par" u drugoj zoni.

6. Najčešće greške

• Svi resursi u jednoj zoni „jer je jednostavnije" — jedna tačka otkaza.
• Izbor udaljenog regiona zbog niže cene, bez provere latencije i pravnih zahteva.
• Pretpostavka da je saobraćaj između zona besplatan — često se naplaćuje.

7. Pitanje za proveru znanja

P: Zašto se aplikacija postavlja u najmanje dve zone dostupnosti? O: Zone imaju nezavisno napajanje, hlađenje i mrežu, pa otkaz jedne zone ne prekida rad aplikacije koja radi i u drugoj.

Tema 4 – VPC (Virtual Private Cloud)

1. Jednostavno objašnjenje

VPC je vaša privatna, izolovana mreža u cloud-u — kao sopstvena LAN mreža, samo što su „svičevi i ruteri" softverski i pravite ih sa nekoliko klikova ili komandi.

2. Stručno objašnjenje

VPC je logički izolovana virtuelna mreža u jednom regionu, sa adresnim opsegom (CIDR blokom) koji sami izaberete — u AWS-u od /16 (65.536 adresa) do /28 (16 adresa), najčešće iz privatnih opsega RFC 1918 (Modul 4). Dobra praksa pri izboru opsega:

• Bez preklapanja sa lokalnom mrežom, drugim VPC-ovima i mrežama partnera sa kojima će se VPC povezivati (VPN, peering) — jer rutiranje između preklapajućih opsega nije moguće bez NAT-a.
• Dovoljno velik za rast (često /16 po VPC-u), jer se primarni opseg kasnije ne može promeniti (mogu se dodati sekundarni opsezi, uz ograničenja).
• Deo centralnog IP adresnog plana firme (Modul 23).

VPC ima ugrađen virtuelni ruter (implicitni ruter kome nema direktnog pristupa), DNS rezoluciju, DHCP za instance i mogućnost IPv6 opsega. Više VPC-ova se povezuje VPC peering-om (veza jedan-na-jedan, netranzitivna) ili Transit Gateway-em (centralni ruter za mnogo VPC-ova i VPN-ova).

3. Primer iz svakodnevnog života

Iznajmljen prostor u velikoj poslovnoj zgradi: zgrada je deljena, ali vaš sprat ima sopstvena vrata, sopstveni raspored kancelarija i ključeve koje imate samo vi.

4. Primer iz poslovnog IT okruženja

Firma ima lokalnu mrežu 10.10.0.0/16. Za produkcioni VPC bira 10.20.0.0/16, za testni 10.21.0.0/16, a sve upisuje u IP adresni plan — kada kasnije uvede site-to-site VPN, rutiranje radi bez ikakvog NAT-a.

5. Praktična vežba / napomena

Koristeći VLSM znanje iz Modula 5, proverite koliko /24 subneta staje u VPC 10.20.0.0/16 (odgovor: 256).

6. Najčešće greške

• Korišćenje podrazumevanog VPC-a (sa podrazumevanim opsegom) za produkciju, bez planiranja.
• Premali VPC (npr. /24) koji ne može da primi nove subnete.
• Opseg koji se preklapa sa kućnim mrežama zaposlenih (npr. 192.168.1.0/24) — problemi sa client VPN-om.

7. Pitanje za proveru znanja

P: Zašto se adresni opseg VPC-a ne sme preklapati sa lokalnom mrežom firme? O: Zato što rutiranje između mreža sa istim adresama nije moguće (bez NAT-a) — VPN ili namenska veza između lokalne mreže i VPC-a ne bi radila ispravno.

Tema 5 – Subneti: javni i privatni

1. Jednostavno objašnjenje

VPC se deli na manje mreže — subnete. „Javni" subnet ima put ka internetu, „privatni" nema direktan put sa interneta i u njemu stoje serveri koji ne treba da budu izloženi.

2. Stručno objašnjenje

Subnet je deo CIDR opsega VPC-a; u AWS-u je vezan za jednu zonu dostupnosti. Da li je subnet javni ili privatni ne određuje njegovo ime, već tabela ruta:

• Javni subnet — tabela ruta ima podrazumevanu rutu 0.0.0.0/0 ka internet gateway-u (Tema 7); instance sa javnom IP adresom su dostupne sa interneta (ako to dozvole pravila filtriranja). Tu su load balancer-i, bastion host-ovi, NAT gateway.
• Privatni subnet — nema rutu ka internet gateway-u; izlaz ka internetu (ako treba) ide preko NAT gateway-a (Tema 8). Tu su aplikacioni serveri i baze podataka.

Rezervisane adrese: AWS i Azure u svakom subnetu rezervišu 5 adresa (adresa mreže, .1 virtuelni ruter, .2 DNS, .3 rezervisano, i poslednja adresa), a Google Cloud 4. Subnet /24 u AWS-u ima zato 251 upotrebljivu adresu, a ne 254. Tipična arhitektura sa tri sloja u dve zone ima šest subneta: javni, aplikacioni i baza — po jedan u svakoj zoni.

3. Primer iz svakodnevnog života

Zgrada sa recepcijom (javni subnet), koja je dostupna posetiocima sa ulice, i kancelarijama iza recepcije (privatni subnet), u koje se ne može ući direktno sa ulice.

4. Primer iz poslovnog IT okruženja

Veb aplikacija: load balancer u javnim subnetima obe zone, aplikacioni serveri u privatnim aplikacionim subnetima, baza u privatnim subnetima baze — napadač sa interneta ne može ni da pokuša direktnu vezu sa bazom, jer do nje ne postoji ruta.

5. Praktična vežba / napomena

Izračunajte broj upotrebljivih adresa u AWS subnetu /26: 64 − 5 = 59.

6. Najčešće greške

• Nazvati subnet „privatni", a povezati ga sa tabelom ruta koja ima rutu ka internet gateway-u.
• Zaboraviti 5 rezervisanih adresa pri planiranju malih subneta (/28 ima samo 11 upotrebljivih).
• Baza podataka u javnom subnetu „privremeno".

7. Pitanje za proveru znanja

P: Šta određuje da li je subnet u AWS-u javni ili privatni? O: Tabela ruta pridružena subnetu — javni subnet ima rutu 0.0.0.0/0 ka internet gateway-u, privatni nema.

Tema 6 – Tabele ruta (route tables)

1. Jednostavno objašnjenje

Tabela ruta govori saobraćaju iz subneta kuda da ide — isto kao tabela rutiranja na ruteru iz Modula 11, samo što je podešavate u cloud konzoli.

2. Stručno objašnjenje

Svaki subnet je pridružen tačno jednoj tabeli ruta (eksplicitno ili podrazumevanoj „main" tabeli VPC-a); jedna tabela može biti pridružena većem broju subneta. Svaka ruta ima odredište (CIDR) i cilj (target): local (ceo VPC — automatska, ne može se obrisati), internet gateway (igw-...), NAT gateway (nat-...), virtual private gateway ili transit gateway (VPN/namenska veza), VPC peering veza, mrežni interfejs virtualnog uređaja (npr. firewall-a). Izbor rute se vrši po najdužem poklapanju prefiksa (longest prefix match, Modul 11).

Primer tabele ruta privatnog aplikacionog subneta u hibridnom okruženju:

Dobra praksa: posebna tabela za svaku ulogu (javni, privatni po zoni, baza) umesto izmene „main" tabele, jer novi subnet bez eksplicitnog pridruživanja nasleđuje main tabelu — main tabela treba da ostane „bezbedna" (bez rute ka internetu).

3. Primer iz svakodnevnog života

Putokazi na raskrsnici u naselju: „centar grada" (lokalna mreža), „autoput" (internet), „industrijska zona" (lokalna mreža firme) — svaki pravac ima svoju strelicu.

4. Primer iz poslovnog IT okruženja

Aplikacioni server u privatnom subnetu šalje paket ka 10.10.5.20 (lokalni server firme). Najduže poklapanje je 10.10.0.0/16 → paket ide kroz VPN. Paket ka 8.8.8.8 poklapa samo 0.0.0.0/0 → ide preko NAT gateway-a.

5. Praktična vežba / napomena

Za gornju tabelu odredite cilj za odredišta 10.20.12.7, 10.10.99.1 i 1.1.1.1. (Odgovor: local, VPN, NAT gateway.)

6. Najčešće greške

• Dodavanje rute ka internetu u „main" tabelu — svaki novi subnet postaje javni.
• Nova tabela napravljena, ali nije pridružena subnetu.
• Očekivanje da se ruta local može zameniti ili obrisati.

7. Pitanje za proveru znanja

P: Zašto se ruta ka internet gateway-u ne dodaje u „main" tabelu ruta? O: Zato što svaki subnet koji nije eksplicitno pridružen drugoj tabeli koristi main tabelu — novi subneti bi nenamerno postali javni.

Tema 7 – Internet gateway i javne IP adrese

1. Jednostavno objašnjenje

Internet gateway su „vrata" VPC-a prema internetu. Da bi server bio dostupan sa interneta, potrebni su i vrata (gateway), i put do njih (ruta), i javna adresa servera.

2. Stručno objašnjenje

Internet gateway (IGW) je horizontalno skalabilna, redundantna komponenta koju provajder održava; pridružuje se VPC-u (jedan IGW po VPC-u) i služi kao cilj rute 0.0.0.0/0 u javnim subnetima. Za instance sa javnom IPv4 adresom IGW radi statički 1:1 NAT (Modul 13): instanca u operativnom sistemu vidi samo svoju privatnu adresu, a IGW prevodi privatnu u javnu adresu i obrnuto.

Da bi instanca bila dostupna sa interneta, potrebno je svih pet uslova: (1) IGW pridružen VPC-u, (2) ruta 0.0.0.0/0 → IGW u tabeli subneta, (3) javna IP adresa na instanci (automatski dodeljena ili Elastic IP — stalna javna adresa), (4) security group dozvoljava saobraćaj, (5) network ACL dozvoljava saobraćaj u oba smera. Javne IPv4 adrese su ograničen resurs i provajderi ih naplaćuju; za IPv6 IGW ne radi NAT (adrese su globalne), a za samo izlazni IPv6 saobraćaj postoji egress-only internet gateway.

3. Primer iz svakodnevnog života

Da bi vas kurir našao, potrebni su: kapija zgrade (IGW), put do kapije (ruta), kućni broj (javna IP adresa) i portir koji ga pušta (pravila filtriranja).

4. Primer iz poslovnog IT okruženja

Instanca ima javnu IP adresu i security group sa otvorenim portom 80, ali se sajt ne otvara. Uzrok: subnet je pridružen tabeli ruta bez rute ka IGW-u — „javni" subnet u stvari nije javni.

5. Praktična vežba / napomena

U Delu 2 laboratorije namerno ćete obrisati rutu ka IGW-u i posmatrati posledicu, a zatim je vratiti.

6. Najčešće greške

• Očekivanje da će instanca biti dostupna samo zato što ima javnu IP adresu.
• Zaboravljen neki od pet uslova — najčešće ruta ili pridruživanje tabele subnetu.
• Automatska javna adresa za instancu koja se ponovo pokreće — adresa se menja; za stalnu adresu koristi se Elastic IP.

7. Pitanje za proveru znanja

P: Navedite pet uslova da bi instanca u AWS-u bila dostupna sa interneta. O: IGW pridružen VPC-u; ruta 0.0.0.0/0 ka IGW-u u tabeli ruta subneta; javna IP adresa instance; security group dozvoljava saobraćaj; network ACL dozvoljava saobraćaj u oba smera.

Tema 8 – NAT gateway

1. Jednostavno objašnjenje

Serveri u privatnom subnetu ponekad moraju da „izađu" na internet (npr. da preuzmu ažuriranja), ali niko sa interneta ne sme da „uđe" do njih. NAT gateway omogućava upravo to.

2. Stručno objašnjenje

NAT gateway je upravljana usluga koja radi PAT (NAT overload, Modul 13) za privatne subnete: postavlja se u javni subnet (sa Elastic IP adresom), a privatni subneti dobijaju rutu 0.0.0.0/0 → NAT gateway. Veze se mogu uspostaviti samo iznutra ka spolja; odgovori se vraćaju, ali nova veza sa interneta ka privatnoj instanci nije moguća.

Karakteristike i dobra praksa:

• NAT gateway je vezan za jednu zonu — za visoku dostupnost se pravi po jedan u svakoj zoni, a privatni subnet svake zone koristi NAT gateway iz svoje zone (i da ne bi plaćao saobraćaj između zona).
• Naplaćuje se po satu i po količini obrađenih podataka — jedan od najčešćih „neočekivanih" troškova; zaboravljen NAT gateway u laboratoriji može koštati desetine dolara mesečno.
• Stariji pristup je NAT instanca (obična VM sa IP forwarding-om i masquerade-om — kao ROUTER1 iz Modula 21) — jeftinija, ali je održavate sami.
• Za pristup uslugama provajdera (npr. skladištu objekata) bez prolaska kroz NAT koriste se VPC endpoint-i.

3. Primer iz svakodnevnog života

Sekretarica koja u ime zaposlenih šalje pisma iz firme sa adresom firme kao pošiljaocem: odgovori se vraćaju zaposlenom, ali niko spolja ne zna direktnu adresu zaposlenog niti može da mu pošalje pismo bez prethodnog kontakta.

4. Primer iz poslovnog IT okruženja

Aplikacioni serveri u privatnim subnetima preuzimaju sigurnosne zakrpe operativnog sistema preko NAT gateway-a u svojoj zoni. Kada zona a otkaže, serveri u zoni b i dalje imaju izlaz preko NAT gateway-a zone b.

5. Praktična vežba / napomena

Laboratorija ovog modula namerno ne pravi NAT gateway zbog cene po satu; u Delu 1 ga projektujete, a u rešenju dodatnog izazova je opisano kako se pravi i odmah briše.

6. Najčešće greške

• NAT gateway postavljen u privatni subnet (mora biti u javnom).
• Jedan NAT gateway za sve zone — otkaz zone prekida izlaz na internet svim privatnim subnetima.
• Zaboravljen NAT gateway posle testiranja — trošak se nastavlja.
• Očekivanje da NAT gateway omogućava dolazne veze ka privatnim instancama.

7. Pitanje za proveru znanja

P: U koji subnet se postavlja NAT gateway i koja ruta se dodaje u tabelu privatnog subneta? O: U javni subnet; u tabelu privatnog subneta dodaje se 0.0.0.0/0 → NAT gateway.

Tema 9 – Security group

1. Jednostavno objašnjenje

Security group je firewall koji stoji na samoj virtuelnoj mašini: navodite šta je dozvoljeno, a sve ostalo je zabranjeno. Ako je dozvoljen dolazni zahtev, odgovor automatski prolazi.

2. Stručno objašnjenje

Security group (SG) je stateful firewall na nivou mrežnog interfejsa instance (Modul 16):

• Sadrži samo pravila dozvole (allow); sve što nije dozvoljeno je odbijeno.
• Stateful — ako je dolazna veza dozvoljena, odgovor se automatski propušta (i obrnuto), bez posebnog pravila za povratni saobraćaj.
• Pravila se definišu po protokolu, portu i izvoru/odredištu, gde izvor može biti CIDR ili druga security group — npr. „port 5432 dozvoljen samo iz SG aplikacionih servera", pa pravilo važi i za nove servere bez promene adresa.
• Podrazumevano: nova SG nema dolaznih pravila (sve dolazno zabranjeno) i dozvoljava sav odlazni saobraćaj.
• Sva pravila se procenjuju zajedno (nema redosleda); instanca može imati više SG-ova.

Primer za troslojnu aplikaciju:

3. Primer iz svakodnevnog života

Portir sa spiskom gostiju na ulazu u zgradu: pušta samo one sa spiska, a kada gost izlazi, portir ga pamti i pušta ga bez ponovne provere.

4. Primer iz poslovnog IT okruženja

Revizija pronalazi SG sa pravilom „TCP 22 iz 0.0.0.0/0" na 30 servera — izloženost SSH-a celom internetu. Pravilo se zamenjuje dozvolom samo iz administrativne mreže firme, a dugoročno se SSH zamenjuje upravljanim pristupom bez otvorenih portova (npr. AWS Systems Manager Session Manager).

5. Praktična vežba / napomena

U Delu 1 laboratorije projektujete SG-ove koji se međusobno referenciraju, a u Delu 2 pravite SG za veb server.

6. Najčešće greške

• 0.0.0.0/0 za administrativne portove (SSH 22, RDP 3389, baze podataka).
• Pravila po IP adresama umesto referenci na druge SG-ove — ruše se kada se adrese promene.
• Dodavanje „pravila za odgovor" — nepotrebno, SG je stateful.

7. Pitanje za proveru znanja

P: Da li je potrebno posebno odlazno pravilo u security group-i da bi odgovor veb servera stigao do klijenta? Zašto? O: Nije. Security group je stateful — odgovor na dozvoljenu dolaznu vezu automatski prolazi.

Tema 10 – Network ACL

1. Jednostavno objašnjenje

Network ACL je drugi, dodatni firewall — na ulazu u ceo subnet. Za razliku od security group-e, ne pamti veze, pa morate dozvoliti i put „tamo" i put „nazad".

2. Stručno objašnjenje

Network ACL (NACL) je stateless filter na nivou subneta, veoma sličan proširenoj ACL listi iz Modula 16:

• Ima pravila dozvole i zabrane (allow/deny), sa rednim brojevima; pravila se proveravaju po rastućem broju i primenjuje se prvo poklapanje; na kraju postoji implicitno pravilo * koje sve odbija.
• Posebna pravila za dolazni i odlazni saobraćaj.
• Stateless — povratni saobraćaj se mora eksplicitno dozvoliti. Klijenti koriste efemerne (privremene) portove kao izvorne portove (npr. 1024–65535, Linux koristi 32768–60999), pa odlazno pravilo za odgovore veb servera mora dozvoliti TCP ka portovima 1024–65535.
• Podrazumevana NACL u VPC-u dozvoljava sve; nova (prilagođena) NACL podrazumevano sve odbija.
• Svaki subnet ima tačno jednu NACL; jedna NACL može pokrivati više subneta.

Primer NACL za javni subnet sa veb serverom:

NACL se koristi kao dodatni sloj (defense in depth) — npr. za blokiranje poznatih zlonamernih opsega pravilom deny sa malim rednim brojem, što security group ne može (nema deny pravila).

3. Primer iz svakodnevnog života

Rampa na ulazu u industrijsku zonu koja proverava svako vozilo i na ulazu i na izlazu, po spisku — ne pamti ko je ušao, pa i vozilo koje izlazi mora biti na spisku za izlaz.

4. Primer iz poslovnog IT okruženja

Posle uvođenja nove NACL, veb sajt prestaje da radi iako je security group ispravna. Uzrok: odlazna pravila dozvoljavaju samo portove 80 i 443, a odgovori klijentima idu ka njihovim efemernim portovima — dodaje se odlazno pravilo za TCP 1024–65535.

5. Praktična vežba / napomena

U Delu 2 laboratorije napravićete NACL, a u dijagnostičkoj vežbi uklonićete pravilo za efemerne portove i videti kako se sajt „ugasi" iako se security group nije menjala.

6. Najčešće greške

• Zaboravljena pravila za efemerne portove (povratni saobraćaj).
• deny pravilo sa većim rednim brojem od allow pravila koje ga „pokriva" — nikada se ne primenjuje.
• Nova NACL pridružena subnetu pre dodavanja pravila — trenutni prekid svega u subnetu.

7. Pitanje za proveru znanja

P: Zašto NACL za veb server mora imati odlazno pravilo za TCP portove 1024–65535? O: NACL je stateless, pa povratni saobraćaj ne prolazi automatski; odgovori servera idu ka efemernim portovima klijenata, koji su u tom opsegu.

Tema 11 – Load balancer

1. Jednostavno objašnjenje

Load balancer prima zahteve korisnika i raspoređuje ih na više servera. Ako neki server otkaže, load balancer to primeti i šalje zahteve samo ispravnim serverima.

2. Stručno objašnjenje

Upravljani load balancer (u AWS-u Elastic Load Balancing) ima jednu stalnu tačku pristupa (DNS ime) i raspoređuje saobraćaj na ciljeve (target group: instance, IP adrese, kontejneri) u više zona dostupnosti.

Ključni pojmovi:

• Health check — load balancer periodično proverava svaki cilj (npr. HTTP GET /zdravlje očekuje 200); neispravni ciljevi se isključuju iz raspodele dok se ne oporave.
• TLS terminacija — load balancer drži sertifikat i dešifruje HTTPS, pa serveri iza njega ne moraju.
• Više zona — load balancer ima čvorove u javnim subnetima svake zone; ciljevi su u privatnim subnetima.
• Automatsko skaliranje (Auto Scaling) dodaje i uklanja instance, a load balancer ih automatski uključuje u raspodelu.

Arhitektura: internet → load balancer (javni subneti, SG dozvoljava 443) → aplikacioni serveri (privatni subneti, SG dozvoljava port aplikacije samo iz SG load balancer-a).

3. Primer iz svakodnevnog života

Šalterski službenik na ulazu u banku koji svakog klijenta upućuje na slobodan šalter — a ako je neki šalter zatvoren, tamo nikoga ne šalje.

4. Primer iz poslovnog IT okruženja

Jedna od četiri instance počinje da vraća greške 500 posle neuspelog ažuriranja. Health check je označava kao neispravnu i load balancer je izbacuje iz raspodele za 30 sekundi — korisnici ne primećuju problem, a monitoring (Modul 23) šalje upozorenje.

5. Praktična vežba / napomena

Load balancer se u laboratoriji ne pravi (naplaćuje se po satu); u Delu 1 ga projektujete u javnim subnetima obe zone, sa SG pravilima koja se referenciraju.

6. Najčešće greške

• Health check na putanju koja ne postoji ili zahteva prijavu — svi ciljevi „neispravni".
• Aplikacioni serveri dostupni direktno sa interneta, mimo load balancer-a.
• Load balancer samo u jednoj zoni.

7. Pitanje za proveru znanja

P: Koja je razlika između ALB i NLB load balancer-a? O: ALB radi na sloju 7 i odlučuje na osnovu HTTP sadržaja (putanja, host); NLB radi na sloju 4 i odlučuje na osnovu IP adrese i porta (TCP/UDP), uz veoma nisku latenciju.

Tema 12 – Povezivanje lokalne mreže sa cloud-om

1. Jednostavno objašnjenje

Da bi lokalni računari firme i serveri u cloud-u radili kao jedna mreža, povezuju se šifrovanim tunelom preko interneta (VPN) ili posebnom, iznajmljenom vezom direktno do provajdera.

2. Stručno objašnjenje

• Site-to-site VPN — IPsec tuneli (Modul 15) između lokalnog rutera/firewall-a (customer gateway) i VPN usluge provajdera (u AWS-u virtual private gateway ili transit gateway). AWS VPN veza ima dva tunela ka dve različite krajnje tačke radi redundanse; rute se razmenjuju statički ili preko BGP-a (Modul 12) — BGP omogućava automatski prelazak na drugi tunel. Provajder nudi konfiguraciju za preuzimanje za čest opremu (Cisco, Juniper, Fortinet...). Propusnost je ograničena (reda veličine nekoliko Gb/s po tunelu) i zavisi od interneta.
• Namenska privatna veza — AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect: fizička veza (preko provajdera telekomunikacija) od lokacije firme ili data centra do tačke prisustva cloud provajdera; predvidiva latencija i velika propusnost, ali duže uvođenje i viša cena. Često se kombinuje sa VPN-om kao rezervom.
• Client (remote-access) VPN — pojedinačni korisnici se povezuju na VPC (Modul 15).
• Transit Gateway / Virtual WAN — centralni „ruter" koji povezuje više VPC-ova i lokalnih lokacija (hub-and-spoke), umesto velikog broja pojedinačnih veza.

Preduslovi: adresni plan bez preklapanja (Tema 4), rute na obe strane (u tabelama ruta VPC-a — statičke ili propagacija sa VPN gateway-a), i pravila filtriranja (SG/NACL) koja dozvoljavaju lokalne mreže.

3. Primer iz svakodnevnog života

Dve poslovnice iste firme povezane ili javnim putem sa zaključanim kombijem (VPN preko interneta), ili sopstvenim privatnim putem između zgrada (namenska veza) — skuplje, ali uvek prohodno.

4. Primer iz poslovnog IT okruženja

Firma povezuje centralu sa VPC-om preko site-to-site VPN-a sa BGP-om. Kada jedan tunel padne zbog održavanja kod provajdera, BGP za nekoliko sekundi prebacuje saobraćaj na drugi tunel; monitoring beleži događaj, a korisnici ne primećuju prekid.

5. Praktična vežba / napomena

Setite se IPsec parametara iz laboratorije Modula 15 (IKE politika, transform set, pre-shared key). Isti parametri se usklađuju i sa cloud VPN uslugom — samo je druga strana upravljana usluga provajdera.

6. Najčešće greške

• Podignut samo jedan od dva tunela — nema redundanse.
• Tunel radi, ali u tabeli ruta VPC-a nema rute ka lokalnoj mreži (ili nije uključena propagacija ruta).
• Security group ne dozvoljava lokalne mreže, pa „VPN radi, a server ne odgovara".
• Preklapanje adresa lokalne mreže i VPC-a.

7. Pitanje za proveru znanja

P: Zašto AWS site-to-site VPN veza ima dva tunela i koja je prednost BGP-a u odnosu na statičke rute? O: Dva tunela ka dve krajnje tačke obezbeđuju redundansu; BGP automatski prebacuje saobraćaj na ispravan tunel kada jedan otkaže, bez ručne izmene ruta.

Tema 13 – Osnove mreža u AWS-u, Azure-u i Google Cloud-u

1. Jednostavno objašnjenje

Svi veliki provajderi nude iste osnovne mrežne gradivne blokove, samo pod drugim imenima i sa nekim razlikama u ponašanju.

2. Stručno objašnjenje

Važne razlike: GCP VPC je globalan (jedan VPC sa subnetima u više regiona), dok su AWS VPC i Azure VNet regionalni; Azure NSG je stateful i može se primeniti i na subnet i na interfejs; GCP firewall pravila imaju prioritete i mogu biti allow ili deny, ali su stateful. Azure je najavio ukidanje podrazumevanog izlaznog pristupa internetu za nove mreže, pa se izlaz planira eksplicitno (NAT Gateway ili javna IP).

3. Primer iz svakodnevnog života

Isti saobraćajni znakovi u različitim zemljama: izgledaju malo drugačije i imaju lokalne nazive, ali „stop" svuda znači isto.

4. Primer iz poslovnog IT okruženja

Firma posle preuzimanja druge kompanije ima aplikacije u AWS-u i Azure-u. Mrežni inženjer pravi zajednički adresni plan za AWS VPC-ove i Azure VNet-ove, povezuje ih preko VPN-a i dokumentuje ekvivalentna pravila u SG i NSG obliku.

5. Praktična vežba / napomena

Prevedite arhitekturu iz Dela 1 laboratorije u Azure nazive (VNet, subneti, NSG, NAT Gateway, Application Gateway, VPN Gateway).

6. Najčešće greške

• Pretpostavka da se sve ponaša isto kod svih provajdera (npr. zone i subneti, globalni i regionalni VPC).
• Direktno „prepisivanje" NACL pravila u okruženje koje ima samo stateful filtere.
• Učenje samo naziva bez razumevanja osnovnih mrežnih koncepata iz ovog kursa.

7. Pitanje za proveru znanja

P: Koja je glavna razlika između VPC-a u Google Cloud-u i VPC-a u AWS-u? O: GCP VPC je globalan — jedan VPC može imati subnete u više regiona; AWS VPC je regionalan.

Tema 14 – Razlike između lokalne i cloud mreže

1. Jednostavno objašnjenje

U cloud-u nema kablova, svičeva ni rack ormana koje vidite — mrežu pravite softverski. Neke stvari su lakše, neke se ponašaju drugačije nego u lokalnoj mreži, a za sve se plaća po potrošnji.

2. Stručno objašnjenje

Posledica za mrežnog inženjera: osnovni koncepti (IP adresiranje, subnetting, rutiranje, NAT, stateful/stateless filtriranje, VPN, BGP, DNS) ostaju isti i čine većinu potrebnog znanja; menja se način primene — softverski, preko API-ja, uz kontrolu troškova.

3. Primer iz svakodnevnog života

Kuvanje kod kuće (lokalna mreža — sami kupujete šporet i namirnice) i restoran sa otvorenom kuhinjom (cloud — birate jelo i način pripreme, ali ne menjate instalacije u kuhinji).

4. Primer iz poslovnog IT okruženja

Aplikacija preneta u cloud prestaje da radi jer se oslanja na multicast za otkrivanje drugih servera u klasteru — cloud mreža multicast ne podržava. Rešenje: aplikacija se prepodešava na unicast otkrivanje.

5. Praktična vežba / napomena

Za svaki modul ovog kursa od 7 do 16 odredite da li se njegovo znanje u cloud-u primenjuje direktno, izmenjeno, ili se ne primenjuje (npr. STP — ne primenjuje se; subnetting — direktno).

6. Najčešće greške

• Očekivanje L2 ponašanja (broadcast, multicast, gratuitous ARP za prebacivanje adrese) u cloud-u.
• Pokušaj „hvatanja" saobraćaja kao na lokalnom sviču, umesto korišćenja flow logova.
• Zanemarivanje kvota — napravljeno rešenje ne može da se proširi.

7. Pitanje za proveru znanja

P: Navedite dve mrežne funkcije koje rade u lokalnoj mreži, a u cloud mreži najčešće nisu dostupne. O: Na primer: broadcast/multicast i direktna kontrola sloja 2 (VLAN-ovi, STP, ARP).

Tema 15 – Bezbednost, nadzor i troškovi u cloud mreži

1. Jednostavno objašnjenje

U cloud-u je greška u podešavanju vidljiva celom internetu za nekoliko sekundi, a zaboravljen resurs se naplaćuje svaki sat. Zato su bezbednost, nadzor i kontrola troškova sastavni deo projektovanja mreže.

2. Stručno objašnjenje

Bezbednost:

• IAM (Identity and Access Management) — ko sme da menja mrežu: nalozi sa minimalnim pravima, višefaktorska autentifikacija (MFA), bez svakodnevnog korišćenja root naloga.
• Najmanje izlaganje — samo load balancer i neophodni servisi u javnim subnetima; administrativni pristup preko VPN-a ili upravljanih usluga, bez otvorenog SSH/RDP-a.
• Slojevi odbrane — SG + NACL + (opciono) cloud firewall ili WAF za veb aplikacije.

Nadzor (Modul 23): VPC Flow Logs (zapisi o dozvoljenim i odbijenim tokovima), zapisi o API pozivima (npr. AWS CloudTrail — ko je i kada promenio SG), metrike i upozorenja (npr. CloudWatch).

Kontrola troškova: upozorenja o budžetu (npr. AWS Budgets), oznake (tags) na svim resursima (projekat, vlasnik, okruženje), redovno brisanje nekorišćenih resursa. Najčešći mrežni troškovi: NAT gateway, javne IPv4 adrese, load balancer-i, saobraćaj ka internetu i između zona i regiona (dolazni saobraćaj je najčešće besplatan).

Infrastruktura kao kod (Modul 24): Terraform, AWS CloudFormation, Azure Bicep — mreža se opisuje u fajlovima, verzioniše u Git-u i pravi/briše ponovljivo, što smanjuje greške i olakšava čišćenje.

3. Primer iz svakodnevnog života

Iznajmljen automobil sa taksimetrom na dan: ako ga ne vratite na vreme, račun raste i dok stoji parkiran; a ako ostavite otključana vrata, odgovornost je vaša, ne rent-a-car agencije.

4. Primer iz poslovnog IT okruženja

Student pravi laboratoriju sa NAT gateway-em i load balancer-om i zaboravi da ih obriše; mesec dana kasnije stiže račun od nekoliko desetina dolara. Da je podesio budžet sa upozorenjem od 1 dolara i opisao laboratoriju Terraform-om (terraform destroy), trošak bi bio nekoliko centi.

5. Praktična vežba / napomena

Deo 2 laboratorije počinje podešavanjem upozorenja o budžetu i MFA, a završava obaveznim čišćenjem resursa — navika koju treba steći od prvog dana rada u cloud-u.

6. Najčešće greške

• Svakodnevni rad sa root nalogom bez MFA.
• Pristupni ključevi (access keys) u kodu ili javnom Git repozitorijumu (Modul 24) — zloupotrebljavaju se za nekoliko minuta.
• Resursi bez oznaka — ne zna se čiji su i smeju li da se obrišu.
• Laboratorija ostavljena da radi „do sutra".

7. Pitanje za proveru znanja

P: Navedite tri mrežna resursa koji najčešće izazivaju neočekivane troškove u cloud-u. O: NAT gateway, javne IPv4 adrese, load balancer-i (kao i saobraćaj ka internetu i između zona/regiona).

Rezime modula

• Cloud: samousluga, elastičnost, plaćanje po potrošnji; IaaS/PaaS/SaaS; model podeljene odgovornosti.
• Public, private, hybrid i multi-cloud; za hybrid su ključni adresni plan bez preklapanja i veza.
• Regioni i zone dostupnosti; visoka dostupnost zahteva najmanje dve zone.
• VPC sa CIDR opsegom bez preklapanja; subneti po zonama; 5 rezervisanih adresa po subnetu (AWS/Azure).
• Tabela ruta određuje da li je subnet javni (ruta ka IGW-u) ili privatni; longest prefix match.
• Internet gateway (1:1 NAT za javne adrese) i NAT gateway (PAT, samo izlazno, po jedan u svakoj zoni).
• Security group: stateful, samo allow, na instanci, reference na druge SG-ove; NACL: stateless, allow/deny, numerisana pravila, efemerni portovi.
• Load balancer (ALB L7, NLB L4) sa health check-om u više zona.
• Lokalna mreža ↔ cloud: site-to-site VPN (dva tunela, BGP), namenske veze, transit gateway.
• Isti koncepti postoje u AWS-u, Azure-u i GCP-u pod drugim imenima; cloud nema L2 kontrolu, a promene su softverske.
• Bezbednost (IAM, MFA, minimalno izlaganje), nadzor (flow logs, zapisi o API pozivima) i kontrola troškova (budžeti, oznake, brisanje).

Mermaid dijagram

graph TB
    INET["Internet"] --> IGW["Internet gateway"]
    subgraph VPC["VPC 10.20.0.0/16"]
        subgraph AZA["Zona a"]
            PUBA["Javni subnet 10.20.1.0/24<br/>Load balancer, NAT GW-a"]
            APPA["Privatni subnet 10.20.11.0/24<br/>Aplikacija"]
        end
        subgraph AZB["Zona b"]
            PUBB["Javni subnet 10.20.2.0/24<br/>Load balancer, NAT GW-b"]
            APPB["Privatni subnet 10.20.12.0/24<br/>Aplikacija"]
        end
    end
    IGW --> PUBA
    IGW --> PUBB
    PUBA --> APPA
    PUBB --> APPB
    APPA -->|"0.0.0.0/0"| PUBA
    APPB -->|"0.0.0.0/0"| PUBB
    VGW["VPN gateway<br/>(dva IPsec tunela, BGP)"] --- APPA
    VGW --- APPB
    ONPREM["Lokalna mreža firme<br/>10.10.0.0/16"] --- VGW

Dodatni izvori (opciono)

• NIST SP 800-145 – The NIST Definition of Cloud Computing
• AWS dokumentacija – Amazon VPC User Guide (docs.aws.amazon.com/vpc)
• Microsoft Learn – Azure Virtual Network
• Google Cloud dokumentacija – VPC network overview
• AWS Well-Architected Framework – Reliability i Security stubovi
• Besplatni kursevi provajdera: AWS Skill Builder (Cloud Practitioner Essentials), Microsoft Learn (AZ-900), Google Cloud Skills Boost