Početna › DHCP, DNS, NAT i mrežni servisi › Teorija
💾

Teorija – Modul 13 – DHCP, DNS, NAT i mrežni servisi

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.

Tema 1 – Zašto su potrebni mrežni servisi iznad rutiranja

1. Jednostavno objašnjenje

Ruter zna kako da prosledi paket od jedne mreže do druge (Moduli 11-12), ali sam po sebi ne rešava praktična pitanja: ko će računaru dodeliti IP adresu, kako se ime sajta pretvara u IP adresu, i kako 50 računara sa privatnim adresama izlazi na internet preko samo jedne javne adrese. Za to postoje posebni servisi: DHCP, DNS i NAT.

2. Stručno objašnjenje

Rutiranje (Moduli 11-12) rešava problem kako paket stiže od izvora do odredišta kada su IP adrese već poznate. Tri servisa obrađena u ovom modulu rešavaju tri odvojena, ali podjednako neophodna problema u praksi: DHCP automatizuje dodelu IP adrese, maske, gateway-a i DNS servera krajnjim uređajima (bez njega, administrator bi morao ručno da unosi ove podatke na svakom uređaju pojedinačno — statička konfiguracija, obrađena kroz Static IP Address u ranijim modulima). DNS prevodi ljudima razumljiva imena (npr. www.firma.rs) u IP adrese koje ruteri stvarno koriste za prosleđivanje. NAT rešava neusklađenost između ograničenog broja javnih IPv4 adresa i mnogo većeg broja uređaja koji treba da pristupe internetu, prevodeći privatne (RFC 1918) adrese u javne na granici mreže.

3. Primer iz svakodnevnog života

Zamislite novu zgradu sa 50 stanova. Rutiranje je kao poštanska služba koja zna kako paket stiže do prave ulice i broja. DHCP je kao uprava zgrade koja svakom novom stanaru automatski dodeljuje broj stana čim se useli, umesto da stanar sam bira slobodan broj. DNS je kao imenik u kome tražite „Marko Marković" i dobijate tačnu adresu, umesto da unapred znate broj stana. NAT je kao zajednička poštanska kutija zgrade sa jednom uličnom adresom, kroz koju sva pošta svih 50 stanova ulazi i izlazi, iako svaki stan iznutra ima svoj broj.

4. Primer iz poslovnog IT okruženja

Kada zaposleni u firmi uključi laptop, on za par sekundi automatski dobija IP adresu (DHCP), otvara pretraživač i kuca „firma-crm.local" umesto pamćenja IP adrese servera (DNS), i pristupa internet sajtovima iako laptop ima privatnu adresu 192.168.x.x koja nikada nije vidljiva na internetu (NAT) — sva tri servisa rade nevidljivo u pozadini svakog radnog dana.

5. Praktična vežba / napomena

Na sopstvenom računaru pokrenite ipconfig /all (Windows) ili ip addr (Linux) i pronađite koja adresa je označena kao „DHCP Server" i koja kao „DNS Servers" — to su konkretni uređaji koji vam trenutno pružaju ova dva servisa.

6. Najčešće greške

  • Mešanje DHCP-a (dodela adrese) sa DNS-om (prevod imena u adresu) — ovo su dva potpuno nezavisna servisa koja mogu, ali ne moraju, raditi na istom uređaju.
  • Pretpostavka da NAT „štiti" mrežu kao firewall — NAT postoji prevashodno zbog nedostatka javnih adresa; bezbednosna korist (skrivanje interne topologije) je sporedan efekat, ne primarna namena.

7. Pitanje za proveru znanja

P: Koji problem rešava svaki od tri servisa obrađena u ovom modulu? O: DHCP automatizuje dodelu IP konfiguracije uređajima; DNS prevodi imena u IP adrese; NAT omogućava da više uređaja sa privatnim adresama deli manji broj (ili jednu) javnih adresa.

Tema 2 – DHCP osnove i DORA proces

1. Jednostavno objašnjenje

Kada se računar priključi na mrežu i nema ručno unetu IP adresu, on „viče" u mrežu: „Da li iko ovde može da mi da adresu?" DHCP server odgovara i kroz kratku razmenu četiri poruke, računar dobija svoju adresu, masku, gateway i ostale podatke.

2. Stručno objašnjenje

DHCP (Dynamic Host Configuration Protocol) automatski dodeljuje IP adresu, masku, default gateway, DNS server i druge parametre klijentskim uređajima. Proces dodele adrese naziva se DORA: Discover (klijent šalje broadcast DHCPDISCOVER tražeći bilo koji DHCP server), Offer (server(i) odgovaraju sa DHCPOFFER, nudeći konkretnu adresu), Request (klijent bira jednu ponudu i šalje broadcast DHCPREQUEST, potvrđujući izbor — broadcast, kako bi ostali serveri znali da njihova ponuda nije prihvaćena), Acknowledge (izabrani server šalje DHCPACK, zvanično dodeljujući adresu na određeno lease vreme). Adresa se ne dodeljuje trajno — klijent mora periodično da obnavlja (renew) lease pre isteka, obično na 50% proteklog vremena leasa.

3. Primer iz svakodnevnog života

DORA proces je kao iznajmljivanje sobe u hotelu bez rezervacije: gost pita na recepciji da li ima slobodnih soba (Discover), recepcioner nudi konkretan broj sobe (Offer), gost potvrđuje da želi baš tu sobu (Request), i recepcija zvanično upisuje gosta i daje mu ključ na određeni broj noćenja (Acknowledge) — nakon čega gost mora da produži boravak pre isteka rezervacije ako želi da ostane duže.

4. Primer iz poslovnog IT okruženja

Kada 30 laptopova zaposlenih istovremeno krene sa uključivanjem u ponedeljak ujutru, DHCP server u kancelariji automatski sprovodi DORA proces sa svakim od njih u roku od sekunde, dodeljujući svakom slobodnu adresu iz definisanog opsega — bez DHCP-a, IT osoblje bi moralo ručno da konfiguriše svaki laptop.

5. Praktična vežba / napomena

U Packet Traceru, uključite Simulation Mode i posmatrajte razmenu paketa kada PC konfigurisan na „DHCP" pokuša da dobije adresu — trebalo bi da vidite tačno četiri paketa (Discover, Offer, Request, Ack) u tom redosledu.

6. Najčešće greške

  • Zaboravljanje da je Discover broadcast paket — ako se DHCP server nalazi na drugoj mreži (iza rutera), Discover paket se po podrazumevanom ponašanju rutera neće proslediti, pa je potreban DHCP relay (Tema 4).
  • Mešanje Request faze sa direktnim slanjem serveru — Request je takođe broadcast, upravo da bi svi eventualni drugi DHCP serveri saznali da njihova ponuda nije izabrana i mogli da oslobode tu adresu za druge klijente.

7. Pitanje za proveru znanja

P: Zašto su i Discover i Request poruke u DORA procesu broadcast, a ne unicast? O: Discover je broadcast jer klijent još ne zna adresu nijednog DHCP servera na mreži; Request je broadcast kako bi svi DHCP serveri koji su ponudili adresu saznali da li je njihova ponuda prihvaćena, i da eventualno oslobode ponuđenu adresu ako klijent bira drugog servera.

Tema 3 – Konfiguracija DHCP servera na Cisco ruteru

1. Jednostavno objašnjenje

Cisco ruter može sam da obavlja ulogu DHCP servera za svoju mrežu, umesto da se za to koristi poseban server. Dovoljno je definisati opseg adresa, koje adrese ne treba deliti, i koje dodatne podatke (gateway, DNS) treba poslati klijentima.

2. Stručno objašnjenje

Konfiguracija se sastoji od dva dela: (1) ip dhcp excluded-address <početak> <kraj> u Global Config-u, koja isključuje adrese koje se ne smeju automatski dodeljivati (npr. adresu samog rutera i eventualne statičke servere) — ova naredba se unosi pre definisanja pool-a; (2) ip dhcp pool <ime> koji otvara DHCP pool konfiguracioni režim, unutar kog se definišu network <mreža> <maska> (opseg iz kog se dodeljuju adrese), default-router <adresa> (gateway koji se šalje klijentima), dns-server <adresa> (DNS server koji se šalje klijentima), i opciono lease <dani> <sati> <minuti> (podrazumevano 24 sata ako se ne navede). Server automatski preskače isključene adrese i one koje su već u upotrebi.

3. Primer iz svakodnevnog života

Definisanje DHCP pool-a je kao kada uprava naselja odluči da kućni brojevi od 1 do 5 ostaju rezervisani za upravu i infrastrukturu (excluded-address), a kućni brojevi od 6 do 254 se slobodno dodeljuju novim stanarima (pool/network), pri čemu svaki novi stanar odmah dobija i informaciju gde je izlazna kapija naselja (default-router).

4. Primer iz poslovnog IT okruženja

Administrator kancelarije sa mrežom 192.168.10.0/24 rezerviše prvih devet adresa (.1-.9) za ruter, svič-eve i printer sa statičkim adresama, a ostatak (.10-.254) prepušta DHCP-u za radne stanice:

ip dhcp excluded-address 192.168.10.1 192.168.10.9
ip dhcp pool LAN-KANCELARIJA
 network 192.168.10.0 255.255.255.0
 default-router 192.168.10.1
 dns-server 8.8.8.8
 lease 7

5. Praktična vežba / napomena

Nakon konfiguracije, na PC-u u Packet Traceru izaberite „DHCP" u IP Configuration-u i proverite da li je adresa dodeljena iz očekivanog opsega, sa ispravnim gateway-om. Na ruteru proverite show ip dhcp binding da vidite listu trenutno dodeljenih adresa.

6. Najčešće greške

  • Unos ip dhcp excluded-address nakon što je pool već aktivan i adrese već dodeljene — server neće automatski povući već izdate adrese, isključenje važi samo za buduće dodele.
  • Zaboravljanje default-router u pool-u — klijenti dobijaju IP adresu, ali bez gateway-a ne mogu da komuniciraju van sopstvene mreže.
  • Definisanje pool mreže koja se preklapa sa drugim pool-om ili sa statički dodeljenim adresama, izazivajući duplikate adresa (IP conflict).

7. Pitanje za proveru znanja

P: Zašto se ip dhcp excluded-address mora uneti pre nego što DHCP pool počne da dodeljuje adrese iz tog opsega? O: Zato što DHCP server ne povlači već izdate adrese kada se naknadno doda isključenje — ako se adresa rutera ili drugog statičkog uređaja slučajno dodeli DHCP klijentu pre nego što je isključena, može doći do konflikta adresa.

Tema 4 – DHCP Relay (ip helper-address)

1. Jednostavno objašnjenje

DHCP Discover poruka je broadcast, a broadcast po pravilu ne prelazi preko rutera. Ako se DHCP server nalazi na drugoj mreži od klijenta, potreban je „posrednik" koji tu poruku pretvara u unicast i prosleđuje je serveru — to je DHCP relay.

2. Stručno objašnjenje

Naredba ip helper-address <adresa-DHCP-servera>, konfigurisana na interfejsu rutera koji je najbliži DHCP klijentima (obično LAN interfejs udaljene mreže), čini ruter DHCP relay agentom: ruter prima broadcast DHCPDISCOVER na tom interfejsu, pretvara ga u unicast paket upućen direktno konfigurisanom DHCP serveru (dodajući giaddr polje sa adresom relay interfejsa, koje serveru govori iz koje mreže/pool-a treba dodeliti adresu), i prosleđuje odgovor nazad klijentu. Bez ovoga, DHCP server konfigurisan na jednom ruteru ne bi mogao da opslužuje klijente na udaljenim mrežama povezanim preko drugih rutera. Napomena: ip helper-address po podrazumevanom ponašanju prosleđuje ne samo DHCP, već i nekoliko drugih UDP broadcast servisa (npr. TFTP, DNS, NetBIOS) — ovo se retko koristi u praksi za druge servise, ali je korisno znati.

3. Primer iz svakodnevnog života

DHCP relay je kao recepcioner u poslovnici koji ne može sam da izda novi ugovor, ali prosleđuje zahtev centrali (DHCP serveru u drugom gradu) u ime klijenta, i vraća klijentu gotov ugovor kada centrala odgovori — klijent nikada direktno ne razgovara sa centralom.

4. Primer iz poslovnog IT okruženja

Firma ima centralni DHCP server konfigurisan na ruteru u centrali (10.0.0.1), dok poslovnica ima sopstveni ruter i lokalnu mrežu 192.168.20.0/24. Na LAN interfejsu rutera poslovnice unosi se ip helper-address 10.0.0.1, čime klijenti u poslovnici dobijaju adrese iz istog centralizovanog DHCP servera, bez potrebe za posebnim DHCP serverom u svakoj poslovnici.

5. Praktična vežba / napomena

U laboratorijskoj vežbi ovog modula, konfigurisaćete ip helper-address na LAN interfejsu udaljenog rutera, usmeravajući ga ka DHCP pool-u definisanom na centralnom ruteru za tu konkretnu udaljenu mrežu — proverite da PC u udaljenoj mreži zaista dobija adresu iz očekivanog opsega, ne iz opsega lokalne mreže centralnog rutera.

6. Najčešće greške

  • Zaboravljanje da na centralnom DHCP serveru mora postojati poseban ip dhcp pool sa network naredbom koja odgovara mreži udaljenih klijenata — relay samo prosleđuje zahtev, server i dalje mora imati definisan opseg za tu konkretnu mrežu.
  • Konfigurisanje ip helper-address na pogrešnom interfejsu (npr. na WAN interfejsu umesto na LAN interfejsu najbližem klijentima).

7. Pitanje za proveru znanja

P: Zašto je DHCP relay potreban kada su DHCP klijent i server na različitim mrežama? O: Zato što je DHCPDISCOVER broadcast poruka, koja se po podrazumevanom ponašanju rutera ne prosleđuje između mreža; DHCP relay agent prima taj broadcast lokalno i prosleđuje ga kao unicast direktno DHCP serveru, a zatim vraća odgovor klijentu.

Tema 5 – DNS osnove i hijerarhija

1. Jednostavno objašnjenje

DNS je „telefonski imenik interneta" — pretvara imena koja ljudi pamte (kao www.google.com) u IP adrese koje ruteri stvarno koriste. Ta imena su organizovana u hijerarhiju, sličnu organizaciji direktorijuma na disku.

2. Stručno objašnjenje

DNS (Domain Name System) je hijerarhijski, distribuirani sistem imenovanja koji prevodi domenska imena u IP adrese (i obrnuto). Hijerarhija ide od root zone (predstavljena tačkom, obično nevidljivom, npr. „www.firma.rs."), preko TLD (Top-Level Domain) servera (npr. „.rs", „.com", „.org"), do autoritativnog servera za konkretan domen (npr. „firma.rs"), koji poseduje stvarne podatke (zone file) za taj domen. Svaki nivo hijerarhije „zna" samo gde da uputi upit za sledeći, specifičniji nivo — nijedan pojedinačni server ne poseduje kompletnu bazu celog interneta.

3. Primer iz svakodnevnog života

DNS hijerarhija je kao poštanska adresa: država (TLD, npr. „.rs") → grad → ulica → kućni broj (autoritativni server konkretnog domena) — svaki nivo zna samo dovoljno da uputi pošiljku na sledeći, precizniji nivo, bez potrebe da poznaje tačnu lokaciju svake kuće u državi.

4. Primer iz poslovnog IT okruženja

Firma koja registruje domen „firma.rs" postavlja sopstveni ili iznajmljeni autoritativni DNS server koji sadrži tačne zapise za taj domen (npr. mail.firma.rs, www.firma.rs) — kada bilo ko na internetu pokuša da pristupi tim adresama, upit se na kraju prosleđuje baš tom autoritativnom serveru radi konačnog odgovora.

5. Praktična vežba / napomena

Na svom računaru pokrenite nslookup www.google.com (ili dig www.google.com na Linuxu) i pogledajte koji DNS server je odgovorio i koju IP adresu je vratio.

6. Najčešće greške

  • Mešanje pojmova „DNS server" i „autoritativni DNS server" — svaki DNS resolver (npr. onaj kod ISP-a) odgovara na upite, ali samo autoritativni server konkretnog domena poseduje „izvornu istinu" o tom domenu.
  • Pretpostavka da postoji jedan centralni „glavni" DNS server za ceo internet — DNS je namerno dizajniran kao distribuiran sistem bez jedne centralne tačke otkaza.

7. Pitanje za proveru znanja

P: Kojim redosledom DNS hijerarhija usmerava upit za „www.firma.rs"? O: Root zona → TLD server za „.rs" → autoritativni server za domen „firma.rs", koji vraća konačan odgovor za „www.firma.rs".

Tema 6 – DNS zapisi (A, AAAA, CNAME, MX, NS, PTR, TXT)

1. Jednostavno objašnjenje

DNS ne čuva samo „ime → IPv4 adresa" — postoje različite vrste zapisa za različite namene: IPv6 adrese, alternativna imena, mail servere, i još mnogo toga.

2. Stručno objašnjenje

Najčešći tipovi DNS zapisa: A (Address) — mapira ime u IPv4 adresu; AAAA — mapira ime u IPv6 adresu; CNAME (Canonical Name) — mapira jedno ime kao alias drugog imena (npr. „ftp.firma.rs" pokazuje na „server1.firma.rs", koje dalje ima A zapis); MX (Mail Exchange) — određuje koji server prima e-mail poštu za dati domen, sa prioritetom (niži broj = veći prioritet); NS (Name Server) — određuje koji server(i) su autoritativni za dati domen; PTR (Pointer) — obrnuto mapiranje, IP adresa → ime (koristi se za reverse DNS lookup); TXT — proizvoljan tekstualni podatak, često korišćen za verifikaciju vlasništva domena ili SPF/DKIM zapise vezane za e-mail bezbednost.

3. Primer iz svakodnevnog života

A zapis je kao broj telefona osobe (direktna veza imena i broja). CNAME je kao „nadimak" koji vas usmerava na istu osobu pod drugim imenom u imeniku. MX zapis je kao oznaka na poštanskom sandučetu koja govori „svu poštu za ovu zgradu prima portir na broju 5", umesto da svaki stan prima poštu direktno.

4. Primer iz poslovnog IT okruženja

Firma „firma.rs" ima: A zapis „www.firma.rs → 203.0.113.10" (veb sajt), MX zapis „firma.rs → mail.firma.rs, prioritet 10" (gde se šalje e-mail pošta za @firma.rs adrese), CNAME „webmail.firma.rs → mail.firma.rs" (alias), i TXT zapis korišćen za SPF proveru da bi se sprečilo lažiranje pošiljaoca e-mail poruka u ime firma.rs domena.

5. Praktična vežba / napomena

Pokrenite nslookup -type=MX gmail.com (ili ekvivalentnu komandu) i pogledajte koji mail serveri i sa kojim prioritetom su vraćeni kao odgovor.

6. Najčešće greške

  • Mešanje A i CNAME zapisa — CNAME uvek pokazuje na drugo ime, ne direktno na IP adresu; ako se CNAME lanac pogrešno postavi (kruži sam u sebe ili je predugačak), rezolucija ne uspeva.
  • Zaboravljanje da niži broj MX prioriteta znači veći prioritet (server se pokušava prvi) — česta zabuna sa uobičajenim očekivanjem da „veći broj = važnije".

7. Pitanje za proveru znanja

P: Koji DNS zapis biste koristili da odredite koji server prima e-mail poštu za dati domen, i koji zapis biste koristili za obrnuto mapiranje IP adrese u ime? O: MX zapis za mail server; PTR zapis za obrnuto mapiranje (IP → ime).

Tema 7 – Rekurzivni naspram iterativnog DNS upita

1. Jednostavno objašnjenje

Kada vaš računar pita DNS server za adresu sajta, taj server može ili sam da „otrči" i pronađe kompletan odgovor pre nego što vam se javi (rekurzivno), ili da vam samo kaže „pitaj sledećeg", prepuštajući vama da nastavite potragu (iterativno).

2. Stručno objašnjenje

U rekurzivnom upitu, klijent (ili lokalni resolver, npr. kod ISP-a) postavlja upit i očekuje konačan odgovor od servera kome se obratio — taj server preuzima odgovornost da sam, u ime klijenta, kontaktira sve potrebne servere u hijerarhiji (root → TLD → autoritativni) dok ne dobije konačan odgovor. U iterativnom upitu, server kome se obratite vraća najbolji odgovor koji ima (često „ne znam, ali pitaj ovog servera dalje"), a onaj ko je postavio upit sam nastavlja lanac pitanja. U praksi, klijentski uređaji gotovo uvek postavljaju rekurzivne upite svom rekurzivnom resolveru (npr. serveru ISP-a ili javnom DNS servisu), dok taj resolver dalje sa serverima u hijerarhiji najčešće komunicira iterativno.

3. Primer iz svakodnevnog života

Rekurzivni upit je kao kada zamolite asistenta da vam „nabavi odgovor" i on sam obavi sve potrebne pozive dok se ne vrati sa konačnom informacijom. Iterativni upit je kao kada vam neko kaže „ja ne znam, ali probaj da pitaš onu osobu" — vi sami nastavljate lanac pitanja dok ne dobijete odgovor.

4. Primer iz poslovnog IT okruženja

Kada zaposleni u kucaju „intranet.firma.rs" u pretraživaču, njihov računar šalje rekurzivni upit ka internom DNS serveru firme; ako taj server nema odgovor u sopstvenom kešu, on sam (rekurzivno, sa stanovišta zaposlenog) ili iterativno (sa stanovišta samog servera) nastavlja potragu kroz hijerarhiju dok ne pronađe autoritativni odgovor, koji zatim vraća zaposlenom i pamti (kešira) za buduće upite.

5. Praktična vežba / napomena

Razmislite o razlici između prvog i drugog puta kada otvorite isti sajt u kratkom vremenskom razmaku — drugi put je odgovor obično brži jer je DNS resolver sačuvao (keširao) prethodni odgovor umesto da ponovo prolazi kroz celu hijerarhiju.

6. Najčešće greške

  • Pretpostavka da klijentski uređaj sam direktno komunicira sa root/TLD serverima — u praksi to gotovo uvek radi rekurzivni resolver u ime klijenta.
  • Zaboravljanje uloge DNS keširanja — ono značajno smanjuje broj upita koji zaista moraju proći kroz celu hijerarhiju, i objašnjava zašto DNS promene (npr. promena IP adrese sajta) ne postaju vidljive svima trenutno (TTL zapisa određuje koliko dugo se odgovor pamti).

7. Pitanje za proveru znanja

P: Ko obično postavlja rekurzivne upite, a ko iterativne, u tipičnom DNS scenariju? O: Klijentski uređaj postavlja rekurzivni upit svom lokalnom/ISP DNS resolveru, očekujući konačan odgovor; taj resolver zatim najčešće iterativno komunicira sa serverima u DNS hijerarhiji (root, TLD, autoritativni) da bi taj konačan odgovor pronašao.

Tema 8 – Klijentska DNS konfiguracija na Cisco ruteru

1. Jednostavno objašnjenje

I sam ruter ponekad treba da „razume" imena, na primer kada administrator pokuša da se poveže na drugi uređaj koristeći ime umesto IP adrese. Da bi to radilo, ruter mora znati koji DNS server da koristi.

2. Stručno objašnjenje

Tri komande omogućavaju klijentsku DNS rezoluciju na Cisco IOS-u: ip domain-name <domen> postavlja podrazumevani domen koji se automatski dodaje nepotpunim imenima (npr. ako administrator ukuca ping server1, ruter pokušava server1.firma.rs); ip name-server <adresa1> [adresa2 ...] definiše do šest DNS servera koje ruter koristi za rezoluciju; ip domain-lookup (uključeno podrazumevano, ali se često isključuje sa no ip domain-lookup u laboratorijskim okruženjima) omogućava/onemogućava DNS rezoluciju uopšte — česta praksa je isključivanje ove opcije u produkciji bez konfigurisanog DNS-a, jer u suprotnom svaka pogrešno otkucana komanda u CLI-ju izaziva ruter da pokuša (sporu) DNS rezoluciju tog „imena" pre nego što prijavi grešku.

3. Primer iz svakodnevnog života

Ovo je kao kada telefon podesite da automatski doda pozivni broj grada kada birate lokalni broj (ip domain-name), uz to da unapred znate koju telefonsku centralu (DNS server, ip name-server) da pozovete za tačnu informaciju.

4. Primer iz poslovnog IT okruženja

Administrator koji greškom u Privileged EXEC modu ukuca hsotname umesto hostname primetiće da ruter „zastane" na nekoliko sekundi pokušavajući DNS rezoluciju tog pogrešno otkucanog imena kao hosta — ako ip domain-lookup nije isključen, a nijedan DNS server nije konfigurisan/dostupan. Ovo je čest, frustrirajući problem koji se rešava sa no ip domain-lookup u okruženjima gde ruteru DNS rezolucija nije zaista potrebna.

5. Praktična vežba / napomena

Konfigurišite ip domain-name firma.rs i ip name-server 8.8.8.8 na ruteru, zatim probajte ping server1 (bez punog imena) i posmatrajte u debug ip domain (opciono, oprezno) kako ruter dopunjava ime u server1.firma.rs pre pokušaja rezolucije.

6. Najčešće greške

  • Ostavljanje ip domain-lookup uključenim u laboratorijskom/testnom okruženju bez ijednog DNS servera — svaka pogrešno otkucana komanda izaziva neželjeno čekanje.
  • Mešanje klijentske DNS konfiguracije rutera (ova tema) sa DNS serverskom ulogom — Cisco IOS ruter u ovom kontekstu je samo DNS klijent koji koristi eksterni DNS server, ne pruža DNS uslugu drugima (za razliku od DHCP servera koji ruter aktivno pruža, Tema 3).

7. Pitanje za proveru znanja

P: Zašto se no ip domain-lookup često koristi u laboratorijskim okruženjima? O: Da bi se sprečilo da ruter pokuša (sporu, često neuspešnu) DNS rezoluciju svake pogrešno otkucane komande kao da je ime hosta, što bi izazvalo neželjeno čekanje pre prijave greške o nepoznatoj komandi.

Tema 9 – NAT osnove i motivacija

1. Jednostavno objašnjenje

Postoji ograničen broj javnih IPv4 adresa na svetu — daleko manje nego uređaja koji žele pristup internetu. NAT rešava ovo tako što više uređaja sa privatnim adresama „dele" jednu (ili nekoliko) javnih adresa na izlazu iz mreže.

2. Stručno objašnjenje

NAT (Network Address Translation), standardizovan kroz RFC 1631, prevodi IP adrese između dva adresna prostora — najčešće između privatnih adresa (RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) korišćenih unutar organizacije i javnih, globalno rutabilnih adresa korišćenih na internetu. NAT nastaje kao rešenje za iscrpljivanje IPv4 adresnog prostora (samo ~4,3 milijarde mogućih IPv4 adresa, daleko manje od broja uređaja povezanih na internet danas) — umesto da svaki uređaj zahteva sopstvenu javnu adresu, granični ruter (NAT gateway) prevodi adrese na izlazu, omogućavajući da hiljade internih uređaja dele mnogo manji broj (ili samo jednu) javnih adresa. NAT konfiguracija zahteva da se interfejsi eksplicitno označe kao ip nat inside (interni, privatni deo mreže) ili ip nat outside (spoljni, javni deo mreže) — prevod se dešava tačno na granici između te dve zone.

3. Primer iz svakodnevnog života

NAT je kao centrala firme koja ima samo jedan javni broj telefona za spoljne pozive, dok svaki zaposleni unutar zgrade ima svoj interni broj lokala — kada zaposleni zove van firme, centrala „prevodi" njegov interni lokal u zajednički javni broj, a kada odgovor stigne, centrala zna kome unutra da ga prosledi.

4. Primer iz poslovnog IT okruženja

Kancelarija sa 200 računara i samo jednom javnom IP adresom dobijenom od ISP-a koristi NAT na graničnom ruteru da bi svih 200 računara istovremeno moglo da pristupa internetu preko te jedne javne adrese — bez NAT-a, firma bi morala da plati 200 zasebnih javnih adresa, što je i skupo i praktično nemoguće u modernim uslovima nestašice IPv4 adresa.

5. Praktična vežba / napomena

Proverite sopstvenu privatnu IP adresu na računaru (ipconfig/ip addr) i uporedite je sa javnom adresom koju vidi spoljni sajt (npr. pretragom „what is my ip" u pretraživaču) — razlika između te dve adrese je upravo NAT prevod koji se dešava na vašem kućnom ruteru.

6. Najčešće greške

  • Zaboravljanje da se ip nat inside i ip nat outside moraju eksplicitno konfigurisati na odgovarajućim interfejsima — bez ovoga, NAT komande postoje u konfiguraciji, ali se prevod nikada ne dešava jer ruter ne zna gde je „unutra", a gde „spolja".
  • Mešanje NAT-a sa firewall-om — NAT sam po sebi ne blokira saobraćaj po pravilima bezbednosti, iako kao sporedni efekat otežava direktan dolazni pristup internim uređajima bez dodatne static NAT konfiguracije.

7. Pitanje za proveru znanja

P: Koji osnovni problem NAT rešava, i koje dve oznake interfejsa su neophodne da bi NAT uopšte radio? O: NAT rešava nedostatak dovoljnog broja javnih IPv4 adresa za sve uređaje koji trebaju pristup internetu; potrebne oznake su ip nat inside (interni interfejs) i ip nat outside (spoljni interfejs).

Tema 10 – Static NAT

1. Jednostavno objašnjenje

Static NAT trajno vezuje jednu internu (privatnu) adresu za tačno jednu eksternu (javnu) adresu — koristi se kada server unutar mreže mora uvek biti dostupan spolja pod istom javnom adresom.

2. Stručno objašnjenje

Static NAT konfiguriše se naredbom ip nat inside source static <privatna-adresa> <javna-adresa> u Global Config-u. Prevod je fiksan i trajan — postoji u NAT tabeli čak i bez ikakvog aktivnog saobraćaja, za razliku od dynamic NAT-a i PAT-a čiji se unosi kreiraju tek kada saobraćaj krene. Static NAT se koristi isključivo kada je potrebno da spoljni korisnici mogu inicirati konekciju ka internom uređaju pod predvidljivom, uvek istom javnom adresom — npr. za veb server, mail server ili VPN uređaj koji mora biti dostupan spolja.

3. Primer iz svakodnevnog života

Static NAT je kao stalna, trajno dodeljena poštanska pregrada u zajedničkom poštanskom centru — uvek isti spoljni broj pregrade vodi tačno do istog unutrašnjeg primaoca, bez obzira na to da li trenutno stiže pošiljka.

4. Primer iz poslovnog IT okruženja

Firma hostuje sopstveni veb server na internoj adresi 192.168.1.100 i želi da bude dostupan na internetu preko javne adrese 203.0.113.50:

ip nat inside source static 192.168.1.100 203.0.113.50

Sada svaki spoljni korisnik koji pristupi 203.0.113.50 biva automatski preusmeren (translated) ka internom serveru 192.168.1.100.

5. Praktična vežba / napomena

Nakon konfiguracije static NAT-a, proverite show ip nat translations — static prevod će biti vidljiv odmah, čak i bez ijednog paketa saobraćaja, za razliku od dynamic/PAT unosa koji se pojavljuju tek nakon prvog paketa.

6. Najčešće greške

  • Korišćenje static NAT-a za sve interne uređaje umesto samo za servere kojima je zaista potreban dolazni pristup spolja — ovo nepotrebno troši ograničen broj javnih adresa, za razliku od PAT-a koji je efikasniji za obične klijente.
  • Zaboravljanje da server i dalje mora imati ispravno podešen firewall/ACL, jer static NAT sam po sebi ne ograničava koji spoljni saobraćaj sme da stigne do servera.

7. Pitanje za proveru znanja

P: Po čemu se static NAT prevod razlikuje od dynamic NAT/PAT prevoda u pogledu trajanja u NAT tabeli? O: Static NAT prevod je trajan i postoji u tabeli čak i bez aktivnog saobraćaja; dynamic NAT i PAT unosi se kreiraju tek kada saobraćaj zaista počne i ističu nakon perioda neaktivnosti.

Tema 11 – Dynamic NAT

1. Jednostavno objašnjenje

Dynamic NAT dodeljuje javnu adresu iz unapred definisanog „bazena" (pool) javnih adresa, privremeno, dok interni uređaj aktivno komunicira sa internetom — za razliku od static NAT-a, veza između privatne i javne adrese nije fiksna.

2. Stručno objašnjenje

Dynamic NAT konfiguriše se u tri koraka: (1) definisanje ACL-a koji identifikuje koje interne mreže/adrese smeju biti prevedene, npr. access-list 1 permit 192.168.1.0 0.0.0.255; (2) definisanje pool-a javnih adresa, npr. ip nat pool JAVNE-ADRESE 203.0.113.10 203.0.113.20 netmask 255.255.255.0; (3) povezivanje ACL-a i pool-a naredbom ip nat inside source list 1 pool JAVNE-ADRESE. Kada interni uređaj iz dozvoljenog opsega pokrene saobraćaj ka spolja, ruter mu privremeno dodeljuje jednu od slobodnih adresa iz pool-a (jedan-na-jedan prevod, kao static, ali sa dinamičkim, privremenim dodeljivanjem); ako su sve adrese iz pool-a zauzete, dodatni interni uređaji ne mogu da komuniciraju dok se neka adresa ne oslobodi.

3. Primer iz svakodnevnog života

Dynamic NAT je kao parking sa ograničenim brojem numerisanih mesta rezervisanih za zaposlene jedne firme — svako vozilo koje uđe dobija slobodno mesto iz tog skupa dok je na poslu, ali kada su sva mesta zauzeta, sledeće vozilo mora da sačeka da se neko mesto oslobodi.

4. Primer iz poslovnog IT okruženja

Firma sa blokom od 10 javnih adresa (203.0.113.10-203.0.113.20) i internom mrežom od 50 računara koristi dynamic NAT da automatski dodeljuje jednu od tih 10 adresa svakom računaru koji aktivno komunicira sa internetom — ali pošto ima samo 10 javnih adresa za 50 računara, može doći do zagušenja ako više od 10 računara istovremeno pokuša pristup, što nagoveštava zašto je PAT (Tema 12) mnogo praktičnije rešenje u većini realnih scenarija.

5. Praktična vežba / napomena

Konfigurišite dynamic NAT sa pool-om od samo dve adrese i tri interna PC-a; pokušajte da sva tri istovremeno pristupe „internetu" (simuliranom serveru) i posmatrajte da treći PC ne uspeva da komunicira dok se jedna od dve adrese ne oslobodi (nakon isteka NAT timeout-a ili prestanka saobraćaja prva dva PC-a).

6. Najčešće greške

  • Definisanje premalog pool-a u odnosu na stvarni broj internih uređaja koji istovremeno trebaju pristup internetu — dovodi do povremenog gubitka konekcije za uređaje kojima nije dostupna slobodna adresa.
  • Zaboravljanje da dynamic NAT i dalje predstavlja odnos jedan-na-jedan (jedna privatna : jedna javna adresa u datom trenutku) — ne rešava suštinski problem nedostatka adresa bolje od static NAT-a, samo automatizuje dodelu; za pravu uštedu adresa potreban je PAT.

7. Pitanje za proveru znanja

P: Šta se dešava kada su sve adrese iz dynamic NAT pool-a već u upotrebi i novi interni uređaj pokuša pristup internetu? O: Taj uređaj ne može da komunicira sa internetom dok se neka adresa iz pool-a ne oslobodi (dok neki drugi interni uređaj ne završi svoju sesiju i njegov NAT unos ne istekne).

Tema 12 – PAT (NAT Overload)

1. Jednostavno objašnjenje

PAT rešava problem nedostatka adresa na najefikasniji način — umesto da svaki interni uređaj dobije zasebnu javnu adresu (kao kod static/dynamic NAT-a), svi interni uređaji dele jednu jedinu javnu adresu, razlikujući se po broju porta.

2. Stručno objašnjenje

PAT (Port Address Translation), na Cisco IOS-u konfigurisan kao NAT Overload, prevodi kombinaciju (privatna IP adresa + port) u kombinaciju (javna IP adresa + drugačiji port), omogućavajući da hiljade internih uređaja dele jednu jedinu javnu adresu istovremeno — razlikovanje se vrši na osnovu broja porta (16-bitno polje, teoretski do ~65 536 istovremenih sesija po javnoj adresi). Konfiguriše se naredbom ip nat inside source list <ACL> interface <izlazni-interfejs> overload (koristi adresu samog izlaznog interfejsa) ili ip nat inside source list <ACL> pool <ime-pool-a> overload (koristi pool od jedne ili više adresa, deljenih preko portova). PAT je danas daleko najčešće korišćen oblik NAT-a u kućnim ruterima i malim/srednjim firmama, upravo zbog maksimalne uštede javnih adresa.

3. Primer iz svakodnevnog života

PAT je kao već pomenuta centrala firme sa jednim javnim brojem telefona, ali sada sa mogućnošću da centrala prati interni lokal + trenutni razgovor za svakog zaposlenog istovremeno — stotine zaposlenih mogu istovremeno voditi odvojene razgovore preko istog jednog javnog broja, jer centrala tačno zna koji odgovor treba proslediti kom internom lokalu na osnovu detalja tog konkretnog razgovora (broj porta).

4. Primer iz poslovnog IT okruženja

Tipičan kućni ili mali kancelarijski ruter ima samo jednu javnu IP adresu dobijenu od ISP-a (DHCP sa strane ISP-a), i po podrazumevanom podešavanju koristi PAT (NAT Overload) da omogući svim uređajima u kući/kancelariji (telefonima, laptopovima, TV uređajima) da istovremeno pristupaju internetu preko te jedne adrese:

access-list 1 permit 192.168.1.0 0.0.0.255
ip nat inside source list 1 interface GigabitEthernet0/1 overload

5. Praktična vežba / napomena

Nakon konfigurisanja PAT-a, generišite saobraćaj sa dva različita interna PC-a ka istom spoljnom odredištu i proverite show ip nat translations — primetićete da oba PC-a dele istu javnu IP adresu, ali sa različitim brojevima portova.

6. Najčešće greške

  • Zaboravljanje ključne reči overload — bez nje, ip nat inside source list ... interface ... bi tražio dynamic NAT ponašanje (jedan-na-jedan) sa adresom interfejsa kao „pool" od samo jedne adrese, dozvoljavajući samo jednu istovremenu translaciju umesto hiljada.
  • Mešanje PAT-a sa static NAT-om kada je potreban dolazni pristup ka internom serveru — PAT sam po sebi ne omogućava spoljnim korisnicima da iniciraju konekciju ka internom uređaju (nema unapred poznatog mapiranja porta), za to je i dalje potreban static NAT (Tema 10) ili port forwarding.

7. Pitanje za proveru znanja

P: Na osnovu čega PAT razlikuje saobraćaj različitih internih uređaja koji dele istu javnu IP adresu? O: Na osnovu broja porta — svaka interna sesija dobija drugačiji izvorni port u prevedenom (javnom) paketu, čime ruter zna kom internom uređaju treba proslediti odgovarajući odgovor.

Tema 13 – Terminologija NAT-a i dijagnostika

1. Jednostavno objašnjenje

NAT koristi četiri posebna termina da opiše tačno koja adresa se vidi sa koje strane mreže, u kom trenutku — ovo zvuči komplikovano, ali svaki termin ima jasno, logično značenje.

2. Stručno objašnjenje

Cisco terminologija NAT-a: Inside local — privatna adresa internog uređaja, kako je vidi interna mreža (npr. 192.168.1.10); Inside global — javna adresa koja predstavlja taj isti interni uređaj, kako ga vidi spoljni (javni) svet nakon NAT prevoda (npr. 203.0.113.2); Outside global — stvarna, javna adresa spoljnog (internet) uređaja, kako je svi vide (npr. 8.8.8.8); Outside local — kako interna mreža vidi taj spoljni uređaj (u većini jednostavnih NAT scenarija identično sa outside global, jer se spoljne adrese retko prevode). Dijagnostika NAT-a se oslanja na: show ip nat translations (prikazuje trenutnu NAT tabelu — sve aktivne prevode), show ip nat statistics (prikazuje sažete brojeve — koliko je prevoda aktivno, koje su inside/outside oznake interfejsa, koliko je bilo pokušaja/grešaka), i clear ip nat translation * (briše sve dinamičke NAT unose, korisno pri dijagnostici ili nakon promene konfiguracije).

3. Primer iz svakodnevnog života

Inside local je vaše kućno ime kako vas zovu ukućani; inside global je vaše puno zvanično ime kako vas zove spoljni svet (institucije); outside global je zvanično ime osobe sa kojom komunicirate spolja; outside local bi bilo to isto ime, ali kako ga eventualno drugačije zovu unutar vaše kuće (retko se razlikuje od outside global u praksi).

4. Primer iz poslovnog IT okruženja

Kada administrator dijagnostikuje zašto interni korisnik (192.168.1.10) ne može da pristupi određenom sajtu, prvi korak je provera show ip nat translations da potvrdi da li se uopšte kreira prevod za taj saobraćaj (inside local 192.168.1.10 → inside global npr. 203.0.113.2) — ako prevoda uopšte nema, problem je verovatno u ACL-u koji definiše koji interni saobraćaj sme biti preveden, ne u samom NAT mehanizmu.

5. Praktična vežba / napomena

Nakon generisanja saobraćaja kroz PAT konfiguraciju iz Teme 12, izvršite show ip nat translations i za svaki red identifikujte koja kolona predstavlja inside local, a koja inside global adresu.

6. Najčešće greške

  • Mešanje inside/outside sa local/global — „inside/outside" govori gde se uređaj nalazi (interna ili eksterna mreža), dok „local/global" govori iz čije perspektive se adresa posmatra (lokalne, interne perspektive naspram globalne, javne perspektive).
  • Zaboravljanje da se pokrene clear ip nat translation * nakon promene NAT konfiguracije tokom dijagnostike — stari (dynamic) unosi mogu ostati u tabeli i zbunjivati dijagnostiku sve dok prirodno ne isteknu.

7. Pitanje za proveru znanja

P: Šta predstavlja „inside global" adresa u NAT terminologiji? O: Javna adresa koja predstavlja interni uređaj, onako kako ga vidi spoljni (javni) svet nakon što je NAT izvršio prevod njegove privatne (inside local) adrese.

Tema 14 – NTP (sinhronizacija vremena)

1. Jednostavno objašnjenje

Da bi mrežni uređaji mogli tačno da beleže KADA se nešto desilo (npr. kvar ili bezbednosni incident), svi moraju imati usklađen sat — NTP automatski sinhronizuje vreme na svim uređajima sa pouzdanim izvorom.

2. Stručno objašnjenje

NTP (Network Time Protocol) sinhronizuje sat mrežnih uređaja sa jednim ili više pouzdanih izvora vremena (NTP serverima), organizovanim u hijerarhiju stratuma (Stratum 0 su precizni izvori poput atomskih satova/GPS prijemnika, koji se ne povezuju direktno na mrežu; Stratum 1 serveri su direktno povezani na Stratum 0 izvore; Stratum 2 serveri sinhronizuju se sa Stratum 1, i tako dalje). Na Cisco IOS-u, klijentska konfiguracija je jednostavna: ntp server <adresa-NTP-servera>. Tačno i usklađeno vreme je kritično za: tumačenje redosleda događaja u log fajlovima sa više uređaja (Syslog, Tema 15), validnost digitalnih sertifikata i vremenski osetljivih bezbednosnih mehanizama, i tačnost timestamp-ova u dijagnostici problema koji se dešavaju na više uređaja istovremeno.

3. Primer iz svakodnevnog života

NTP je kao radio signal koji sinhronizuje sve zidne časovnike u zgradi sa jednim tačnim, pouzdanim vremenom — bez njega, svaki časovnik bi vremenom počeo da „kasni" ili „žuri" na svoj način, čineći nemogućim pouzdano poređenje „ko je stigao pre koga" između različitih prostorija.

4. Primer iz poslovnog IT okruženja

Kada se desi bezbednosni incident koji zahvata tri različita uređaja (svič, ruter, server), istražitelj mora da poveže log zapise sa sva tri uređaja hronološkim redosledom da bi razumeo šta se tačno desilo — ovo je moguće samo ako su satovi sva tri uređaja bili sinhronizovani preko NTP-a; bez toga, log zapisi mogu imati vremenske razlike od nekoliko minuta ili više, čineći rekonstrukciju događaja nepouzdanom.

5. Praktična vežba / napomena

Na ruteru unesite ntp server <adresa> (u Packet Traceru se ovo može simulirati sa uređajem koji igra ulogu NTP servera) i proverite status sinhronizacije komandom show ntp status i show ntp associations.

6. Najčešće greške

  • Konfigurisanje samo jednog NTP servera u produkcionom okruženju — preporučuje se najmanje tri izvora radi pouzdanosti (ako se dva slažu, a treći odstupa, lakše je identifikovati koji je pogrešan).
  • Zanemarivanje NTP-a jer „sat rutera izgleda tačno" — vizuelna tačnost u trenutku provere ne garantuje da neće doći do drifta (postepenog odstupanja) tokom vremena bez aktivne sinhronizacije.

7. Pitanje za proveru znanja

P: Zašto je tačna sinhronizacija vremena posebno važna kada se log zapisi prikupljaju sa više različitih mrežnih uređaja? O: Bez sinhronizovanog vremena (NTP), nemoguće je pouzdano odrediti tačan hronološki redosled događaja zabeleženih na različitim uređajima, što otežava rekonstrukciju incidenta ili dijagnostiku problema koji zahvata više uređaja.

Tema 15 – Syslog i SNMP

1. Jednostavno objašnjenje

Umesto da se administrator loguje na svaki uređaj pojedinačno da bi video šta se dešava, Syslog šalje poruke o događajima na centralni server, a SNMP omogućava tom centralnom sistemu da aktivno „pita" uređaje o njihovom trenutnom stanju (npr. opterećenju, temperaturi).

2. Stručno objašnjenje

Syslog je standardizovan protokol (RFC 5424) za slanje poruka o događajima (log zapisa) sa mrežnog uređaja ka centralnom Syslog serveru, obično preko UDP porta 514. Svaka Syslog poruka ima severity nivo (0=Emergency do 7=Debug, gde niži broj znači ozbiljniji događaj). Na Cisco IOS-u, osnovna konfiguracija je logging <adresa-syslog-servera> i logging trap <nivo> (određuje koji nivoi ozbiljnosti se šalju). SNMP (Simple Network Management Protocol) omogućava centralnom sistemu za nadzor (NMS — Network Management System) da aktivno upituje (GET) mrežne uređaje o njihovom stanju (npr. iskorišćenost interfejsa, temperatura, CPU), ili da uređaj sam proaktivno pošalje upozorenje (trap) kada se desi značajan događaj (npr. interfejs pao). SNMP koristi community string (u starijim verzijama SNMPv1/v2c, slično lozinci u čistom tekstu) ili robustniju autentifikaciju/enkripciju u SNMPv3.

3. Primer iz svakodnevnog života

Syslog je kao dnevnik smena u fabrici u koji svaki radnik automatski upisuje značajne događaje (kvar mašine, završen zadatak) u centralnu knjigu, umesto da menadžer mora lično da obilazi svaku stanicu i pita šta se desilo. SNMP je kao menadžer koji povremeno pozove svaku stanicu da pita „kako stojite" (GET), ali i stanica koja sama pozove menadžera odmah čim se nešto ozbiljno pokvari (trap), bez čekanja na sledeći redovni poziv.

4. Primer iz poslovnog IT okruženja

NOC (Network Operations Center) tim velike firme centralizuje sve Syslog poruke sa desetina rutera i svič-eva na jedan server, uz automatska upozorenja (alerting) kada se pojavi poruka visoke ozbiljnosti (npr. „interfejs down"); istovremeno, SNMP monitoring sistem (npr. PRTG, Zabbix, SolarWinds) redovno (na svakih par minuta) upitima proverava iskorišćenost linkova i CPU opterećenje svih uređaja, gradeći grafike trendova tokom vremena i šaljući trap upozorenje čim neki uređaj pređe kritičan prag.

5. Praktična vežba / napomena

Na ruteru u Packet Traceru konfigurišite logging <adresa> i generišite događaj (npr. shutdown/no shutdown na interfejsu) da vidite tipičnu Syslog poruku o promeni stanja linka (link up/down), koja uključuje severity nivo i timestamp (zavisno od NTP konfiguracije iz Teme 14).

6. Najčešće greške

  • Korišćenje podrazumevanog ili lako pogodivog SNMP community string-a (npr. „public"/„private") u produkcionom okruženju — ovo predstavlja ozbiljan bezbednosni rizik jer omogućava neovlašćen uvid u (ili čak izmenu) konfiguracije uređaja.
  • Podešavanje Syslog trap nivoa previsoko (npr. samo Emergency) — administrator propušta važna upozorenja srednje ozbiljnosti koja bi mogla ukazati na problem pre nego što eskalira u potpuni ispad.

7. Pitanje za proveru znanja

P: Koja je ključna razlika u načinu rada između Syslog-a i SNMP-a u pogledu ko „pokreće" komunikaciju? O: Syslog poruke uređaj sam šalje (push) centralnom serveru kada se desi događaj; SNMP prevashodno radi na principu da centralni sistem aktivno upituje (pull/GET) uređaje, iako SNMP takođe podržava proaktivno slanje trap poruka sličnih Syslog-u za hitne događaje.

Tema 16 – TFTP, FTP, SFTP i pregled SSH-a

1. Jednostavno objašnjenje

Mrežni uređaji povremeno moraju da razmenjuju čitave fajlove (npr. backup konfiguracije ili novu verziju IOS softvera) sa serverom, ne samo pojedinačne poruke — za to postoje protokoli za prenos fajlova, od najjednostavnijih do najbezbednijih.

2. Stručno objašnjenje

TFTP (Trivial File Transfer Protocol), koristi UDP port 69, je najjednostavniji protokol za prenos fajlova, bez autentifikacije i enkripcije — tradicionalno se koristi na Cisco opremi za backup/restore konfiguracije (copy running-config tftp) i IOS image fajlova, upravo zbog svoje jednostavnosti u kontrolisanim internim mrežama. FTP (File Transfer Protocol), obrađen već u Modulu 2, koristi TCP portove 20/21, podržava autentifikaciju, ali šalje podatke (uključujući kredencijale) u čistom tekstu. SFTP (SSH File Transfer Protocol) prenosi fajlove preko already-enkriptovane SSH sesije (TCP port 22, isti port kao SSH iz Modula 7), pružajući i autentifikaciju i punu enkriptovanost — preporučen izbor u modernim, bezbednosno svesnim mrežama umesto FTP-a ili TFTP-a kad god je dostupan. Poređenje bezbednosti: TFTP (bez autentifikacije/enkripcije) < FTP (autentifikacija, bez enkripcije) < SFTP (autentifikacija + enkripcija).

3. Primer iz svakodnevnog života

TFTP je kao ostavljanje paketa na zajedničkom stolu u hodniku bez ikakve provere ko ga uzima — brzo i jednostavno, ali samo bezbedno u potpuno poverljivom okruženju (npr. zaključana interna prostorija). FTP je kao predaja paketa portiru koji proverava ličnu kartu, ali razgovor sa portirom mogu čuti svi u blizini. SFTP je kao predaja paketa kroz zaključanu, oklopljenu cev direktno primaocu, uz proveru identiteta na oba kraja.

4. Primer iz poslovnog IT okruženja

IT tim koji redovno pravi backup konfiguracije desetina rutera unutar zaštićene interne mreže i dalje često koristi TFTP zbog jednostavnosti (copy running-config tftp), oslanjajući se na to da je interna mreža već fizički i logički izolovana; za prenos fajlova preko interneta ili osetljivih podataka, isti tim koristi isključivo SFTP, izbegavajući FTP zbog slanja kredencijala u čistom tekstu koje bi neko sa pristupom mreži mogao presresti.

5. Praktična vežba / napomena

U Packet Traceru postavite Server-PT sa uključenim TFTP servisom i sa rutera izvršite copy running-config tftp, unoseći IP adresu servera i ime fajla — proverite da je fajl uspešno prenet i sačuvan na serveru.

6. Najčešće greške

  • Korišćenje TFTP-a ili FTP-a preko javnog interneta ili nezaštićene mreže za osetljive podatke (uključujući konfiguracije rutera koje mogu sadržati lozinke) — ozbiljan bezbednosni rizik zbog nedostatka enkripcije.
  • Zaboravljanje da SFTP i FTP nisu isti protokol uprkos sličnom imenu i nameni — SFTP radi preko SSH-a (port 22) sa potpuno drugačijim, enkriptovanim mehanizmom, ne preko FTP porta 21 sa dodatkom enkripcije.

7. Pitanje za proveru znanja

P: Poređajte TFTP, FTP i SFTP od najmanje ka najviše bezbednom, i objasnite ukratko zašto. O: TFTP (bez autentifikacije i enkripcije) < FTP (autentifikacija postoji, ali podaci i kredencijali putuju u čistom tekstu) < SFTP (autentifikacija i puna enkripcija preko SSH sesije) — svaki sledeći dodaje sloj zaštite koji prethodni nema.

Rezime modula

  • DHCP automatizuje dodelu IP konfiguracije kroz DORA proces (Discover, Offer, Request, Acknowledge); DHCP relay (ip helper-address) omogućava DHCP serveru da opslužuje udaljene mreže preko broadcast-blokirajućih rutera.
  • DNS prevodi imena u adrese kroz hijerarhiju (root → TLD → autoritativni server), koristeći različite tipove zapisa (A, AAAA, CNAME, MX, NS, PTR, TXT) i rekurzivne/iterativne upite.
  • NAT rešava nedostatak javnih IPv4 adresa prevodeći privatne adrese u javne na granici mreže (ip nat inside/ip nat outside); static NAT je trajno mapiranje jedan-na-jedan, dynamic NAT dodeljuje iz pool-a privremeno, a PAT (NAT Overload) omogućava da hiljade uređaja dele jednu javnu adresu preko brojeva portova.
  • NAT terminologija (inside/outside local/global) opisuje adresu iz perspektive unutrašnje/spoljašnje mreže; show ip nat translations i show ip nat statistics su osnovni dijagnostički alati.
  • NTP sinhronizuje vreme na svim uređajima, što je preduslov za pouzdanu hronologiju u Syslog log zapisima; SNMP omogućava centralizovani nadzor stanja mreže kroz upite (GET) i proaktivna upozorenja (trap).
  • TFTP, FTP i SFTP prenose fajlove (npr. backup konfiguracije) sa rastućim nivoom bezbednosti; SFTP koristi već poznatu SSH infrastrukturu iz Modula 7.

Mermaid dijagram

graph TD
    PC["PC (DHCP klijent)"] -->|"1. DHCPDISCOVER (broadcast)"| R[Ruter / DHCP relay]
    R -->|"2. unicast prosleđivanje"| DHCP[DHCP server]
    DHCP -->|"3. DHCPOFFER"| R
    R -->|"4. prosleđeno klijentu"| PC
    PC -->|"5. nakon DORA: saobraćaj ka internetu"| NAT["NAT granica<br/>inside → outside"]
    NAT -->|"6. prevedena javna adresa"| Internet[Internet]

Dodatni izvori (opciono)

  • RFC 2131 – Dynamic Host Configuration Protocol (DHCP)
  • RFC 1035 – Domain Names – Implementation and Specification (DNS)
  • RFC 1631 / RFC 3022 – The IP Network Address Translator (NAT) / Traditional NAT
  • RFC 1918 – Address Allocation for Private Internets
  • RFC 5905 – Network Time Protocol Version 4 (NTP)
  • RFC 5424 – The Syslog Protocol