Praktični primeri – Modul 18 – Linux mreže

Ovaj dokument sadrži pet detaljno rešenih praktičnih primera i jedan integrativan poslovni scenario.

Primer 1 – Statička IP konfiguracija preko Netplan-a

Situacija: Ubuntu Server treba statičku adresu 192.168.56.20/24, gateway 192.168.56.1, DNS server 8.8.8.8, umesto podrazumevanog DHCP-a.

Konfiguracija (/etc/netplan/00-installer-config.yaml):

network:
  version: 2
  ethernets:
    enp0s3:
      dhcp4: false
      addresses:
        - 192.168.56.20/24
      routes:
        - to: default
          via: 192.168.56.1
      nameservers:
        addresses: [8.8.8.8]

Primena:

$ sudo netplan try

Objašnjenje: dhcp4: false isključuje DHCP (Modul 13) za ovaj interfejs; addresses definiše statičku IP/prefiks (Tema 9). netplan try (ne direktan apply) je namerno korišćen prvi put — ako YAML sintaksa ili konfiguracija sadrži grešku koja bi prekinula mrežnu vezu, promena se automatski poništava nakon kratkog tajmera, sprečavajući da administrator ostane zaključan van servera preko SSH-a.

Primer 2 – SSH server sa autentifikacijom preko ključa

Situacija: Potrebno je omogućiti bezbedan SSH pristup Ubuntu Server-u, koristeći isključivo autentifikaciju preko ključa, bez lozinke.

Koraci (sa host računara i na serveru):

(na host računaru)
$ ssh-keygen -t ed25519
$ ssh-copy-id korisnik@192.168.56.20

(na serveru, /etc/ssh/sshd_config)
PasswordAuthentication no
PermitRootLogin no

(na serveru)
$ sudo systemctl restart sshd

Objašnjenje: ssh-copy-id automatski kopira javni ključ na server u ~/.ssh/authorized_keys (Tema 10). Tek nakon što je potvrđeno da prijava preko ključa radi (testirano pre izmene sshd_config), PasswordAuthentication no bezbedno onemogućava lozinku kao opciju — obrnut redosled bi mogao potpuno da onemogući pristup ako ključ nije ispravno postavljen.

Primer 3 – UFW konfiguracija bez prekidanja sopstvene sesije

Situacija: Administrator je povezan preko SSH-a i treba da uključi UFW na serveru koji, pored SSH-a, treba da dozvoli i HTTP (port 80).

Ispravan redosled:

$ sudo ufw allow OpenSSH
$ sudo ufw allow 80/tcp
$ sudo ufw enable
Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
$ sudo ufw status verbose
Status: active
To                         Action      From
--                         ------      ----
22/tcp (OpenSSH)           ALLOW IN    Anywhere
80/tcp                     ALLOW IN    Anywhere

Objašnjenje: SSH pravilo (Tema 12) je namerno dodato pre ufw enable — da je administrator prvo uključio UFW pa tek onda pokušao da doda SSH pravilo, aktivna SSH sesija bi se odmah prekinula (jer UFW podrazumevano odbija sav dolazni saobraćaj koji nije eksplicitno dozvoljen), zahtevajući fizički pristup serveru za ispravku.

Primer 4 – Dijagnostika: servis sluša lokalno, ali nije dostupan spolja

Situacija: Veb server je instaliran i navodno pokrenut, ali korisnici sa drugih računara ne mogu da mu pristupe.

Dijagnostički koraci:

(na samom serveru)
$ ss -tulpn | grep :80
tcp   LISTEN  0  511  0.0.0.0:80  0.0.0.0:*  users:(("nginx",pid=1234,fd=6))

(sa drugog računara na mreži)
$ nc -zv 192.168.56.20 80
nc: connect to 192.168.56.20 port 80 (tcp) failed: Connection refused

Objašnjenje: ss na samom serveru (Tema 5) potvrđuje da nginx zaista sluša na portu 80, na svim interfejsima (0.0.0.0). Međutim, pokušaj konekcije sa drugog uređaja (Tema 14) ne uspeva — ovo izoluje problem tačno na firewall (UFW, Tema 12), ne na sam veb server, jer je aplikacija dokazano funkcionalna, samo blokirana za dolazni saobraćaj sa mreže. Rešenje: sudo ufw allow 80/tcp.

Primer 5 – Praćenje SSH log zapisa tokom testiranja konfiguracije

Situacija: Nakon izmene SSH konfiguracije (Primer 2), administrator želi da u realnom vremenu vidi da li nova konekcija preko ključa uspeva ili ne, i zašto.

Komande (u dva odvojena terminala/sesije):

(Terminal 1, postojeća sesija na serveru)
$ journalctl -u sshd -f

(Terminal 2, sa host računara, nova konekcija)
$ ssh korisnik@192.168.56.20

Očekivan izlaz u Terminalu 1:

sshd[5678]: Accepted publickey for korisnik from 192.168.56.1 port 54321 ssh2: ED25519 SHA256:...

Objašnjenje: journalctl -u sshd -f (Tema 15) prati SSH log u realnom vremenu — administrator odmah vidi da li je autentifikacija prihvaćena preko javnog ključa (Accepted publickey), ili odbijena, sa tačnim razlogom (npr. „Connection closed by authenticating user" ako ključ nije ispravan), umesto da nagađa zašto konekcija ne uspeva.

Poslovni scenario – Postavljanje bezbednog Linux veb servera

Kontekst: Firma „Nexora Tech" postavlja novi Ubuntu Server koji će hostovati interni veb portal, dostupan zaposlenima preko interne mreže, uz zahtev da administratori mogu bezbedno da mu pristupaju preko SSH-a.

Zahtevi:

• Statička, predvidljiva IP adresa servera.
• Bezbedan SSH pristup, bez lozinke.
• Firewall koji dozvoljava samo neophodan saobraćaj.
• Mogućnost brze dijagnostike ako nešto prestane da radi.

Projektovano rešenje:

Zašto ovakav redosled: Mrežna konfiguracija (Korak 1) mora biti postavljena i stabilna pre bilo čega drugog, jer sve naredne udaljene operacije (SSH pristup, testiranje firewall-a) zavise od stabilne, predvidljive adrese. SSH sa ključem (Korak 2) se konfiguriše pre firewall-a (Korak 3) upravo da bi se izbegla greška iz Primera 3 — dozvoljavanje SSH-a u UFW-u je besmisleno ako sam SSH server još nije ni funkcionalan i testiran.