VPNak etxean konektatzen du, baina hotelako Wi-Fi-n denbora-muga jotzen du

Portátila etxeko Wi-Fi-ra konektatzen da, bezeroa hiru segundotan konektatzen da, eta profil bera ordu bat geroago hotelean huts egiten du. Bitartean ez da ezer eguneratu. Hau bezero batekin aurrez aurre gainbegiratzea, batez ere, zein errore dagokion zein etapari jakitea da, informazio erabilgarria bezeroak inprimatzen duen kodean baitago, huts egin duen egitatean ez. Jarraitu beheko lau urratsak hurrenez hurren eta jakingo duzu izen batek, pakete batek, ataka batek edo politika batek uko egin dizun.

Irakurri errore-kodea etapa gisa, ez epai gisa

Bezeroa hiru mugarri ezberdin ukitzen ditu tunela existitu aurretik. Zerbitzariaren izena ebazten du, sarean dagoen zerbaitetik erantzun bat jasotzen du, eta segurtasun-elkarte bat negoziatzen du. Mugarri bakoitzak bere huts-mezua du, eta Windows bereziki eskuzabala da kode ezberdinekin, zein etapari dagozkion dakizunean.

Kode horietako bik sareak errurik ez duela esan nahi dute. 789 batek paketeak zebiltzala eta bi muturrak kriptografiaren inguruan ados ez zeudela esan nahi du, eta hori etxean konpon dezakezun konfigurazio-arazoa da. 868 batek pakete bakar batek ere ez zuela irten behar esan nahi du, beraz tunelaren diseinua ez da garrantzitsua izena ebatzi arte. Kodea etapa egokian sailkatzeak edozein harrapaketak baino denbora gehiago aurreztatzen du, hurrengo hiru urratsetatik zein saltatu esaten baitizu.

Izan zaitez neurriz zuhur bezeroa Windows ez bada. Hirugarrenen bezeroek horren zatirik handiena "konexioak huts egin du" esaldira murrizten dute, eta horregatik hurrengo bi urratsek ez dute mezuan batere oinarritzen.

Egiaztatu izena tunela errua eman aurretik

Hotel eta aireportu sareek DNS etengabe atzematen dute, eta atari-helbide batekin erantzuten duen ebazle batek zerbitzari hil baten itxura zehatza duen hutsegitea sortzen du. Konparatu tokiko ebazleak esaten duena eta ebazle publiko batek esaten duena:

Resolve-DnsName vpn.example.net -Type A
nslookup vpn.example.net 1.1.1.1
ipconfig /all | findstr /i "DNS Servers"

Bi erantzunak ezberdinak badira, gidatzen ari zaituzte eta gainerako diagnosia alferrikakoa da hori konpondu arte. Atari-helbide batek, bereziki, TCP konexioa pozik onartuko du eta gero trabatuko da, eta horregatik suebaki-blokeo bat dirudi nabigatzailearekin probatzean.

Orain egiaztatu iritsi nahi duzun helbidea erabiltzen ari dena dela. Bezero batzuek aurreko ebazpena profilearen bizitza osoan gordetzen dute cachean, beraz DNS aldaketaren ondorengo birkonexioak helbide zaharrean jarraitzen du. Itxi bezeroa erabat berriro probatu aurretik, leiho berean deskonektatu eta konektatu sakatzearen ordez.

Jakizu zein kanpoko pakete desagertzen den

Tunelak kanpoko fluxu bat du, zure eta zerbitzariaren arteko bidearena erabat, eta fluxu hori da tarteko kutxek sailkatzen eta botatzen dutena. Harrapatu bezeroan, eta gero alderatu funtzionatzen duen sare bat huts egiten duenarekin. Windowsen txertatutako harrapaketak nahikoa da lehen begirada bat emateko:

pktmon filter remove
pktmon filter add -p 500 -t UDP
pktmon start --capture --pkt-size 128
pktmon stop
pktmon etl2txt PktMon.etl

Ikusi nahi duzuna zure paketeak irteten diren ala ez eta zerbait itzultzen den ala ez da. Kanpoan paketeak eta ezer itzuli gabe bideak edo urruneko muturrak botatzen dituela esan nahi du; ezer irten ez bada, bezeroa ez zen bidaltzera iritsi, eta horrek izenaren ebazpenera edo tokiko suebaki-politikara garamatza.

Errepikatu proba bera telefonoaren hotspot batean. Horixe da eskuragarri duzun alderaketarik informatiboena, hoteleko kutxa guztiak bidetik kentzen baititu, portátila, bezeroa eta kredentzialak berdin mantenduz. Tunela hotspot-ean altxatzen bada, utzi zerbitzaria begiratzeari. Han ere huts egiten badu, sareak inoiz eragin ez zuen bezero edo kontu arazo bat duzu.

Aldatu garraio bat eta probatu berriro

Kanpoko fluxua botatzen dela dakizunean, galdera praktikoa sareak zein fluxu baimentzen duen da. Sare murriztu gehienek TCP 443 irtenaria baimentzen dute, bestela ezin baitute funtzionatu, beraz entzulea hara mugitzea da erantzun ohikoa. OpenVPN-en kasuan, hau bezeroaren aldeko etengailua da zerbitzaria aldatu arte:

openvpn --config corp.ovpn --proto tcp-client --remote vpn.example.net 443 --verb 4

IPsec bezeroek baliokide den etengailu bat dute beren ezarpen-paneletan, normalean TCP gaineko IPsec edo NAT zeharkatzea gisa deskribatua. Hura aldatzea diagnosi bat ere bada: tunela TCP gainean altxatu eta UDP gainean hiltzen bada, sareak UDP iragazten duela frogatu duzu, eta toki hori bisitatzen duzun bakoitzean beharko duzun ezarpena ere aurkitu duzu.

Egin aurre lehen saioan routerraren eginbideak desgaitzeko tentazioari. Hotel-sare batean egoerako ikuskapena edo uholde-aurkako babesa itzaltzea ez zaizu posible izango, eta zure ekipamenduan benetako babesa portátil bakar baten truke aldatzen du. Idatzi zein ezarpenek aldatu zuen emaitza, gero jarri berriro eta bilatu sareak dagoeneko baimentzen duen garraio bat.

Egiaztatu profil bera bigarren sarean

Txartela itxi aurretik, frogatu aldaketak eraikina uztea gainditu zuela. Birkonektatu jatorrizko sarean jatorrizko ezarpenekin, harrapatu lehen hogeita hamar segundoak, eta egiaztatu bezeroak hotspot-ean lortu zuen egoera bera lortzen duela:

pktmon filter add -p 443 -t TCP
pktmon start --capture
Get-VpnConnection -Name "Corp" | Select-Object ConnectionStatus, TunnelType, ServerAddress

Azken komandoak agertzen duen bereizketa merezi du gordetzea: profileak tunel konektatua jakinaraz dezake barneko bideratzea oker dagoen bitartean, eta horrek "VPN-a piztuta dago baina ezerk ez du funtzionatzen" sortzen du, eta hori beste artikulu bat da. Zure edizioaren ondoren tunel mota aldatu bazen, profila ez da probatu zenuena.

Gero idatzi aurkikuntza hurrengo pertsonak begiratuko duen tokian. "Enpresako profilak TCP 443 behar du toki honetan; hotelak UDP 500 iragazten du" esaldi bat da lankide batek jardun dezakeena. "VPN-a ezegonkorra da hotelietan" ez da, eta ziurtatzen du ordu bera berriro gastatuko dela hurrengo hilabetean.