VPN yhdistyy kotona mutta aikakatkaisee hotellin Wi-Fi-verkossa

Kannettava liittyy kodin Wi-Fi-verkkoon, asiakas yhdistää kolmessa sekunnissa, ja sama profiili epäonnistuu hotellissa tuntia myöhemmin. Välissä ei päivitetty mitään. Tämän läpikäyminen asiakkaan kanssa edessäsi on enimmäkseen sitä, että tietää mikä virhe kuuluu mihinkin vaiheeseen, koska hyödyllinen tieto on koodissa, jonka asiakas tulostaa, ei siinä että se epäonnistui. Käy alla olevat neljä vaihetta järjestyksessä läpi, niin tiedät hylkäsikö sinut nimi, paketti, portti vai käytäntö.

Lue virhekoodi vaiheena, älä tuomiona

Asiakas saavuttaa kolme erillistä virstanpylvästä ennen kuin tunnelia on olemassa. Se ratkaisee palvelimen nimen, saa vastauksen joltakin verkossa ja neuvottelee tietoturvayhteyden. Jokaisella virstanpylväällä on oma epäonnistumisviestinsä, ja erityisesti Windows on antelias erilaisten koodien kanssa, kun tiedät mihin vaiheeseen ne kuuluvat.

Kaksi näistä koodeista tarkoittaa, että verkko on syytön. 789 tarkoittaa, että paketit liikkuivat ja molemmat päät olivat eri mieltä salauksesta, mikä on asetusongelma, jonka voit korjata kotona. 868 tarkoittaa, ettei yhdenkään paketin tarvinnut lähteä, joten tunnelin suunnittelu on merkityksetön, kunnes nimi ratkeaa. Koodin lajittelu oikeaan vaiheeseen säästää enemmän aikaa kuin mikään kaappaus, koska se kertoo, minkä seuraavista kolmesta vaiheesta voi ohittaa.

Ole asianmukaisen varovainen, jos asiakas ei ole Windows. Kolmannen osapuolen asiakkaat tiivistävät suurimman osan tästä muotoon "yhteys epäonnistui", minkä vuoksi kaksi seuraavaa vaihetta eivät luota viestiin lainkaan.

Tarkista nimi ennen kuin syytät tunnelia

Hotelli- ja lentoasemaverkot sieppaavat DNS:ää jatkuvasti, ja ratkaisija, joka vastaa portaaliosoitteella, tuottaa epäonnistumisen, joka näyttää täsmälleen kuolleelta palvelimelta. Vertaa, mitä paikallinen ratkaisija sanoo, siihen, mitä julkinen sanoo:

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

Jos kaksi vastausta eroavat, sinua ohjataan ja loput diagnoosista on hukassa, kunnes se ratkeaa. Erityisesti portaaliosoite ottaa TCP-yhteyden mielellään vastaan ja jumittuu sitten, minkä vuoksi se voi selaimella testattaessa näyttää palomuurin estolta.

Vahvista nyt, että osoite, johon aiot päästä, on se jota käytetään. Jotkut asiakkaat välimuistittavat aiemman ratkaisun profiilin koko eliniäksi, joten DNS-muutoksen jälkeinen uudelleenyhdistäminen menee yhä vanhaan osoitteeseen. Sulje asiakas kokonaan ennen uutta testiä sen sijaan, että painat katkaise ja yhdistä samassa ikkunassa.

Selvitä, mikä ulompi paketti katoaa

Tunnelilla on ulompi virtaus, joka kuuluu kokonaan sinun ja palvelimen väliseen polkuun, ja juuri sitä virtausta välilaatikot luokittelevat ja pudottavat. Kaappaa se asiakkaalla ja vertaa sitten toimivaa verkkoa epäonnistuvaan. Windowsissa sisäänrakennettu kaappaus riittää ensisilmäykseen:

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

Haluat nähdä, lähtevätkö pakettisi ylipäätään ja tuleeko jotain takaisin. Paketteja ulos ilman mitään takaisin tarkoittaa, että polku tai kaukopää pudottaa ne; jos ulos ei lähde mitään, asiakas ei koskaan päässyt lähettämiseen, mikä viittaa takaisin nimen ratkaisuun tai paikalliseen palomuurikäytäntöön.

Toista sama testi puhelimen hotspotilla. Tämä on ainoa kaikkein informatiivisin vertailu käytettävissäsi, koska se poistaa polulta jokaisen hotellin laatikon pitäen kannettavan, asiakkaan ja tunnistetiedot samoina. Jos tunneli nousee hotspotilla, lopeta palvelimen katsominen. Jos se epäonnistuu myös siellä, sinulla on asiakas- tai tilihäiriö, jota verkko ei koskaan aiheuttanut.

Vaihda yksi kuljetus ja testaa uudelleen

Kun tiedät, että ulompi virtaus pudotetaan, käytännön kysymys on, minkä virtauksen verkko kuitenkin sallii. Useimmat rajoitetut verkot sallivat lähtevän TCP 443:n, koska ne eivät muuten toimisi, joten kuuntelijan siirtäminen sinne on tavallinen vastaus. OpenVPN-ohjelmassa se on asiakaspuolen kytkin, kunnes palvelinta muutetaan:

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

IPsec-asiakkailla on vastaava kytkin omissa asetuspaneleissaan, yleensä kuvattu nimellä IPsec TCP:n yli tai NAT:n läpikulku. Sen muuttaminen on myös diagnoosi: jos tunneli nousee TCP:n yli ja kuolee UDP:n yli, olet todistanut, että verkko suodattaa UDP:tä, ja löysit myös asetuksen, jota tarvitset joka kerta siinä paikassa vieraillessasi.

Vastusta kiusausta kytkeä reitittimen ominaisuuksia pois ensimmäisellä yrityksellä. Tilallisen tarkastuksen tai tulvasuojauksen pois kytkeminen hotelliverkossa ei ole sinulle muutenkaan mahdollista, ja omassa laitteistossasi se vaihtaa todellisen suojauksen yhteen kannettavaan. Merkitse muistiin, mikä asetus muutti tuloksen, palauta se sitten ja etsi kuljetus, jonka verkko jo sallii.

Varmista sama profiili toisessa verkossa

Ennen kuin suljet tiketin, todista, että muutos kesti rakennuksesta lähtemisen. Yhdistä uudelleen alkuperäisessä verkossa alkuperäisillä asetuksilla, kaappaa ensimmäiset kolmekymmentä sekuntia ja vahvista, että asiakas saavuttaa saman tilan kuin hotspotilla:

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

Viimeisen komennon paljastama ero kannattaa pitää: profiili voi raportoida yhdistetyn tunnelin, vaikka sen sisäinen reititys on väärä, ja se tuottaa "VPN on päällä mutta mikään ei toimi", mikä on toinen artikkeli. Jos tunnelityyppi muuttui muokkauksesi jälkeen, profiili ei ole se, jota testasit.

Kirjoita sitten löydös sinne, minne seuraava henkilö katsoo. "Yritysprofiili tarvitsee tässä paikassa TCP 443:n; hotelli suodattaa UDP 500:n" on lause, jonka perusteella kollega voi toimia. "VPN on hotelleissa epävakaa" ei ole, ja se takaa, että sama tunti käytetään uudelleen ensi kuussa.