Moj problem sa Wi-Fi vezom na Windowsu 11 bio je dovoljno neobičan da me u početku odvede u potpuno pogrešnom smjeru.

Nakon pokretanja računara sve bi izgledalo normalno. Sistem bi se povezao na kućnu bežičnu mrežu, VPN klijent bi počeo učitavati svoje servise, a onda bi nakon nekoliko sekundi Wi-Fi veza nestala. U sistemskoj traci pojavio bi se simbol globusa ili obavještenje da nema interneta.

Kada bih otvorio listu dostupnih mreža i ručno se ponovo povezao, sve bi proradilo. VPN tunel bi se uspostavio, pristup internetu bi se vratio i veza bi ostala stabilna do kraja dana. Poslije sljedećeg ponovnog pokretanja računara ponavljala se ista situacija.

Upravo je ta pravilnost bila najčudnija. Da je problem bio u slabom signalu, ruteru ili fizičkom kvaru Wi-Fi adaptera, očekivao bih nasumične prekide i tokom rada. Kod mene se prekid dešavao gotovo isključivo pri pokretanju sistema, a ručno ponovno povezivanje rješavalo ga je odmah.

Prvo sam, sasvim očekivano, sumnjao na upravljački program bežičnog adaptera. Provjerio sam mrežne postavke, stanje adaptera i ponašanje rutera. Međutim, ništa od toga nije objašnjavalo zašto veza radi besprijekorno nakon jednog ručnog klika.

Nedostajalo mi je objašnjenje šta se tačno dešava u prvih nekoliko sekundi nakon pokretanja Windowsa. Pronašao sam ga tek kada sam pročitao tri članka posvećena upravo ovom problemu.

Problem nije bio kvar, nego utrka pri pokretanju sistema

Ova tri teksta pomogla su mi da problem prestanem posmatrati kao klasičan prekid Wi-Fi veze. Ono što sam vidio bilo je samo krajnji rezultat sukoba nekoliko mrežnih komponenti koje istovremeno pokušavaju obaviti različite zadatke.

S jedne strane bio je VPN kill switch, odnosno zaštitni mehanizam koji sprečava izlazak mrežnog saobraćaja izvan šifrovanog VPN tunela. Kada koristim strogi ili stalno aktivni kill switch, zaštita ne čeka da se pojavi grafički interfejs VPN aplikacije. Pravila filtriranja mogu biti aktivna već tokom pokretanja sistema.

To je i smisao takve zaštite. Ako VPN tunel još nije spreman, saobraćaj koji bi otkrio stvarnu IP adresu ne bi smio biti propušten običnom mrežnom rutom.

S druge strane, Windows 11 odmah po povezivanju na Wi-Fi želi provjeriti postoji li stvarni pristup internetu. Činjenica da se bežični adapter povezao sa ruterom i dobio lokalnu IP adresu nije dovoljna. Windows koristi Network Connectivity Status Indicator, poznat kao NCSI, da obavi dodatnu provjeru dostupnosti interneta.

U člancima je objašnjeno da NCSI može koristiti DNS upit prema Microsoftovom testnom hostu i HTTP zahtjev prema adresi za provjeru veze. Očekuje tačno određen odgovor kojim potvrđuje da mreža zaista ima pristup internetu.

Tu je bio ključ mog problema.

U trenutku kada je Windows slao testni zahtjev, VPN tunel još nije bio potpuno uspostavljen. Kill switch je već bio aktivan i ispravno je blokirao nezaštićeni izlazni saobraćaj. Zbog toga NCSI provjera nije mogla proći.

Iz perspektive VPN zaštite, sve je radilo kako treba. Iz perspektive Windowsa, mreža koja je povezana sa ruterom, ali ne može odgovoriti na provjeru pristupa internetu, izgledala je kao neispravna veza.

Kada automatski oporavak napravi veći problem

Samo neuspješna NCSI provjera ne bi morala biti ozbiljan problem. Windows bi mogao nekoliko sekundi prikazivati status bez pristupa internetu, sačekati da se VPN tunel uspostavi i zatim ponoviti provjeru.

Problem nastaje zbog agresivnijeg mehanizma koji prati navodno loše stanje mrežne veze. U člancima se taj mehanizam opisuje kao Bad State Tracking, a povezan je sa servisom Windows Connection Manager, odnosno WcmSvc.

Kada Windows zaključi da je mreža u lošem stanju, ne mora ostati samo na prikazivanju upozorenja. Može pokušati automatski oporaviti vezu tako što će prekinuti ili ponovo pokrenuti bežičnu asocijaciju.

Tada se stvara zatvoreni krug:

  1. Wi-Fi adapter se poveže sa ruterom.
  2. Računar dobije lokalnu IP adresu putem DHCP-a.
  3. VPN kill switch počne blokirati saobraćaj koji ne ide kroz tunel.
  4. VPN klijent započne uspostavljanje tunela.
  5. Windows istovremeno pokrene NCSI provjeru pristupa internetu.
  6. Kill switch blokira testni zahtjev jer tunel još nije spreman.
  7. Windows protumači neuspješnu provjeru kao problem sa Wi-Fi mrežom.
  8. WcmSvc pokrene automatski oporavak i prekine bežičnu vezu.
  9. VPN ostane bez fizičke mrežne rute i ne može završiti povezivanje.

To objašnjava zašto se moj VPN nije mogao jednostavno povezati nakon nekoliko dodatnih sekundi. Windows mu je uklonio mrežnu osnovu potrebnu za uspostavljanje tunela.

Objašnjenje iz članaka bilo mi je posebno korisno zato što razdvaja fizičku Wi-Fi vezu, provjeru pristupa internetu i VPN filtriranje. Prije toga sam sve posmatrao kao jednu stvar. Ako nema interneta, pretpostavljao sam da je problem u bežičnoj vezi. U stvarnosti je Wi-Fi veza sa lokalnim ruterom bila uspostavljena, ali je Windows na osnovu neuspješne provjere odlučio da je prekine.

Zašto je ručno povezivanje uvijek uspijevalo

Članci su mi pomogli da razumijem i drugi dio zagonetke: zašto je ručno ponovno povezivanje radilo bez ikakvih dodatnih intervencija.

Prvi pokušaj povezivanja dešavao se tokom osjetljive faze pokretanja računara. VPN servis, mrežni adapter, Windowsovi servisi i sigurnosna pravila aktivirali su se gotovo istovremeno. Nekoliko sekundi kasnije, kada bih ručno kliknuo na svoju Wi-Fi mrežu, VPN servis je već bio učitan i spreman za uspostavljanje tunela.

Zbog toga drugi pokušaj nije ulazio u isti nepovoljan vremenski prozor. Fizička veza bi se vratila, VPN bi se uspješno povezao, a naredna NCSI provjera mogla je proći kroz već uspostavljen tunel.

Dakle, ručno povezivanje nije popravljalo ruter, upravljački program ili adapter. Samo je ponavljalo povezivanje u trenutku kada su svi potrebni servisi već bili spremni.

To je za mene bio prilično uvjerljiv pokazatelj da ne treba nasumično mijenjati upravljačke programe niti isključivati sigurnosne funkcije. Problem je bio u redoslijedu i vremenu pokretanja mrežnih komponenti.

Provjera u Event Vieweru

Nisam želio mijenjati Windows Registry samo na osnovu sličnosti simptoma. Koristan dio tehničkih članaka bio je opis načina na koji se uzrok može provjeriti u Windowsovim zapisima događaja.

Za pregled relevantnih događaja može se otvoriti Event Viewer naredbom:

text

eventvwr.msc

Zatim treba otići na sljedeću putanju:

text

Applications and Services LogsMicrosoftWindowsWLAN-AutoConfigOperational

U tom zapisu mogu se tražiti upozorenja koja vremenski odgovaraju prekidu Wi-Fi veze neposredno nakon pokretanja računara. Članci navode događaje poput ID 11000 i 11004, povezane sa ograničenom povezivošću i pokušajem automatskog oporavka mreže.

Posebno je korisno povezati te događaje sa NCSI zapisima koji ukazuju na neuspješnu aktivnu HTTP provjeru. Takav slijed događaja razlikuje ovaj problem od fizičkog gubitka signala ili nasumičnog kvara upravljačkog programa.

Za mene je ova dijagnostika bila važna jer Registry nije mjesto na kojem volim nasumično isprobavati tuđe komande. Činjenica da su tekstovi objasnili ne samo šta treba promijeniti nego i kako provjeriti pretpostavljeni uzrok učinila je preporučeno rješenje znatno uvjerljivijim.

Rješenje koje ne zahtijeva isključivanje kill switcha

Mogao sam zaobići problem tako što bih isključio strogi VPN kill switch ili spriječio automatsko pokretanje VPN-a. To bi vjerovatno uklonilo vremenski sukob, ali bi istovremeno oslabilo zaštitu zbog koje sam tu funkciju i uključio.

Korisniji pristup iz članaka bio je da se zaustavi automatsko prekidanje Wi-Fi veze, bez diranja VPN filtriranja.

Promjena se odnosi na vrijednost EnableBadStateTracking u konfiguraciji servisa WcmSvc. Iz Command Prompta pokrenutog sa administratorskim ovlaštenjima može se izvršiti sljedeća naredba:

reg add "HKLM\SOFTWARE\Microsoft\WcmSvc" ^    /v EnableBadStateTracking /t REG_DWORD /d 0 /f

Ista naredba može se unijeti i u jednom redu:

reg add "HKLM\SOFTWARE\Microsoft\WcmSvc" /v EnableBadStateTracking /t REG_DWORD /d 0 /f

Ovom promjenom kreira se ili ažurira REG_DWORD vrijednost pod nazivom EnableBadStateTracking i postavlja na 0. Time se isključuje ponašanje zbog kojeg Windows na osnovu procjene lošeg stanja automatski prekida mrežnu vezu.

Nakon promjene potreban je ponovni početak sistema. To nije samo formalni korak, jer se WcmSvc učitava rano i nova postavka se ne mora pouzdano primijeniti tokom već aktivne sesije.

Najvažnije mi je bilo što ovo rješenje ne uklanja VPN kill switch. Ono ne govori VPN-u da propusti nezaštićen saobraćaj. Umjesto toga, govori Windowsu da ne prekida fizičku vezu sa ruterom samo zato što provjera interneta trenutno ne uspijeva.

Ta razlika je suštinska.

Wi-Fi veza i zaštita mrežnog saobraćaja nisu isto

Jedno od najboljih tehničkih objašnjenja koje sam izvukao iz ova tri članka jeste razlika između upravljanja mrežnom vezom i filtriranja paketa.

WcmSvc upravlja odlukama vezanim za stanje i izbor mrežnih interfejsa. U ovom slučaju bitno je da li će Wi-Fi adapter ostati povezan sa pristupnom tačkom.

VPN kill switch djeluje kroz Windows Filtering Platform, odnosno WFP. On odlučuje koji paketi smiju napustiti računar i kojim putem.

Promjena vrijednosti EnableBadStateTracking ne mijenja pravila zaštitnog zida, ne otvara portove, ne prepravlja VPN rute i ne dopušta DNS saobraćaju da zaobiđe VPN. Kill switch i dalje može blokirati saobraćaj ako se VPN tunel prekine.

Jedina bitna promjena je da Windows ostavlja lokalnu Wi-Fi vezu aktivnom dovoljno dugo da VPN završi povezivanje.

Upravo mi je ovo objašnjenje pomoglo da procijenim sigurnosni utjecaj izmjene. Sama činjenica da se nešto mijenja u Registryju ne govori da li je izmjena bezazlena ili rizična. Potrebno je razumjeti koju komponentu kontroliše i koji dio mrežnog toka ostaje netaknut.

Postoji i praktičan kompromis

Ova promjena ipak ima određenu posljedicu, i korisno je znati je unaprijed.

Ako se povežem na Wi-Fi mrežu koja zaista nema pristup internetu, Windows više neće nužno automatski prekinuti vezu u pokušaju oporavka. Adapter može ostati povezan sa lokalnim ruterom, dok će sistem prikazivati status da internet nije dostupan.

To mi nije predstavljalo ozbiljan problem. Radije ću sam odlučiti kada treba prekinuti vezu sa neispravnom mrežom nego dozvoliti Windowsu da prekida ispravnu vezu dok VPN pokušava uspostaviti tunel.

Na poznatoj kućnoj ili poslovnoj mreži takvo ponašanje mi je čak logičnije. Lokalna Wi-Fi veza može biti sasvim ispravna i kada vanjski internet privremeno nije dostupan. Automatsko prekidanje veze sa ruterom ne rješava nužno problem izvan lokalne mreže.

Na javnim mrežama, posebno onima sa neispravnim pristupom internetu ili problematičnim portalom za prijavu, možda ću morati ručno prekinuti vezu i izabrati drugu mrežu. To je stvarni kompromis, ali nije isto što i slabljenje VPN zaštite.

Mogućnost vraćanja prvobitnog ponašanja

Dobro sistemsko rješenje treba imati jasan način povratka na prethodno stanje. I tu su članci bili praktični.

Ako želim ukloniti dodanu vrijednost i vratiti Windowsovo zadano ponašanje, mogu pokrenuti Command Prompt kao administrator i izvršiti:

reg delete "HKLM\SOFTWARE\Microsoft\WcmSvc" ^    /v EnableBadStateTracking /f

Ili u jednom redu:

reg delete "HKLM\SOFTWARE\Microsoft\WcmSvc" /v EnableBadStateTracking /f

Nakon toga je ponovo potrebno pokrenuti računar.

Ova mogućnost mi je bila bitna jer izmjena nije nepovratna. Ako se kasnije promijeni ponašanje Windowsa, VPN klijenta ili moje mrežne konfiguracije, postavku mogu ukloniti bez nagađanja koja je zadana vrijednost ranije bila upisana.

Šta su mi ova tri teksta stvarno razjasnila

Najveća vrijednost ovih članaka za mene nije bila samo jedna Registry naredba. Bez tehničkog konteksta mogao sam je kopirati, privremeno riješiti problem i ostati bez razumijevanja šta sam zapravo promijenio.

Jedan tekst mi je problem približio kroz jednostavan opis sukoba između Windowsove provjere mreže i VPN kill switcha. To mi je pomoglo da prepoznam vlastite simptome i prestanem sumnjati na kvar rutera ili Wi-Fi kartice.

Detaljnija objašnjenja zatim su povezala WFP, NCSI, WcmSvc, WlanSvc, DHCP i Bad State Tracking u jedan smislen slijed. Tek tada sam razumio kako jedna blokirana HTTP provjera može dovesti do fizičkog prekida bežične veze.

Treći koristan element bila je dijagnostika kroz Event Viewer, zajedno sa objašnjenjem sigurnosnog utjecaja i načinom vraćanja promjene. To je preporuku pretvorilo iz običnog savjeta sa interneta u postupak koji sam mogao razumjeti, provjeriti i kontrolisano primijeniti.

Sva tri članka obrađuju isti problem, ali njihove informacije zajedno daju potpuniju sliku. Jednostavnije objašnjenje pomaže pri prepoznavanju simptoma, arhitektonski detalji objašnjavaju mehanizam, a dijagnostički i operativni koraci omogućavaju da se rješenje primijeni bez nepotrebnog rizika.

Problem je bio u pogrešnoj pretpostavci Windowsa

Ovo iskustvo me podsjetilo koliko status „nema interneta” može biti neprecizan opis stvarnog stanja mreže. Wi-Fi adapter može biti uredno povezan sa ruterom. Lokalna IP adresa može biti ispravno dodijeljena. VPN zaštita može raditi tačno onako kako je podešena. Ipak, Windows može zaključiti da je veza neispravna jer njegova vanjska provjera nije dobila očekivani odgovor.

Kod mene se nije kvarila mreža. Windows je privremeno blokiran testni saobraćaj protumačio kao dokaz da je Wi-Fi veza loša, a zatim pokušao pomoći tako što ju je prekinuo. Taj automatski pokušaj oporavka bio je pravi uzrok prekida.

Nakon što sam prošao kroz objašnjenja iz ova tri članka, cijeli obrazac je napokon imao smisla: prekid samo pri pokretanju, stabilna veza nakon ručnog povezivanja, aktivan VPN kill switch i odsustvo bilo kakvih problema tokom ostatka dana.

Rješenje nije bilo da žrtvujem privatnost, isključim sigurnosnu funkciju ili nasumično mijenjam upravljačke programe. Trebalo je samo spriječiti Windows da prerano donese pogrešan zaključak i prekine vezu koja je VPN-u bila potrebna.

Za mene je to i najkorisnija pouka cijelog slučaja. Kada nekoliko zaštitnih i automatizovanih sistema djeluje istovremeno, svaki od njih može pojedinačno raditi prema svojoj logici, a da njihov zajednički rezultat ipak bude pogrešan. Tek kada sam razdvojio fizičku vezu, provjeru dostupnosti interneta i VPN filtriranje, prestao sam popravljati pogrešan dio sistema.

Noel

IZVORI