VPN tengist heima en rennur á tíma á Wi-Fi á hótelinu

Tölvan tengist Wi-Fi heimilisins, biðlarinn tengist á þremur sekúndum, og sama sniðið mistekst á hótelinu klukkustund síðar. Ekkert var uppfært á milli. Að fara í gegnum þetta með biðlara fyrir framan þig snýst að mestu um að vita hvaða villa tilheyrir hvaða áfanga, því gagnlegu upplýsingarnar eru í kóðanum sem biðlarinn prentar, ekki í þeirri staðreynd að hann mistókst. Farðu í gegnum fjögur skrefin hér að neðan í röð og þú munt vita hvort nafn, pakki, port eða stefna neitaði þér.

Lestu villukóðann sem áfanga, ekki sem úrskurð

Biðlarinn nær þremur aðskildum áfangamerkjum áður en göng liggja. Hann leysir nafn þjónsins, fær svar frá einhverju á netinu og semur um öryggistengingu. Hvert áfangamerki hefur sína eigin mistökaskilaboð, og Windows er sérstaklega rausnarlegt með ólíka kóða þegar þú veist hvaða áfanga þeir tilheyra.

Tveir þessara kóða þýða að netið er saklaust. 789 þýðir að pakkar flæddu og endarnir tveir voru ósammála um dulkóðun, sem er stillingarvandamál sem þú getur lagað heima. 868 þýðir að enginn pakki þurfti nokkurn tíma að fara út, svo hönnun ganganna skiptir ekki máli fyrr en nafnið leysist. Að raða kóðanum í réttan áfanga sparar meiri tíma en nokkur fanga, því hann segir þér hvaða af næstu þremur skrefum á að sleppa.

Vertu hófsamlega varkár ef biðlarinn er ekki Windows. Biðlarar frá þriðja aðila þjappa flestu af þessu í "tenging mistókst", og þess vegna treysta næstu tvö skrefin alls ekki á skilaboðin.

Athugaðu nafnið áður en þú kennir göngunni um

Net hótela og flugvalla grípa DNS stöðugt, og leysir sem svarar með vefgáttarfangi framleiðir mistök sem líta nákvæmlega út eins og dauður þjónn. Berðu saman það sem staðbundni leysirinn segir við það sem almennur leysir segir:

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

Ef svörin tvö eru ólík ertu að vera vísað og afgangur greiningarinnar er til einskis þar til það er leyst. Vefgáttarfang sérstaklega tekur TCP-tengingunni fagnandi og stöðvast svo, og þess vegna getur það litið út eins og eldveggsblokkun þegar þú prófar með vafra.

Staðfestu nú að fangið sem þú ætlar að ná er það sem er notað. Sumir biðlarar skyggja fyrri upplausn í alla líftíma sniðsins, svo endurtenging eftir DNS-breytingu fer enn á gamla fangið. Lokaðu biðlaranum algjörlega fyrir endurprófun, í stað þess að ýta á aftengja og tengja í sama glugga.

Finndu út hvaða ytri pakki hverfur

Göngin hafa ytri streymi sem tilheyrir að öllu leyti leiðinni milli þín og þjónsins, og það er það streymi sem millibox flokka og sleppa. Fangaðu það á biðlaranum og berðu svo saman net sem virkar við það sem mistekst. Á Windows nægir innbyggða fangið fyrir fyrsta svip:

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

Það sem þú vilt sjá er hvort pakkarnir þínir fari yfirhöfuð út, og hvort eitthvað komi til baka. Pakkar út án nokkurs til baka þýða að leiðin eða fjarlægi endinn sleppir þeim; ef ekkert fer út yfirhöfuð náði biðlarinn aldrei að senda, sem vísar aftur á nafnaupplausn eða staðbundna eldveggsstefnu.

Endurtaktu sama próf á hotspot úr síma. Þetta er eina upplýsandi samanburðurinn sem þú hefur, því hann fjarlægir hvert box á hótelinu af leiðinni á meðan tölvan, biðlarinn og skilríkin haldast eins. Ef göngin koma upp á hotspotnum skaltu hætta að horfa á þjóninn. Ef þau mistekst þar líka hefur þú biðlara- eða reikningsvandamál sem netið olli aldrei.

Breyttu einni flutningsleið og prófaðu aftur

Þegar þú veist að ytri streyminu er sleppt er hagnýta spurningin hvaða streymi netið leyfir. Flest takmörkuð net leyfa útstreymi TCP 443 því annars geta þau ekki starfað, svo að færa hlustarann þangað er venjulega svarið. Á OpenVPN er þetta rofi á biðlarahlið þar til þjóninum er breytt:

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

IPsec-biðlarar hafa samsvarandi rofa í eigin stillingaspjöldum, venjulega lýst sem IPsec yfir TCP eða NAT-för. Að breyta honum er líka greining: ef göngin koma upp yfir TCP og deyja yfir UDP hefur þú sannað að netið síar UDP, og þú hefur líka fundið stillinguna sem þú þarft í hvert skipti sem þú heimsækir þann stað.

Standast freistingu um að slökkva á eiginleikum beinis við fyrstu tilraun. Að slökkva á ástandsskoðun eða flóðavörn á hótelneti er þér hvort sem er ónothæft, og á þínum eigin búnaði skiptir það raunverulegri vernd fyrir eina tölvu. Skráðu hvaða stilling breytti niðurstöðunni, settu hana svo aftur og leitaðu að flutningsleið sem netið leyfir þegar.

Staðfestu sama snið á öðru netinu

Áður en þú lokar miðanum skaltu sanna að breytingin hafi lifað af að yfirgefa bygginguna. Tengstu aftur á upprunalega netinu með upprunalegu stillingunum, fangaðu fyrstu þrjátíu sekúndurnar og staðfestu að biðlarinn nái sama ástandi og hann náði á hotspotnum:

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

Aðgreiningin sem síðasta skipunin leiðir í ljós er þess virði að halda: sniðið getur tilkynnt tengd göng á meðan leiðsögnin inni í þeim er röng, og það framleiðir "VPN er tengt en ekkert virkar", sem er önnur grein. Ef gerð ganganna breyttist eftir breytingu þína er sniðið ekki það sem þú prófaðir.

Skrifaðu síðan niðurstöðuna þar sem næsta manneskja mun horfa. "Fyrirtækjasniðið þarf TCP 443 á þessum stað; hótelið síar UDP 500" er setning sem kollega getur brugðist við. "VPN er óstöðugt á hótelum" er það ekki, og það tryggir að sama klukkustundin verður eytt aftur í næsta mánuði.