VPN Hardening: Protokoli, autentifikacija i put ka Zero Trust pristupu

VPN je pominjan usput kroz gotovo svaku prethodnu seriju na ovom blogu — kao alternativa izlaganju RDP ili SSH porta, kao način udaljenog pristupa firewall administraciji, kao osnovna zaštita saobraćaja između lokacija. Ovaj tekst mu daje pažnju koju zaslužuje kao samostalna tema: koji protokol odabrati i zašto, kako podesiti autentifikaciju da VPN ne postane sam sebi slaba tačka, i gde se u 2026. godini VPN uklapa u širu priču o zero trust pristupu koja sve više preoblikuje kako se udaljeni pristup uopšte razmišlja.

Zašto VPN i dalje zaslužuje pažnju u eri zero trust-a

Vredi ovo pitanje postaviti direktno, jer je legitimno: sve više izveštaja i proizvođača govori o zameni VPN-a sa ZTNA (Zero Trust Network Access) pristupom, opisanim detaljnije kasnije u tekstu. Realnost za veliku većinu organizacija, posebno manjih i srednjih, jeste da je zero trust putovanje, ne prekidač koji se jednostavno uključi — migracija zahteva vreme, budžet, i promenu navika koje se ne dešavaju preko noći. Dobro podešen VPN sa jakom autentifikacijom, pravilnom segmentacijom i disciplinom ažuriranja i dalje je znatno bolji od nedostatka bilo kakvog kontrolisanog udaljenog pristupa, ili, još gore, od lošeg, zapuštenog VPN-a koji svi u organizaciji tretiraju kao formalnost.

Izbor protokola — tri ozbiljna kandidata, različiti kompromisi

Tri protokola dominiraju savremenim VPN pejzažom, i vredi razumeti njihove suštinske razlike pre nego što se donese odluka, jer se odluka teško menja naknadno bez značajnog operativnog troška.

WireGuard je najnoviji od tri, sa namerno malim, lako proverljivim kodom (oko 4.000 linija za kernel implementaciju, u poređenju sa stotinama hiljada linija OpenSSL biblioteke koju OpenVPN koristi) — manja kodna baza znači manju površinu za ranjivosti i lakšu, temeljitiju bezbednosnu reviziju. Koristi savremene kriptografske primitive (ChaCha20, Poly1305, Curve25519) i radi u kernel prostoru na Linux-u, što mu daje značajnu prednost u performansama — nezavisni testovi dosledno pokazuju nekoliko puta veću propusnost i znatno nižu latenciju u odnosu na OpenVPN na istom hardveru.

OpenVPN je najstariji od tri, sa preko dve decenije terenske primene i najširom kompatibilnošću klijenata, uključujući mogućnost rada preko TCP porta 443 — što ga čini praktično nezaobilaznim izborom u mrežama sa strogim izlaznim filtriranjem gde UDP saobraćaj (koji WireGuard po difoltu koristi) može biti blokiran. Ova fleksibilnost dolazi po ceni performansi — rad u korisničkom prostoru (user-space) umesto kernela nosi merljivo veći trošak po CPU i latenciju.

IPsec (obično u kombinaciji sa IKEv2 za razmenu ključeva) ostaje dominantan izbor za site-to-site VPN između enterprise mrežne opreme — praktično svaki ozbiljan ruter i firewall proizvođač ga podržava nativno, uz hardversku akceleraciju na namenskim uređajima koja ga čini brzim upravo u tom kontekstu. Kompleksnost konfiguracije (odvojene baze bezbednosnih politika i asocijacija) čini ga podložnijim greškama u ručnom podešavanju nego što su druga dva protokola, ali njegova standardizovanost i duga istorija čine ga i dalje preovlađujućim izborom u regulisanim, enterprise okruženjima.

Šta treba uraditi

• Za remote-access VPN (pojedinačni korisnici koji se povezuju sa udaljenih lokacija) u novim implementacijama, WireGuard je razuman podrazumevani izbor gde platforma i klijentska podrška to dozvoljavaju — kombinacija performansi i male, proverljive kodne baze čini ga snažnim izborom za većinu scenarija
• Zadržati OpenVPN kao rezervni put (fallback) za mreže ili klijente gde UDP saobraćaj može biti blokiran — TCP/443 varijanta OpenVPN-a prolazi kroz gotovo svaki firewall koji dozvoljava standardan veb saobraćaj
• Za site-to-site veze između enterprise mrežne opreme, IPsec/IKEv2 ostaje adekvatan, dobro podržan izbor, posebno gde postojeća infrastruktura (kao Fortinet ili Palo Alto uređaji obrađeni u Firewall Hardening seriji na ovom blogu) već ima ugrađenu, hardverski ubrzanu podršku
• Nikad ne koristiti PPTP, i izbegavati L2TP/IPsec bez dodatnog sloja enkripcije — oba su zastarela, sa poznatim, javno dokumentovanim slabostima, i ne bi trebalo da budu deo bilo koje nove implementacije u 2026. godini
• Tretirati izbor protokola kao arhitekturnu odluku sa realnim, dugoročnim posledicama — migracija između protokola kasnije zahteva koegzistenciju oba tokom prelaznog perioda, ne prost, trenutan prekidač

Autentifikacija — VPN kao ulazna vrata zaslužuje najjaču moguću bravu

Isti princip phishing-otporne, obavezne MFA koji se ponavlja kroz svaku seriju o kritičnoj infrastrukturi na ovom blogu ima ovde možda i najdirektniju primenu — VPN je, po definiciji, ulazna tačka sa spoljne, nepoverljive mreže ka unutrašnjoj, poverljivoj mreži, i kompromitacija te tačke poništava vrednost svega iza nje.

Šta treba uraditi

• Zahtevati MFA za svaku VPN konekciju, bez izuzetka, uključujući i site-to-site veze gde je to tehnički izvodljivo — sertifikat-bazirana autentifikacija (gde uređaj poseduje kriptografski sertifikat izdat od poverljivog, internog CA) predstavlja jak, phishing-otporan drugi faktor koji se dobro uklapa uz standardnu korisničku lozinku
• Integrisati VPN autentifikaciju sa centralizovanim identity sistemom (RADIUS/LDAP povezano sa AD-om, opisano kroz raniju seriju na ovom blogu) umesto vođenja odvojene, lokalne baze VPN korisnika — ovo osigurava da deprovizioniranje naloga pri odlasku zaposlenog automatski ukine i VPN pristup, bez potrebe za ručnim, lako zaboravljivim dodatnim korakom
• Proveravati stanje uređaja (device posture) pre dozvoljavanja konekcije gde platforma to podržava — da li je uređaj upravljan od strane organizacije, da li ima ažuran EDR/antivirus, da li ispunjava minimalne bezbednosne standarde — umesto oslanjanja isključivo na to da je neko uneo ispravne kredencijale
• Postaviti razuman, ne predugačak period ponovne autentifikacije za dugotrajne sesije — VPN sesija koja ostaje aktivna nedeljama bez ponovne provere identiteta produžava prozor u kojem kompromitovana sesija ostaje korisna napadaču

Split tunneling — praktičan kompromis sa realnim rizikom

Ovo je koncept vredan detaljnog objašnjenja jer predstavlja čest, konkretan kompromis sa kojim se svaka organizacija koja koristi VPN suočava. Full tunnel usmerava sav saobraćaj korisnika (uključujući običan pristup internetu, ne samo pristup internim resursima) kroz VPN tunel i dalje kroz organizacionu mrežu — bezbednije, jer sav saobraćaj prolazi kroz centralnu inspekciju i kontrolu, ali sporije i skuplje po propusnom opsegu, posebno za saobraćaj koji nema nikakve veze sa internim resursima organizacije (npr. striming video sadržaja ili obično pretraživanje interneta). Split tunneling usmerava kroz VPN samo saobraćaj namenjen internim resursima, dok ostatak ide direktno na internet sa uređaja korisnika — brže i jeftinije, ali otvara prozor rizika: uređaj istovremeno ima aktivnu vezu ka poverljivoj internoj mreži i nekontrolisan, direktan pristup nepoverljivom internetu, što ga čini potencijalnim mostom za lateralno kretanje ako bude kompromitovan preko tog nekontrolisanog puta.

Šta treba uraditi

• Za administratore, finansijski tim, i bilo koga sa privilegovanim pristupom osetljivim sistemima, zahtevati full tunnel bez izuzetka — trošak propusnog opsega je zanemarljiv u poređenju sa rizikom da privilegovan nalog postane most za lateralno kretanje
• Za standardne korisnike na upravljanim (organizacija-kontrolisanim) uređajima sa ažurnim EDR/endpoint zaštitom, split tunneling može biti prihvatljiv kompromis — ali sprovesti ovu politiku kroz centralno upravljanu, klijent-stranu konfiguraciju (Group Policy na Windows-u ili ekvivalentan mehanizam), ne ostaviti je kao opciju koju pojedinačni korisnik sam bira
• Nikad dozvoliti split tunneling na neupravljanim, ličnim (BYOD) uređajima bez dodatnih kompenzacionih mera — neupravljan uređaj sa istovremenim pristupom internoj mreži i nekontrolisanim internetom predstavlja rizik koji nadmašuje uštedu u propusnom opsegu
• Uključiti VPN kill switch po difoltu, kroz politiku, ne kao opcionu funkciju koju korisnik sam uključuje — kill switch blokira sav internet saobraćaj ako VPN konekcija neočekivano padne, sprečavajući da kredencijali, sesijski tokeni i osetljivi podaci nekontrolisano "iscure" na nezaštićenu mrežu (javni WiFi, hotelska mreža) u trenutku prekida veze

Segmentacija i pristup po ulozi — VPN ne treba da bude univerzalni ključ

Isti princip least privilege koji se provlači kroz svaku seriju na ovom blogu ima ovde konkretnu, često zanemarenu primenu: uspešna VPN autentifikacija ne treba automatski da otvori pristup celoj internoj mreži. Inženjer koji se povezuje radi pristupa razvojnom okruženju ne treba mrežnu rutu ka finansijskoj bazi podataka, čak i ako je uspešno prošao MFA proveru.

Šta treba uraditi

• Mapirati VPN pristup na role-bazirane mrežne politike, ograničavajući koje interne segmente svaka grupa korisnika stvarno sme da dosegne nakon uspostavljanja VPN konekcije — isti princip komunikacione matrice i mikrosegmentacije detaljno obrađen u Firewall Hardening seriji na ovom blogu
• Tretirati VPN gateway kao DMZ granicu, nikad smeštenu direktno u samo srce produkcione mreže — segmentisati VPN infrastrukturu na ulazni (terminacija VPN konekcije), inspekcioni (gde se primenjuje dodatna kontrola, DLP gde je relevantno) i izlazni sloj (specifični, ograničeni pristup ka aplikativnim segmentima), po istom principu slojevite DMZ arhitekture opisanom u Firewall Hardening seriji
• Primenjivati mikrosegmentaciju između internih odeljenja/segmenata i za saobraćaj koji dolazi kroz VPN, ne samo za saobraćaj koji nastaje unutar same mreže — VPN korisnik ne zaslužuje automatski šire poverenje samo zato što je uspešno prošao autentifikaciju na granici

Održavanje — isti princip discipline ažuriranja, primenjen na kritičnu granicu

VPN gateway, kao i firewall opisan u prethodnoj seriji na ovom blogu, predstavlja mrežno izloženu, kritičnu komponentu čije zakrpe zaslužuju prioritet iznad standardnog ciklusa. Ranjivosti u VPN softveru — bilo komercijalnim (Fortinet, Palo Alto SSL VPN komponente) ili open-source (OpenVPN, WireGuard implementacije) — redovno se pojavljuju na CISA KEV katalogu opisanom u Windows Server hardening seriji, upravo zato što VPN gateway predstavlja direktan, atraktivan put ka unutrašnjosti mreže.

Šta treba uraditi

• Tretirati VPN softver i firmver sa istim prioritetom brzog ažuriranja opisanim za internet-izložene servere u Windows Server hardening seriji — ranjivost na CISA KEV katalogu koja pogađa VPN komponentu zaslužuje hitan, ne standardan ciklus odgovora
• Pratiti bezbednosne biltene proizvođača VPN rešenja redovno, po istom principu opisanom kroz Firewall Hardening seriju za Fortinet i Palo Alto specifično
• Logovati VPN konekcije detaljno (korisničko ime, izvorna IP adresa, dodeljena interna adresa, vreme trajanja sesije) i prosleđivati te logove ka centralnom SIEM sistemu, po istom principu centralizovanog logovanja koji se provlači kroz celu ovu seriju blogova — neuobičajen obrazac (prijava sa neočekivane geografske lokacije, sesija u neobično doba noći) često je prvi vidljiv signal kompromitovanih kredencijala

ZTNA — kuda se stvari kreću, i zašto to ne mora biti sve-ili-ništa odluka

Vredi na kraju objasniti zaista suštinsku razliku između klasičnog VPN-a i Zero Trust Network Access pristupa koji ga sve više dopunjuje ili delimično zamenjuje, jer razumevanje ove razlike pomaže da se donese informisana odluka o tome kuda usmeriti dalja ulaganja. Klasičan VPN, jednom uspostavljen, daje korisniku mrežnu prisutnost unutar cele (ili šire) interne mreže — dobra metafora je glavni ključ koji otvara ceo objekat. ZTNA radi suštinski drugačije: ne povezuje korisnika na mrežu uopšte, već posreduje pristup konkretnoj, pojedinačnoj aplikaciji kroz centralni brokerski servis koji proverava identitet, stanje uređaja, i kontekst (vreme, lokacija) pre svakog pristupa — korisnik nikad ne dobija mrežnu vidljivost ka bilo čemu osim tačno onoj aplikaciji kojoj mu je pristup odobren, ekvivalent ključa koji otvara samo jednu, tačno određenu prostoriju, ne ceo objekat.

Ovo direktno rešava problem lateralnog kretanja opisan kroz segmentaciju ranije u tekstu — ako je ZTNA sesija kompromitovana, šteta je ograničena na tu jednu aplikaciju kojoj je pristup bio odobren, ne na celu mrežnu prisutnost koju klasičan VPN po difoltu pruža.

Šta treba uraditi

• Posmatrati ZTNA kao nadogradnju, ne zamenu za postojeću VPN infrastrukturu, posebno za organizacije koje nisu spremne za potpunu, odjednom sprovedenu migraciju — hibridan pristup (ZTNA broker za pristup specifičnim, kritičnim aplikacijama, VPN i dalje za širi, opštiji pristup) smanjuje rizik migracije i čuva postojeće ulaganje u PKI i identity infrastrukturu
• Prioritizovati ZTNA uvođenje za najosetljivije, najkritičnije aplikacije prvo — isti princip prioritizacije prema stvarnom riziku koji se provlači kroz svaku seriju na ovom blogu, umesto pokušaja da se sve odjednom migrira
• Za organizacije bez resursa ili trenutne potrebe za punom ZTNA migracijom, fokusirati energiju na to da postojeći VPN bude što bolje podešen prema principima opisanim kroz ceo ovaj tekst — dobro hardenovan VPN sa jakom MFA, segmentacijom i disciplinom ažuriranja ostaje solidna, brnjena osnova, čak i dok se dugoročna ZTNA strategija tek gradi

VPN ostaje, i u 2026. godini, temeljna komponenta udaljenog pristupa za veliku većinu organizacija — pitanje nije da li ga koristiti, već da li je podešen sa istom pažnjom koju smo kroz celu ovu seriju blogova primenjivali na svaku drugu kritičnu tačku infrastrukture: jaka autentifikacija, precizna segmentacija, disciplina ažuriranja, i realno razumevanje gde se nalazi na putu ka širem, zero trust pristupu koji budućnost sve više oblikuje.