Početna › Linux mreže › Teorija
💾

Teorija – Modul 18 – Linux 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.

Tema 1 – Linux mrežni interfejsi

1. Jednostavno objašnjenje

Svaki mrežni adapter na Linux sistemu ima svoje ime, slično Windows konceptu (Modul 17), ali sa drugačijom konvencijom imenovanja koja često izgleda manje intuitivno na prvi pogled.

2. Stručno objašnjenje

Moderni Linux distribucije koriste predvidljivo imenovanje mrežnih interfejsa (predictable network interface names, npr. ens33, enp0s3) umesto starijeg, jednostavnijeg eth0/eth1 — imena kodiraju informacije o fizičkoj lokaciji uređaja (PCI slot, port), obezbeđujući da isti fizički interfejs uvek dobije isto ime čak i nakon dodavanja/uklanjanja druge mrežne kartice (za razliku od starog sistema gde bi redosled mogao da se promeni). Loopback interfejs (lo, ekvivalent Windows loopback-a, Modul 4) uvek postoji i predstavlja sam uređaj (127.0.0.1). U virtuelnim mašinama (VirtualBox), tipično ime prvog interfejsa je enp0s3 ili slično, zavisno od verzije distribucije.

3. Primer iz svakodnevnog života

Predvidljivo imenovanje interfejsa je kao numerisanje parking mesta prema tačnoj lokaciji u garaži (sprat-red-mesto) umesto prostog rednog broja — čak i ako se doda novo parking mesto, postojeća mesta zadržavaju svoje tačne, nepromenjene oznake.

4. Primer iz poslovnog IT okruženja

Administrator koji upravlja serverom sa dve mrežne kartice (jedna za internu mrežu, druga za DMZ, Modul 16) se oslanja na predvidljiva imena (ens33, ens34) da bi bio siguran da automatizovani skript uvek konfiguriše ispravnu karticu za ispravnu mrežu, bez rizika da redosled detekcije uređaja pri pokretanju sistema zameni njihove uloge.

5. Praktična vežba / napomena

Na Ubuntu Server VM iz laboratorijske vežbe ovog modula, pokrenite ip link show (Tema 2) i identifikujte tačno ime primarnog mrežnog interfejsa pre nastavka bilo koje konfiguracije.

6. Najčešće greške

  • Pisanje generičkog eth0 u konfiguracionim fajlovima na modernim distribucijama koje koriste predvidljivo imenovanje — komanda/konfiguracija neće raditi ako stvarno ime interfejsa nije eth0.
  • Pretpostavka da će ime interfejsa biti identično na svim VM-ovima/serverima — ime zavisi od virtuelnog hardvera i redosleda detekcije, pa ga treba proveriti na svakom sistemu pojedinačno.

7. Pitanje za proveru znanja

P: Zašto moderne Linux distribucije koriste predvidljiva imena interfejsa (npr. ens33) umesto starog eth0? O: Predvidljiva imena kodiraju fizičku lokaciju uređaja, obezbeđujući da isti fizički interfejs uvek dobije isto ime — sprečava zabunu koja bi nastala ako bi se redosled detekcije uređaja promenio (npr. nakon dodavanja nove mrežne kartice).

1. Jednostavno objašnjenje

ip addr prikazuje IP adrese dodeljene interfejsima, a ip link prikazuje i upravlja statusom (uključen/isključen) samih interfejsa — zajedno čine osnovni alat za pregled mrežne konfiguracije na modernom Linux sistemu.

2. Stručno objašnjenje

ip addr show (ili skraćeno ip a) prikazuje sve mrežne interfejse sa njihovim IP adresama, maskama (u CIDR notaciji, Modul 5), i statusom (UP/DOWN) — moderni ekvivalent starije, danas zastarele ifconfig komande. ip link show (ili ip l) prikazuje interfejse na Layer 2 nivou (MAC adresa, MTU, status), bez IP informacija. ip addr add <adresa>/<prefiks> dev <interfejs> ručno dodaje IP adresu interfejsu (privremeno, do restarta, ako se ne sačuva i u konfiguracionom fajlu poput Netplan-a, Tema 9); ip link set <interfejs> up/down administrativno uključuje/isključuje interfejs (ekvivalent Cisco no shutdown/shutdown, Modul 7).

3. Primer iz svakodnevnog života

ip link je kao provera da li je glavni prekidač za struju uključen (osnovni status uređaja). ip addr je kao provera koja je tačno adresa dodeljena tom uređaju — oba pitanja su odvojena, ali podjednako bitna za razumevanje da li nešto uopšte može da komunicira.

4. Primer iz poslovnog IT okruženja

Administrator koji dijagnostikuje zašto novi server ne odgovara na mreži prvo pokreće ip link show da proveri da li je interfejs uopšte u stanju UP (možda je fizički kabl neispravan ili je interfejs administrativno ugašen), pre nego što uopšte proveri da li ima ispravnu IP adresu preko ip addr show.

5. Praktična vežba / napomena

Na Ubuntu Server VM, pokrenite ip addr show i ip link show odvojeno, i uporedite koje informacije svaka komanda prikazuje — identifikujte status (UP/DOWN) i trenutnu IP adresu primarnog interfejsa.

6. Najčešće greške

  • Korišćenje zastarele ifconfig komande na modernim distribucijama gde možda uopšte nije instalirana po podrazumevanom ponašanju — ip komanda je danas standardni, preporučeni alat.
  • Zaboravljanje da ip addr add promena nije trajna — nestaje nakon restarta ako nije takođe sačuvana u Netplan konfiguraciji (Tema 9).

7. Pitanje za proveru znanja

P: Koja je razlika u informacijama koje prikazuju ip addr show i ip link show? O: ip addr show prikazuje IP adrese i maske dodeljene interfejsima (Layer 3); ip link show prikazuje status, MAC adresu i MTU interfejsa na Layer 2 nivou, bez IP informacija.

Tema 3 – ip route

1. Jednostavno objašnjenje

ip route prikazuje i menja routing tabelu Linux sistema — isti koncept kao routing tabela na ruteru (Modul 11) ili Windows route print (Modul 17), primenjen na Linux server.

2. Stručno objašnjenje

ip route show (ili ip r) prikazuje trenutnu routing tabelu — uključujući default rutu (default via <gateway>) i directly connected mreže. ip route add <mreža>/<prefiks> via <next-hop> dodaje statičku rutu (Modul 11 koncept primenjen na Linux); ip route del <mreža>/<prefiks> uklanja rutu. Kao i kod ip addr, promene napravljene direktno preko ip route komande su privremene (nestaju nakon restarta) osim ako nisu takođe definisane u trajnoj mrežnoj konfiguraciji (Netplan, Tema 9).

3. Primer iz svakodnevnog života

ip route je Linux ekvivalent ličnog plana puta iz Windows konteksta (Modul 17, route print) — prikazuje koju „glavnu kapiju" (gateway) uređaj koristi za izlazak ka mrežama koje nisu direktno povezane.

4. Primer iz poslovnog IT okruženja

Linux server sa dve mrežne kartice (jedna ka internoj mreži, druga ka DMZ segmentu, Modul 16) zahteva pažljivo definisane statičke rute preko ip route add (ili trajno preko Netplan-a) da bi znao kojim putem da šalje saobraćaj ka svakoj od te dve mreže, isto kao što bi ruter to zahtevao (Modul 11).

5. Praktična vežba / napomena

Na Ubuntu Server VM, pokrenite ip route show i identifikujte red koji predstavlja default rutu (default via ...) — uporedite format sa Cisco show ip route (Modul 11) i Windows route print (Modul 17) izlazima iz ranijih modula.

6. Najčešće greške

  • Očekivanje da ip route add komanda trajno menja konfiguraciju — bez odgovarajućeg unosa u Netplan (Tema 9), ruta nestaje nakon restarta sistema.
  • Zaboravljanje da dodata ruta zahteva postojeći, dostižan next-hop (isti princip kao kod Cisco statičkih ruta, Modul 11) — next-hop adresa mora biti u directly connected mreži.

7. Pitanje za proveru znanja

P: Zašto ruta dodata preko ip route add nestaje nakon restarta sistema, ako nije dodatno sačuvana negde drugde? O: ip route add menja samo trenutno aktivno stanje jezgra (kernel) u memoriji, ne trajni konfiguracioni fajl — bez odgovarajućeg unosa u Netplan konfiguraciji, sistem se pri sledećem pokretanju vraća na rute definisane u tom trajnom fajlu, gubeći privremeno dodatu rutu.

Tema 4 – ping, traceroute i tracepath

1. Jednostavno objašnjenje

Ovo su tri Linux alata za proveru dostupnosti i putanje — ping proverava da li je uređaj dostupan, traceroute i tracepath prikazuju putanju do njega, sa manjim razlikama u tome ko sme da ih pokreće i koje dodatne informacije prikazuju.

2. Stručno objašnjenje

ping <adresa> na Linux-u radi kontinuirano (za razliku od Windows-a koji šalje fiksan broj paketa, Modul 17) dok se ručno ne prekine sa Ctrl+C, osim ako se ne koristi -c <broj> prekidač za ograničen broj paketa. traceroute <adresa> (Linux/Unix ekvivalent Windows tracert-a) prikazuje svaki mrežni skok, ali podrazumevano koristi UDP pakete (ne ICMP kao Windows), što ponekad daje drugačije rezultate ako mrežni uređaji na putu drugačije tretiraju ta dva tipa saobraćaja; traceroute obično zahteva instalaciju (nije uvek podrazumevano prisutan) i, u nekim konfiguracijama, root privilegije. tracepath je jednostavnija alternativa koja ne zahteva root privilegije i podrazumevano je prisutna na većini distribucija — koristan izbor kada traceroute nije dostupan ili kada korisnik nema administratorska prava.

3. Primer iz svakodnevnog života

ping na Linux-u koji radi kontinuirano je kao neko ko stalno viče „čuješ li me?" dok mu ne kažete da prestane, za razliku od nekoga ko postavi to pitanje tačno pet puta i onda prestane sam od sebe (Windows podrazumevano ponašanje).

4. Primer iz poslovnog IT okruženja

Administrator koji nema root pristup na deljenom Linux serveru (ograničen nalog) koristi tracepath umesto traceroute za osnovnu dijagnostiku putanje, jer tracepath ne zahteva povišene privilegije, dok bi traceroute u nekim konfiguracijama mogao da odbije pokretanje bez njih.

5. Praktična vežba / napomena

Na Ubuntu Server VM, pokrenite ping -c 4 <adresa-gateway-a> (sa -c 4 da se ograniči na 4 paketa, izbegavajući kontinuirano izvršavanje), zatim tracepath <spoljna-adresa> ako VM ima internet pristup.

6. Najčešće greške

  • Pokretanje ping bez -c prekidača i zaboravljanje da se prekine (Ctrl+C) — na Linux-u, ping bez ograničenja radi neograničeno, za razliku od Windows podrazumevanog ponašanja od 4 paketa.
  • Pretpostavka da je traceroute uvek podrazumevano instaliran — na minimalnim Ubuntu Server instalacijama, često se mora ručno instalirati (sudo apt install traceroute), za razliku od ping i tracepath koji su gotovo uvek prisutni.

7. Pitanje za proveru znanja

P: Po čemu se tracepath razlikuje od traceroute u pogledu ko sme da ga pokrene? O: tracepath ne zahteva root/administratorske privilegije i podrazumevano je prisutan na većini distribucija, dok traceroute u nekim konfiguracijama zahteva povišene privilegije i često mora biti posebno instaliran.

Tema 5 – ss i netstat

1. Jednostavno objašnjenje

ss i netstat prikazuju aktivne mrežne konekcije i portove na kojima sistem „sluša" — ss je moderniji, brži alat koji postepeno zamenjuje stariji netstat, slično kao PowerShell cmdlet-i naspram starih Windows CLI komandi (Modul 17).

2. Stručno objašnjenje

netstat -tulpn (starija, ali i dalje često korišćena komanda) prikazuje TCP/UDP (-tu) portove na kojima se „sluša" (-l), sa procesima (-p) i numeričkim (-n) prikazom adresa. ss -tulpn je moderniji ekvivalent sa identičnim prekidačima i sličnim izlazom, ali implementiran efikasnije (čita direktno iz kernel strukture podataka, brže na sistemima sa mnogo konekcija) — ss je danas preporučeni izbor na modernim distribucijama, dok netstat može zahtevati dodatnu instalaciju paketa (net-tools) na minimalnim Ubuntu Server instalacijama.

3. Primer iz svakodnevnog života

ss/netstat su kao spisak svih trenutno otvorenih „prozora i vrata" zgrade (portova) i ko trenutno kroz njih ulazi/izlazi (konekcije/procesi) — ss je moderniji, brži sistem za taj uvid u odnosu na stariji netstat.

4. Primer iz poslovnog IT okruženja

Administrator koji proverava da li je veb server ispravno pokrenut i sluša na portu 80/443 koristi ss -tulpn | grep :80 da brzo potvrdi da proces zaista „sluša" na tom portu, umesto da čeka na spor odgovor browser-a koji ne otkriva zašto konekcija ne uspeva.

5. Praktična vežba / napomena

Na Ubuntu Server VM, nakon što instalirate SSH server (Tema 11), pokrenite ss -tulpn | grep :22 da potvrdite da SSH servis zaista sluša na očekivanom portu pre nego što pokušate konekciju sa drugog uređaja.

6. Najčešće greške

  • Korišćenje netstat na minimalnoj Ubuntu Server instalaciji bez prethodne instalacije net-tools paketa — komanda jednostavno neće postojati („command not found").
  • Zaboravljanje -n prekidača kada je brzina bitna — bez njega, i ss i netstat pokušavaju DNS rezoluciju za svaku adresu, usporavajući izlaz (isti princip kao Windows netstat, Modul 17).

7. Pitanje za proveru znanja

P: Zašto je ss danas preporučeniji izbor od netstat na modernim Linux distribucijama? O: ss čita direktno iz kernel struktura podataka, radeći efikasnije (posebno na sistemima sa mnogo konekcija), i podrazumevano je prisutan na modernim distribucijama, dok netstat može zahtevati dodatnu instalaciju paketa.

Tema 6 – dig i nslookup

1. Jednostavno objašnjenje

dig i nslookup postavljaju DNS upite na Linux-u — nslookup postoji i na Windows-u (Modul 17) sa istom osnovnom svrhom, dok je dig Linux/Unix specifičan alat koji pruža mnogo detaljniji, tehnički izlaz.

2. Stručno objašnjenje

nslookup <ime> radi identično kao Windows verzija (Modul 17) — jednostavan upit i odgovor. dig <ime> je moćniji, Linux/Unix-specifičan alat koji prikazuje kompletan DNS odgovor uključujući sve delove DNS zaglavlja (query section, answer section, authority section, additional section), TTL vrednosti svakog zapisa, i vreme trajanja upita (query time) — mnogo koristan za dublju DNS dijagnostiku od nslookup-a. dig <ime> MX (ili bilo koji drugi tip zapisa, Modul 13) traži konkretan tip DNS zapisa; dig +short <ime> prikazuje samo sažet, minimalan odgovor (koristan u skriptovanju); dig @<dns-server> <ime> postavlja upit direktno određenom DNS serveru, zaobilazeći podrazumevani.

3. Primer iz svakodnevnog života

nslookup je kao kratko pitanje „koji je broj telefona ove osobe" sa kratkim odgovorom. dig je kao dobijanje kompletnog izvoda iz imenika sa svim dodatnim podacima (koliko dugo je taj broj važeći, ko je odgovorio na pitanje, koliko je pitanje trajalo) — mnogo detaljnije za onoga kome je ta dubina informacija potrebna.

4. Primer iz poslovnog IT okruženja

Administrator koji dijagnostikuje spore DNS odgovore koristi dig <ime> da vidi tačno „Query time" polje u izlazu, kvantifikujući koliko dugo DNS rezolucija zaista traje — informacija koju nslookup ne prikazuje tako direktno i precizno.

5. Praktična vežba / napomena

Na Ubuntu Server VM, pokrenite dig google.com i pronađite „ANSWER SECTION" i „Query time" polja u izlazu; zatim uporedite sa dig +short google.com da vidite razliku u obimu prikazanih informacija.

6. Najčešće greške

  • Korišćenje dig bez instaliranog dnsutils paketa na minimalnim Ubuntu instalacijama — slično traceroute-u (Tema 4), možda zahteva ručnu instalaciju.
  • Zanemarivanje TTL vrednosti u dig izlazu prilikom dijagnostike „zastarelih" DNS odgovora — visok TTL znači da će se stari, keširan odgovor koristiti duže vreme čak i nakon što je stvarni DNS zapis promenjen na serveru.

7. Pitanje za proveru znanja

P: Koju dodatnu informaciju dig tipično prikazuje, a koju nslookup ne prikazuje na isti direktan način? O: dig prikazuje kompletne delove DNS odgovora (TTL vrednosti, query time, authority/additional sekcije), pružajući mnogo detaljniju tehničku sliku DNS transakcije od jednostavnijeg nslookup odgovora.

Tema 7 – hostnamectl i /etc/resolv.conf

1. Jednostavno objašnjenje

hostnamectl upravlja imenom Linux računara (ekvivalent Windows hostname promene, Modul 7/17), a /etc/resolv.conf je fajl koji sadrži koje DNS servere sistem koristi.

2. Stručno objašnjenje

hostnamectl bez argumenata prikazuje trenutno ime hosta i osnovne informacije o sistemu (OS, kernel verzija); hostnamectl set-hostname <ime> trajno menja ime hosta sistema. /etc/resolv.conf je konfiguracioni fajl koji sadrži nameserver <adresa> unose — DNS servere koje sistem koristi za rezoluciju (Modul 13 koncept, Linux implementacija). Na modernim Ubuntu sistemima, ovaj fajl se automatski generiše od strane systemd-resolved servisa na osnovu Netplan konfiguracije (Tema 9) — ručno editovanje /etc/resolv.conf direktno se često prepisuje pri sledećem restartu ili osvežavanju mrežne konfiguracije, pa je ispravan pristup izmena kroz Netplan, ne direktno kroz taj fajl.

3. Primer iz svakodnevnog života

hostnamectl je kao promena imena na vratima vaše kancelarije. /etc/resolv.conf je kao lični imenik telefonskih brojeva koje koristite kada trebate nekog da pozovete po imenu — ali na modernim sistemima taj imenik se automatski ažurira iz centralnog izvora (Netplan), pa ručno pisanje u njega liči na pisanje direktno u nečiju automatski generisanu tabelu koja će biti prepisana.

4. Primer iz poslovnog IT okruženja

Novi administrator, naviknut na starije Linux sisteme, pokušava da ručno izmeni /etc/resolv.conf na modernom Ubuntu Server-u da promeni DNS server — nakon restarta mrežnog servisa, izmena nestaje jer je systemd-resolved automatski regenerisao fajl na osnovu Netplan konfiguracije, koja i dalje sadrži stari DNS server; ispravan pristup bi bio izmena direktno u Netplan YAML fajlu (Tema 9).

5. Praktična vežba / napomena

Na Ubuntu Server VM, pokrenite hostnamectl da vidite trenutne informacije o sistemu, i pregledajte sadržaj /etc/resolv.conf (cat /etc/resolv.conf) da identifikujete trenutno konfigurisane DNS servere.

6. Najčešće greške

  • Direktno editovanje /etc/resolv.conf na modernim Ubuntu sistemima očekujući trajnu promenu — izmena se često prepisuje pri sledećem osvežavanju mrežne konfiguracije od strane systemd-resolved.
  • Zaboravljanje da hostnamectl set-hostname menja samo ime hosta, ne i unose u /etc/hosts fajlu koji možda referenciraju staro ime — oba mesta ponekad treba ažurirati zajedno za potpunu konzistentnost.

7. Pitanje za proveru znanja

P: Zašto direktno ručno editovanje /etc/resolv.conf na modernom Ubuntu Server-u često nije trajno rešenje? O: Na modernim Ubuntu sistemima, /etc/resolv.conf se automatski generiše od strane systemd-resolved servisa na osnovu Netplan konfiguracije — ručne izmene se često prepisuju pri sledećem restartu ili osvežavanju mrežne konfiguracije, pa trajnu izmenu treba napraviti u samom Netplan YAML fajlu.

Tema 8 – NetworkManager i nmcli

1. Jednostavno objašnjenje

NetworkManager je servis koji upravlja mrežnim vezama na mnogim Linux distribucijama (posebno desktop verzijama), a nmcli je komandnolinijski alat za upravljanje tim istim vezama bez potrebe za grafičkim interfejsom.

2. Stručno objašnjenje

NetworkManager je servis koji dinamički upravlja mrežnim konekcijama (žičnim, bežičnim, VPN), popularan posebno na desktop distribucijama i nekim serverskim konfiguracijama, nudeći dinamičniji pristup upravljanju mrežom od statičkih konfiguracionih fajlova. nmcli (Network Manager Command Line Interface) omogućava potpuno upravljanje NetworkManager-om preko terminala — nmcli device status prikazuje status svih uređaja; nmcli connection show prikazuje definisane mrežne veze; nmcli connection modify <ime> ipv4.addresses <adresa>/<prefiks> ipv4.method manual konfiguriše statičku adresu. Važna napomena za Ubuntu Server kontekst ovog modula: Ubuntu Server po podrazumevanom ponašanju koristi Netplan (Tema 9), ne NetworkManager, za razliku od Ubuntu Desktop-a — oba mogu koegzistirati, ali je bitno znati koji sistem trenutno upravlja mrežom na datom serveru da bi se izbegli konfliktni pokušaji konfiguracije sa dva različita alata.

3. Primer iz svakodnevnog života

NetworkManager je kao lični asistent koji dinamički upravlja vašim rasporedom sastanaka (mrežnim vezama), dodajući/uklanjajući ih po potrebi. nmcli je kao mogućnost da tom asistentu date instrukcije preko poruke (terminal) umesto da uvek koristite lični razgovor (grafički interfejs).

4. Primer iz poslovnog IT okruženja

Administrator koji upravlja desktop Linux radnim stanicama u kancelariji (za razliku od servera) često koristi nmcli za skriptovano, automatizovano podešavanje Wi-Fi profila (Modul 14 koncepti primenjeni na Linux) na desetinama mašina odjednom, umesto da ručno prolazi kroz grafički interfejs na svakoj.

5. Praktična vežba / napomena

Na Ubuntu Server VM (koja po pravilu koristi Netplan, ne NetworkManager), proverite koji servis upravlja mrežom pomoću systemctl status NetworkManager i systemctl status systemd-networkd — na standardnoj Ubuntu Server instalaciji, očekujte da NetworkManager nije aktivan.

6. Najčešće greške

  • Pokušaj korišćenja nmcli na Ubuntu Server instalaciji koja koristi Netplan/systemd-networkd bez NetworkManager-a — komande mogu vratiti grešku ili ne imati efekta ako NetworkManager servis uopšte nije pokrenut.
  • Mešanje dva sistema upravljanja mrežom (NetworkManager i Netplan bez NetworkManager renderera) istovremeno na istom serveru — može dovesti do konfliktne, nepredvidive konfiguracije.

7. Pitanje za proveru znanja

P: Koji sistem za upravljanje mrežom Ubuntu Server po podrazumevanom ponašanju koristi, za razliku od Ubuntu Desktop-a? O: Ubuntu Server po podrazumevanom ponašanju koristi Netplan (sa systemd-networkd rendererom), ne NetworkManager, koji je uobičajeniji na Ubuntu Desktop-u.

Tema 9 – Netplan i statička IP konfiguracija

1. Jednostavno objašnjenje

Netplan je moderan način da se mrežna konfiguracija na Ubuntu-u opiše u jednostavnom, čitljivom YAML fajlu, umesto starijih, manje strukturiranih konfiguracionih fajlova.

2. Stručno objašnjenje

Netplan je deklarativan sistem konfiguracije mreže (YAML fajlovi u /etc/netplan/) uveden na Ubuntu-u kao zamena za starije /etc/network/interfaces pristup. Osnovna struktura definiše interfejs, i da li koristi DHCP (dhcp4: true) ili statičku adresu (addresses: [192.168.1.10/24], routes za gateway, nameservers za DNS servere). Nakon izmene YAML fajla, promene se primenjuju komandom sudo netplan apply (ili testiraju bezbedno sa sudo netplan try, koja automatski vraća staru konfiguraciju ako nova ne bude potvrđena u kratkom vremenskom roku — korisna zaštita od greške koja bi vas „zaključala" van udaljene SSH sesije).

3. Primer iz svakodnevnog života

Netplan je kao pisani, precizno strukturiran ugovor o mrežnim uslovima (statička adresa, gateway, DNS) koji se čita i primenjuje odjednom, umesto usmenih, razbacanih dogovora na više različitih mesta (stariji, manje strukturiran pristup).

4. Primer iz poslovnog IT okruženja

Administrator koji konfiguriše statičku IP adresu na Ubuntu Server-u putem SSH veze koristi sudo netplan try umesto direktnog apply — ako nova konfiguracija sadrži grešku koja bi prekinula mrežnu vezu (npr. pogrešan gateway), netplan try automatski vraća prethodnu, funkcionalnu konfiguraciju nakon isteka kratkog tajmera, sprečavajući da administrator ostane zaključan van servera bez fizičkog pristupa.

5. Praktična vežba / napomena

U laboratorijskoj vežbi ovog modula, kreiraćete/izmeniti Netplan YAML fajl da postavite statičku IP adresu na Ubuntu Server VM, koristeći netplan try pre konačnog apply-ja.

6. Najčešće greške

  • Greška u YAML sintaksi (npr. nekonzistentno uvlačenje, YAML je strogo osetljiv na razmake) — čest uzrok da netplan apply odbije konfiguraciju ili je pogrešno protumači.
  • Korišćenje netplan apply direktno (bez try) preko udaljene SSH sesije kada je konfiguracija netestirana — greška u konfiguraciji može odmah prekinuti SSH vezu, zahtevajući fizički/konzolni pristup VM-u za ispravku.

7. Pitanje za proveru znanja

P: Zašto je netplan try bezbednija opcija od netplan apply kada se mrežna konfiguracija menja preko udaljene SSH veze? O: netplan try automatski vraća prethodnu, funkcionalnu konfiguraciju ako nova konfiguracija ne bude eksplicitno potvrđena u kratkom vremenskom roku — sprečava da administrator ostane trajno zaključan van servera ako nova konfiguracija sadrži grešku koja prekida mrežnu vezu.

Tema 10 – SSH server na Linux-u

1. Jednostavno objašnjenje

SSH server (obično openssh-server) omogućava bezbedan, enkriptovan udaljeni pristup Linux sistemu — isti koncept obrađen za Cisco uređaje (Modul 7) i Windows (Modul 17), sada primenjen na Linux server koji često nema grafički interfejs uopšte, čineći SSH jedinim praktičnim načinom administracije.

2. Stručno objašnjenje

SSH server se instalira paketom openssh-server (sudo apt install openssh-server), sa konfiguracijom u /etc/ssh/sshd_config — ključna podešavanja uključuju Port (podrazumevano 22, može se promeniti radi smanjenja automatizovanih napada, iako to nije zamena za pravu bezbednost), PermitRootLogin (preporučeno no, iz istog razloga kao izbegavanje deljenih administratorskih naloga, Modul 16), i PasswordAuthentication (preporučeno no u produkciji, u korist autentifikacije preko ključeva — asimetričan par ključeva, gde se javni ključ postavlja na server u ~/.ssh/authorized_keys, a privatni ključ ostaje bezbedno čuvan kod korisnika, eliminišući rizik od pogađanja/brute-force napada na lozinku). Nakon izmene konfiguracije, servis se ponovo pokreće sa sudo systemctl restart sshd.

3. Primer iz svakodnevnog života

SSH autentifikacija preko lozinke je kao ključ koji se može iskopirati ili pogoditi. Autentifikacija preko ključeva je kao jedinstven, kriptografski „otisak prsta" koji je praktično nemoguće falsifikovati ili pogoditi napadom pokušaja i greške.

4. Primer iz poslovnog IT okruženja

DevOps tim koji upravlja desetinama Linux servera u cloud okruženju potpuno onemogućava PasswordAuthentication na svim serverima, zahtevajući isključivo autentifikaciju preko SSH ključeva — svaki novi server automatski dobija javne ključeve ovlašćenih administratora pri kreiranju (automatizovano), eliminišući rizik od brute-force napada na lozinke koji su čest cilj automatizovanih skenera na internetu.

5. Praktična vežba / napomena

U laboratorijskoj vežbi ovog modula, generisaćete SSH par ključeva na svom host računaru, postaviti javni ključ na Ubuntu Server VM, i konfigurisati PasswordAuthentication no da bi se pristup vršio isključivo preko ključa.

6. Najčešće greške

  • Onemogućavanje PasswordAuthentication pre nego što je javni ključ ispravno postavljen i testiran — može potpuno onemogućiti bilo kakav SSH pristup ako ključ ne radi ispravno.
  • Ostavljanje PermitRootLogin yes u produkcionom okruženju — omogućava direktne brute-force pokušaje protiv root naloga, koji uvek postoji i ima puna prava, za razliku od običnog korisničkog naloga koji bi prvo trebalo pogoditi ime.

7. Pitanje za proveru znanja

P: Zašto se autentifikacija preko SSH ključeva smatra bezbednijom od autentifikacije preko lozinke? O: Autentifikacija preko ključeva koristi kriptografski par ključeva koji je praktično nemoguće pogoditi brute-force napadom (za razliku od lozinke), a privatni ključ nikada ne napušta korisnikov uređaj tokom procesa autentifikacije.

Tema 11 – SCP i SFTP

1. Jednostavno objašnjenje

SCP i SFTP su dva načina da se fajlovi bezbedno prenesu preko postojeće SSH veze, isti koncept kao Windows SMB (Modul 17), ali preko potpuno drugačijeg, SSH-baziranog mehanizma.

2. Stručno objašnjenje

SCP (Secure Copy Protocol) je jednostavan alat za kopiranje fajlova preko SSH konekcije, sintaksa scp <lokalni-fajl> <korisnik>@<server>:<putanja> (upload) ili scp <korisnik>@<server>:<putanja> <lokalna-putanja> (download) — direktan, jednostavan, ali ograničen (ne podržava interaktivnu navigaciju, samo direktno kopiranje). SFTP (SSH File Transfer Protocol), već pomenut u Modulu 15 kao VPN alternativa, ovde se koristi u svojoj primarnoj nameni — interaktivni alat za prenos fajlova preko SSH-a sa mogućnošću navigacije kroz direktorijume (ls, cd, get, put komande unutar SFTP sesije), sličnije tradicionalnom FTP klijentu, ali potpuno enkriptovano preko SSH-a. Oba alata koriste isti SSH server i autentifikaciju (Tema 10) kao i obična SSH terminal sesija — nema potrebe za posebnim, dodatnim servisom.

3. Primer iz svakodnevnog života

SCP je kao brzo, direktno slanje jednog paketa poznatom primaocu bez zadržavanja. SFTP je kao poseta skladištu gde možete da prošetate kroz police (direktorijume), pregledate šta je tu, i uzmete/ostavite tačno ono što vam treba — oba se dešavaju kroz istu, bezbednu, prethodno uspostavljenu vezu (SSH).

4. Primer iz poslovnog IT okruženja

Administrator koji automatizuje noćni backup skript koristi scp u samom skriptu (jednostavna, direktna komanda pogodna za automatizaciju) da prenese backup fajl na udaljeni server, dok bi za ručno istraživanje strukture direktorijuma na udaljenom serveru pre odlučivanja šta tačno preuzeti, radije koristio interaktivnu SFTP sesiju.

5. Praktična vežba / napomena

U laboratorijskoj vežbi ovog modula, koristićete scp da prenesete test fajl sa svog host računara na Ubuntu Server VM preko već konfigurisane SSH veze sa ključem (Tema 10).

6. Najčešće greške

  • Mešanje SFTP-a (preko SSH-a, port 22, potpuno enkriptovano) sa FTPS (FTP preko TLS-a, drugačiji mehanizam i port) — imena zvuče slično, ali su tehnički različiti protokoli.
  • Zaboravljanje da SCP/SFTP zahtevaju iste SSH kredencijale (lozinka ili ključ, Tema 10) kao obična terminal sesija — ako je PasswordAuthentication onemogućen za SSH, isto važi i za SCP/SFTP pristup istom serveru.

7. Pitanje za proveru znanja

P: Zašto SCP i SFTP ne zahtevaju poseban, dodatni servis odvojen od SSH-a? O: Oba protokola rade preko već postojeće SSH konekcije i koriste identičnu SSH autentifikaciju i enkripciju — nema potrebe za zasebnim serverom ili portom, jer se prenos fajlova odvija kroz isti kanal kao i obična SSH terminal sesija.

Tema 12 – UFW (Uncomplicated Firewall)

1. Jednostavno objašnjenje

UFW je jednostavan firewall alat na Ubuntu-u koji čini konfigurisanje osnovnih firewall pravila mnogo lakšim od direktnog rada sa složenijim, moćnijim alatima ispod haube.

2. Stručno objašnjenje

UFW (Uncomplicated Firewall) je pojednostavljen interfejs za konfigurisanje Linux firewall pravila (koja u pozadini implementira iptables ili moderniji nftables, Tema 13), dizajniran za jednostavnu, čitljivu sintaksu. Osnovne komande: sudo ufw enable/disable (uključuje/isključuje firewall); sudo ufw allow <port> (npr. sudo ufw allow 22 za SSH, ili sudo ufw allow ssh koristeći imenovan servis); sudo ufw deny <port>; sudo ufw allow from <adresa> (dozvoljava sav saobraćaj sa konkretne izvorišne adrese, princip najmanjih privilegija, Modul 16); sudo ufw status verbose (prikazuje trenutna pravila). UFW pravila se obrađuju sličnim redosledom kao Cisco ACL (Modul 16) — specifičnija pravila treba postaviti pažljivo u odnosu na opštija.

3. Primer iz svakodnevnog života

UFW je kao jednostavan, unapred pripremljen obrazac za postavljanje pravila obezbeđenja zgrade („dozvoli poštara na glavnim vratima, zabrani sve ostale strance") — mnogo lakše popuniti nego pisati kompletan pravni ugovor o bezbednosti od nule (direktan iptables/nftables).

4. Primer iz poslovnog IT okruženja

Administrator koji postavlja nov Ubuntu Server odmah nakon instalacije SSH servera (Tema 10) konfiguriše sudo ufw allow OpenSSH i sudo ufw enable — dozvoljavajući isključivo SSH saobraćaj, dok je sve ostalo podrazumevano odbijeno, primenjujući princip najmanjih privilegija (Modul 16) od samog početka rada servera.

5. Praktična vežba / napomena

U laboratorijskoj vežbi ovog modula, konfigurisaćete UFW da dozvoli isključivo SSH saobraćaj, zatim proveriti sudo ufw status verbose da potvrdite ispravna pravila pre nego što uključite firewall.

6. Najčešće greške

  • Uključivanje UFW (ufw enable) preko udaljene SSH sesije pre nego što je SSH port eksplicitno dozvoljen — ovo trenutno prekida sopstvenu SSH sesiju administratora, zahtevajući fizički/konzolni pristup za ispravku.
  • Zaboravljanje da UFW podrazumevano odbija sav dolazni saobraćaj koji nije eksplicitno dozvoljen — nakon uključivanja, bilo koji servis koji nije eksplicitno dozvoljen postaje nedostupan spolja, čak i ako je ranije radio bez firewall-a.

7. Pitanje za proveru znanja

P: Zašto je kritično dozvoliti SSH port pre uključivanja UFW-a na serveru kome se pristupa preko udaljene SSH veze? O: UFW podrazumevano odbija sav dolazni saobraćaj koji nije eksplicitno dozvoljen — ako SSH port nije prethodno dozvoljen, uključivanje firewall-a odmah prekida trenutnu SSH sesiju administratora, potencijalno zahtevajući fizički pristup serveru za ispravku.

Tema 13 – nftables (koncept)

1. Jednostavno objašnjenje

nftables je moderniji, moćniji Linux firewall framework koji postepeno zamenjuje stariji iptables, koristeći jedinstveniji i efikasniji pristup filtriranju saobraćaja.

2. Stručno objašnjenje

nftables je naslednik iptables-a (starijeg Linux firewall frameworka), integrisan u Linux jezgro od verzije 3.13 nadalje, dizajniran da zameni odvojene alate (iptables za IPv4, ip6tables za IPv6, arptables, ebtables) jednim jedinstvenim frameworkom sa konzistentnom sintaksom za sve protokole. Koristi koncept tabela (tables) i lanaca (chains) pravila, sličan iptables-u, ali sa efikasnijom internom implementacijom (jedinstvena virtuelna mašina u jezgru koja obrađuje pravila, umesto sekvencijalne obrade kroz više odvojenih modula). UFW (Tema 12) na modernim Ubuntu verzijama zapravo generiše nftables pravila u pozadini — administrator retko piše sirova nftables pravila ručno osim u naprednim, prilagođenim scenarijima koji prevazilaze mogućnosti UFW-a.

3. Primer iz svakodnevnog života

Prelazak sa iptables-a na nftables je kao prelazak sa nekoliko odvojenih, nekonzistentnih obrazaca za različite vrste zahteva (po jedan obrazac za svaki tip dokumenta) na jedan jedinstven, moderniji sistem koji obrađuje sve tipove zahteva efikasnije i konzistentnije.

4. Primer iz poslovnog IT okruženja

Napredni bezbednosni tim koji treba vrlo specifično, prilagođeno filtriranje saobraćaja (van onoga što UFW jednostavna sintaksa podržava) piše sirova nftables pravila direktno, dok običan administrator za tipičan server nastavlja da koristi UFW kao jednostavniji interfejs koji ionako generiše nftables pravila ispod haube.

5. Praktična vežba / napomena

Ovaj modul se fokusira na koncept; za samostalno istraživanje, na Ubuntu Server VM pokrenite sudo nft list ruleset (ako je nftables backend aktivan) da vidite sirova pravila koja je UFW automatski generisao iz vaše konfiguracije iz Teme 12.

6. Najčešće greške

  • Pokušaj da se istovremeno ručno pišu i iptables i nftables pravila na istom sistemu bez razumevanja koji je zapravo aktivan backend — može dovesti do konfliktne, teško dijagnostikovane konfiguracije.
  • Pretpostavka da je potrebno naučiti sirovu nftables sintaksu za osnovnu upotrebu — za većinu potreba, UFW (Tema 12) pruža dovoljno jednostavan interfejs bez potrebe za direktnim pisanjem nftables pravila.

7. Pitanje za proveru znanja

P: Šta nftables čini konceptualno drugačijim (i efikasnijim) u odnosu na stariji iptables? O: nftables zamenjuje nekoliko odvojenih alata (iptables, ip6tables, arptables, ebtables) jednim jedinstvenim frameworkom sa konzistentnom sintaksom za sve protokole, koristeći efikasniju internu implementaciju u Linux jezgru.

Tema 14 – Provera DNS-a i otvorenih portova

1. Jednostavno objašnjenje

Kombinacija alata iz prethodnih tema (dig/nslookup za DNS, ss/netstat za portove) čini standardni „brzi pregled zdravlja" mrežnih servisa na Linux serveru.

2. Stručno objašnjenje

Sistematska provera funkcionalnosti servisa na Linux serveru kombinuje: DNS proveru (dig <ime> ili nslookup <ime>, Tema 6) — da li se ime servera/servisa ispravno razrešava; proveru otvorenih portova lokalno (ss -tulpn, Tema 5) — da li servis zaista „sluša" na očekivanom portu na samom serveru; i proveru dostupnosti porta spolja (sa drugog uređaja, npr. nc -zv <adresa> <port> — netcat u „zero-I/O" režimu, ili PowerShell Test-NetConnection sa Windows klijenta, Modul 17) — da li je taj port zaista dostupan preko mreže, ne samo lokalno na serveru. Razlika između druge i treće provere je ključna: servis može „slušati" lokalno (ss pokazuje port kao otvoren), ali biti nedostupan spolja zbog firewall pravila (UFW, Tema 12) koja blokiraju dolazni saobraćaj ka tom portu.

3. Primer iz svakodnevnog života

Provera da servis „sluša" lokalno je kao provera da je neko fizički prisutan iza vrata kancelarije spreman da odgovori. Provera dostupnosti spolja je kao provera da li ta ista vrata uopšte imaju bravu koja dozvoljava nekome spolja da uđe — osoba unutra može biti savršeno spremna da odgovori, ali zaključana vrata (firewall) i dalje sprečavaju spoljni pristup.

4. Primer iz poslovnog IT okruženja

Korisnik prijavljuje da ne može da pristupi veb aplikaciji na serveru — administrator prvo proverava ss -tulpn | grep :80 na samom serveru i potvrđuje da aplikacija zaista sluša na portu 80, zatim sa drugog računara pokušava nc -zv <adresa-servera> 80 i otkriva da konekcija ne uspeva — ukazujući da problem nije u samoj aplikaciji, već u UFW pravilu (Tema 12) koje blokira dolazni saobraćaj na tom portu spolja.

5. Praktična vežba / napomena

U laboratorijskoj vežbi ovog modula, nakon konfigurisanja UFW pravila (Tema 12), proverite i lokalno (ss -tulpn na samom Ubuntu Server VM) i spolja (sa host računara ili druge VM) da li je SSH port zaista dostupan u oba smisla.

6. Najčešće greške

  • Zaustavljanje dijagnostike nakon što ss/netstat potvrdi da servis lokalno sluša, bez provere dostupnosti spolja — propušta scenarije gde je problem u firewall-u (lokalnom UFW-u ili mrežnom uređaju na putu), ne u samoj aplikaciji.
  • Zaboravljanje da provera dostupnosti spolja mora doći sa drugog uređaja, ne sa samog servera — testiranje porta sa istog servera na kome servis radi ne otkriva probleme sa firewall pravilima koja utiču isključivo na dolazni saobraćaj sa mreže.

7. Pitanje za proveru znanja

P: Zašto servis koji „sluša" lokalno (potvrđeno preko ss) i dalje može biti nedostupan korisnicima na mreži? O: Firewall pravila (npr. UFW) mogu blokirati dolazni saobraćaj ka tom portu sa mreže, čak i kada aplikacija sama ispravno radi i „sluša" na tom portu lokalno na serveru — lokalna provera i provera dostupnosti spolja testiraju dva različita sloja problema.

Tema 15 – Osnovno logovanje (journalctl)

1. Jednostavno objašnjenje

journalctl je alat za pregled sistemskih log zapisa na modernim Linux distribucijama, uključujući mrežne servise poput SSH-a — koristan kada nešto ne radi i potrebno je videti šta se zaista dešava „iznutra".

2. Stručno objašnjenje

journalctl čita centralizovani binarni log koji održava systemd-journald servis, zamenjujući (ili dopunjujući) tradicionalne tekstualne log fajlove u /var/log/. Korisni prekidači: journalctl -u <servis> (npr. journalctl -u sshd) prikazuje log zapise konkretnog servisa; journalctl -f prati log u realnom vremenu (slično tail -f); journalctl --since "1 hour ago" filtrira po vremenskom periodu; journalctl -p err prikazuje samo zapise nivoa „error" ili ozbiljnijeg (koncept sličan Syslog severity nivoima, Modul 13). Za mrežnu dijagnostiku, journalctl -u sshd je posebno koristan za identifikovanje neuspešnih pokušaja prijave ili grešaka u SSH konfiguraciji (Tema 10) odmah nakon izmene sshd_config fajla.

3. Primer iz svakodnevnog života

journalctl je kao centralna knjiga događaja zgrade u koju se automatski beleži svaki dolazak, odlazak i incident na jednom mestu, umesto da svaki sprat (servis) vodi sopstvenu, odvojenu, ručno pisanu evidenciju.

4. Primer iz poslovnog IT okruženja

Nakon izmene SSH konfiguracije (Tema 10) da onemogući PasswordAuthentication, administrator pokreće journalctl -u sshd -f u jednom terminalu dok u drugom terminalu (ili sa drugog uređaja) testira novu konekciju preko ključa — u realnom vremenu vidi tačno da li SSH servis prihvata ili odbija pokušaj, i, ako odbija, tačan razlog naveden u log zapisu.

5. Praktična vežba / napomena

U laboratorijskoj vežbi ovog modula, nakon svake značajnije izmene (SSH konfiguracija, UFW pravila), proverite journalctl -u sshd -n 20 (poslednjih 20 zapisa) da potvrdite da nije došlo do neočekivane greške pre nego što pređete na sledeći korak.

6. Najčešće greške

  • Zanemarivanje log zapisa i oslanjanje isključivo na simptome („ne radi") bez provere zašto — journalctl često direktno navodi tačan uzrok greške (npr. sintaksna greška u konfiguracionom fajlu, odbijena autentifikacija) koji bi inače zahtevao nagađanje.
  • Pretraživanje log-a bez filtriranja po servisu (-u) na sistemu sa mnogo aktivnih servisa — rezultuje ogromnom količinom nebitnih zapisa koje je teško pregledati.

7. Pitanje za proveru znanja

P: Koju komandu biste koristili da pratite SSH log zapise u realnom vremenu dok testirate novu konfiguraciju sa drugog uređaja? O: journalctl -u sshd -f — prikazuje log zapise konkretno SSH servisa i prati ih u realnom vremenu (novi zapisi se odmah prikazuju kako pristižu).

Tema 16 – Sistematska dijagnostika Linux mrežnih problema

1. Jednostavno objašnjenje

Kao i kod Windows-a (Modul 17), dijagnostika Linux mrežnih problema prati jasan redosled — od osnovnog statusa interfejsa, preko lokalne/DNS povezanosti, do konkretnog servisa i firewall provere.

2. Stručno objašnjenje

Sistematski redosled dijagnostike Linux mrežnih problema: (1) ip link show (Tema 2) — proveriti da je interfejs u stanju UP; (2) ip addr show — proveriti da interfejs ima očekivanu IP adresu i masku; (3) ip route show (Tema 3) — proveriti da postoji ispravna default ruta; (4) ping <gateway> zatim ping <spoljna adresa> (Tema 4) — izolovati da li je problem lokalni ili udaljeniji; (5) dig/nslookup <ime> (Tema 6) — proveriti DNS rezoluciju odvojeno od IP povezanosti; (6) ss -tulpn (Tema 5) na samom serveru — proveriti da li konkretan servis sluša na očekivanom portu; (7) provera dostupnosti porta spolja sa drugog uređaja (Tema 14) — izolovati da li je problem u samoj aplikaciji ili u firewall pravilima (UFW, Tema 12); (8) journalctl -u <servis> (Tema 15) — pregledati konkretne log zapise za tačan uzrok greške ako prethodni koraci nisu dali jasan odgovor. Ovaj redosled je gotovo identičan Windows dijagnostičkom redosledu iz Modula 17, samo sa Linux-specifičnim alatima na svakom koraku.

3. Primer iz svakodnevnog života

Redosled dijagnostike je identičan principu iz prethodnog modula (Windows) — prvo proverite da li je uređaj uopšte „upaljen" i ima ispravnu adresu, zatim da li zna put ka izlazu, zatim da li zna imena, i tek na kraju da li konkretna „osoba" (servis) unutra odgovara i da li su „vrata" (firewall) uopšte otvorena za posetioce spolja.

4. Primer iz poslovnog IT okruženja

Tim koji administrira flotu Linux servera u cloud okruženju standardizuje ovaj tačan redosled kao deo internog troubleshooting runbook-a — svaki novi član tima uči da prati iste korake (interfejs → IP → ruta → povezanost → DNS → lokalni port → spoljni port → log zapisi) umesto haotičnog, neorganizovanog pristupa koji zavisi od iskustva pojedinca.

5. Praktična vežba / napomena

U laboratorijskoj vežbi ovog modula, nakon što namerno unesete grešku u UFW konfiguraciju, provežbajte kompletan dijagnostički redosled od početka do kraja da identifikujete tačno na kom koraku se problem prvi put manifestuje.

6. Najčešće greške

  • Preskakanje osnovnih koraka (status interfejsa, IP adresa) i direktno pokušavanje dijagnostike na nivou aplikacije/servisa — isti obrazac greške kao u Windows dijagnostici (Modul 17, Tema 16).
  • Zaboravljanje da testira dostupnost porta i lokalno i spolja odvojeno (Tema 14) — problem koji izgleda kao „aplikacija ne radi" često je zapravo firewall pravilo koje blokira samo spoljni pristup.

7. Pitanje za proveru znanja

P: Po čemu je sistematska dijagnostika Linux mrežnih problema slična onoj sa Windows sistema (Modul 17), uprkos potpuno različitim alatima? O: Oba redosleda prate isti princip — od osnovnog (status interfejsa/IP konfiguracija) ka specifičnom (konkretan servis/port/firewall), izolujući probleme sloj po sloj — razlikuju se samo konkretni alati koji se koriste na svakom koraku (Linux ip/ss/ufw naspram Windows ipconfig/netstat/Windows Firewall).

Rezime modula

  • Linux koristi predvidljivo imenovanje interfejsa; ip addr/ip link/ip route su moderni alati za pregled i upravljanje mrežnom konfiguracijom, dok su promene preko njih privremene bez trajne konfiguracije (Netplan).
  • ping, traceroute/tracepath dijagnostikuju dostupnost i putanju; ss/netstat prikazuju aktivne konekcije/portove; dig/nslookup postavljaju DNS upite, sa dig pružajući detaljniji tehnički uvid.
  • hostnamectl upravlja imenom hosta; /etc/resolv.conf se na modernim Ubuntu sistemima automatski generiše iz Netplan konfiguracije, ne treba ga ručno editovati.
  • NetworkManager/nmcli je uobičajeniji na desktop distribucijama; Ubuntu Server po podrazumevanom ponašanju koristi Netplan, deklarativan YAML sistem konfiguracije sa bezbednim netplan try mehanizmom.
  • SSH server omogućava bezbedan udaljeni pristup, sa autentifikacijom preko ključeva kao preporučenom praksom; SCP/SFTP koriste istu SSH infrastrukturu za prenos fajlova.
  • UFW pojednostavljuje firewall konfiguraciju (implementiranu preko nftables/iptables ispod haube); nftables je moderniji, jedinstveniji naslednik starijeg iptables frameworka.
  • Provera funkcionalnosti servisa kombinuje DNS, lokalnu i spoljnu proveru portova; journalctl pruža detaljan uvid u log zapise konkretnih servisa.
  • Sistematska dijagnostika prati identičan princip kao na Windows sistemima (Modul 17) — od osnovne konfiguracije ka specifičnom servisu/firewall-u, samo sa Linux-specifičnim alatima.

Mermaid dijagram

graph TD
    A["1. ip link show<br/>(status interfejsa)"] --> B["2. ip addr show<br/>(IP konfiguracija)"]
    B --> C["3. ip route show<br/>(routing tabela)"]
    C --> D["4. ping/tracepath<br/>(lokalna/udaljena povezanost)"]
    D --> E["5. dig/nslookup<br/>(DNS rezolucija)"]
    E --> F["6. ss -tulpn<br/>(lokalni status servisa)"]
    F --> G["7. Provera spolja<br/>(UFW/firewall)"]
    G --> H["8. journalctl -u servis<br/>(detaljan log)"]

Dodatni izvori (opciono)

  • Ubuntu Server Documentation – Netplan
  • man stranice: ip(8), ss(8), dig(1), nftables(8), sshd_config(5)
  • Arch Wiki / Ubuntu Wiki – systemd-resolved i systemd-journald