Avoimessa verkossa yhteyspisteesi ei vain luovuta paketteja internetiin. Ylempänä oleva käytäntöpiste tarkistaa, onko laitteesi jo valtuutettu, ja kunnes on, lähes kaikki pudotetaan. VPN-asiakkaasi lukee tuon hiljaisuuden kuolleeksi palvelimeksi. Se harvoin sanoo sitä: WireGuard toistaa kättelyn tyhjyyteen, OpenVPN raportoi yhteyden aikakatkaisun ja IKEv2 palaa virheenä 809 etäpalvelimesta, joka ei vastaa.

Mitä portaali todella hallitsee

Vangitsemisportaali on kaksi yhteen niitattu asiaa: käytäntöpäätöspiste ja uudelleenohjaaja. Kun laitteesi liittyy ja ottaa DHCP-vuokran, verkko asettaa sinut valtuutusta edeltävään tilaan.

Tämä tila on palomuurin sääntöjoukko. Se yleensä sallii DNS:n ja sallii HTTP:n tai HTTPS:n lyhyelle luettelolle portaalin isäntiä, ja se hylkää kaiken muun. Sallittu luettelo on muurien ympäröimä puutarha, eikä se juuri koskaan sisällä VPN-päätepistettä.

Mikään noista pudotuksista ei ole kohtelias. VPN-palvelimelle osoitetut paketit hylätään eikä niitä torjuta, joten asiakas ei saa ICMP unreachablea eikä TCP resetiä, vain vastauksen puuttumisen. Valmistajasta riippuen uudelleenohjaaja voi vastata porttiin 80 uudelleenohjauksella kirjautumissivulle, kun taas portti 443 pudotetaan tai siepataan. Uudelleenohjaukset on helppo havaita, koska ne kantavat tavallisen HTTP-vastauksen; sieppaaminen portilla 443 vaatii varmenteen, jota selaimesi kieltäytyy luottamasta.

Valtuutus itsessään on yleensä sidottu laitteen MAC-osoitteeseen, joskus vuokrattuun IP:hen, ja se elää ajastimella varustetussa istuntotaulukossa. Sisäänkirjautuminen luo merkinnän. Palomuurisääntö, joka päästää liikenteesi läpi, on olemassa vain niin kauan kuin tuo merkintä on, ja siksi koko ongelma palaa myöhemmin ilman, että mitään muuttuu sinun puolellasi.

Miksi VPN:n kättely kuolee ennen kuin se alkaa

Jokaisella protokollalla on oma kuljetuksensa, ja valtuutusta edeltävä palomuuri rikkoo jokaisen eri tavalla. IKEv2 Windowsissa ja iOS:ssä kulkee UDP 500:n ja UDP 4500:n päällä; pudotus noilla porteilla näkyy 809:nä tai nimien selvityksen kaltaisena vikana asiakkaissa, jotka raportoivat vaiheet erikseen. OpenVPN UDP 1194:n yli pysyy yhdistämistilassa, kunnes sen aikakatkaisu päättyy. OpenVPN TCP 443:n yli on kiinnostava tapaus, koska portaali voi suorittaa TCP-kättelyn loppuun ja vastata sitten uudelleenohjaussivullaan, joten näet aikakatkaisun sijaan TLS-virheen.

WireGuard näyttää mekanismin selkeimmin. Se on suunnittelultaan vain UDP, ilman TCP-varavaihtoehtoa, joten palomuuri, joka hylkää tuntemattoman UDP:n, poistaa kuljetuksen kokonaan. Asiakas lähettää edelleen kättelyn aloituksia kasvavalla viiveellä ja raportoi kättelystä, joka ei koskaan valmistu. Mikään tuossa viestissä ei mainitse Wi-Fiä, eikä mikään siinä vihjaa, että sinun pitäisi avata selain.

Alustat yrittävät huomata tilan ennen VPN:ääsi. Windows hakee tunnetun URL:n päättääkseen, näyttääkö se kirjautumisilmoituksensa, Android pyytää päätepistettä, jonka pitäisi vastata 204 No Content, ja Apple-laitteet avaavat pienen vangitsemisverkon ikkunan. Ne tunnustelut toimivat, koska portaali vastaa uudelleenohjauksella odotetun rungon sijaan. Sama käyttäytyminen selittää, miten portaali voi näyttää täysin terveeltä, kun tunnelisi on kuollut: tunnustelua ja tunnelia arvioidaan eri säännöillä.

Mitä istunnon vanheneminen todella nollaa

Paikat vanhentavat istuntoja syistä, jotka eivät liity VPN-tiliisi: joutokäynnin aikakatkaisu, istunnon enimmäispituus, uusi DHCP-vuokra tai uudelleenliittyminen toiseen yhteyspisteeseen. Kun ajastin laukeaa, istuntotaulukon merkintä katoaa ja valtuutusta edeltävä sääntöjoukko palaa täsmälleen sellaisena kuin se oli sisäänkirjautuessa.

Muodostettu tunneli selviää usein tarpeeksi kauan näyttääkseen terveeltä. Keepalive-viestit jatkavat matkaa, ja huomaako asiakas sen, riippuu siitä, miten se käsittelee vastaamatonta liikennettä, joten tilavalo voi pysyä vihreänä jonkin aikaa polun kadottua. Sitten tunneli putoaa ja jokainen uudelleenyhdistämisyritys epäonnistuu samoilla estetyillä porteilla.

Siinä vaiheessa asiakkaan virhe kertoo, missä vaiheessa olet, jos luet sen huolellisesti:

SymptomWhat it meansNext check
Handshake times out with no replyPre-authorization drop on UDPLoad any HTTP page and see whether the portal appears
Immediate TLS error on 443The portal answered your TCP connectionAuthorize, then retry the same profile
Authentication rejectedYour credentials reached the serverThe network is fine, so treat this as an account problem
Connects, then drops repeatedlySession or lease churnWatch the portal timer and the lease time

Yksi yksityiskohta hämää ihmisiä: kun istunto on sidottu MAC-osoitteeseen, kirjautumissivun uudelleenlataus ei välttämättä auta. Sinun on irrotettava liitos ja liityttävä uudelleen, jotta portaali näkee uuden valtuutusyrityksen vanhentuneen sijaan.

Kirjaudu ensin sisään, nosta sitten tunneli

Toimiva järjestys on: valtuuta laite, todista polku, käynnistä VPN, todista tunneli ja palauta sitten tavallinen estosi. Viimeinen vaihe on tärkeä, koska väliaikainen tila, jonka tarvitset portaaliin pääsemiseksi, on täsmälleen se tila, jonka kill switch on olemassa estääkseen.

Työpöytäasiakas, jossa on tunnelin ulkopuolisen eston vaihtoehto, on keskeytettävä, jotta portaalinsivu latautuu, ja arkaluontoiset sovellukset kannattaa pitää suljettuina tuon tunnelin ulkopuolisen ikkunan ajan; se on ainoa jakso, jolloin paikallinen liikenne lähtee suojaamattomana. Hallitun, aina päällä olevan laitteen tulisi käyttää omistajansa julkaisemaa menettelyä sen sijaan, että sinä poistat käytännön. Jos portaali näyttää varmennevaroituksen, pysähdy: sen hyväksyminen ohjaa istuntosi paikan sieppausvälityspalvelimen kautta, ja se välityspalvelin voi lukea kaiken, mitä lähetät. Androidissa aina päällä olevan VPN:n alla oleva lukitus estää liikenteen ennen kuin tunneli on ylhäällä, eikä jotkin koontiversiot pysty vapauttamaan portaalin virtausta; jos omasi ei pysty, käytä paikan vaihtoehtoista pääsyä tai toista laitetta sen sijaan, että jättäisit lukituksen pois päältä. Applen kysynnän mukaiset säännöt voidaan kirjoittaa hylkäämään tunneli, kunnes tunnustelu onnistuu, ja se on käyttäytyminen, jonka haluat hotelliverkoissa.

Vahvista järjestyksessä työkaluilla, jotka sinulla jo on. Ennen tunnelia suorita tunnustelu niin, että sekä otsakkeet että runko näkyvät, ja katso, saako VPN-kuljetuksesi ylipäätään mitään vastausta:

curl -sS -D - http://captive.apple.com/hotspot-detect.html -o -
sudo tcpdump -ni any 'udp port 500 or udp port 4500 or udp port 1194'

Ennen valtuutusta tavallinen portaali antaa yhden kahdesta vastauksesta: 302, jonka Location osoittaa kirjautumissivulle, tai 200, jonka HTML-runko on portaalinsivu. Kirjaa, kumman sait. Uudelleenohjaus ei ole epäonnistuminen ennen kirjautumista; se on portaali, joka kertoo sinulle, minne mennä. Kun portaali ilmoittaa onnistumisesta, toista komento ja odota 200:tä, jonka runko on kirjaimellisesti sana Success. Juuri tuo merkkijono tekee tunnustelusta mielekkään. Jos isäntä vastaa normaalisti ennen kuin koskaan kirjauduit, tässä verkossa ei ole sieppaavaa portaalia. Kaappauksessa valtuutusta edeltävä pudotus on lähteviä paketteja, joista mikään ei palaa, kun taas toimiva polku näyttää vastauksen samaan virtaan noin sekunnin kuluessa. Yhdistä ja toista sitten kaappaus.

Jos tunneli epäonnistuu edelleen, kun portaali sanoo kyllä

Sisäänkirjautumisen onnistuminen ei ole sama kuin sallittu kuljetus. Monet paikat sallivat portaalin ja tavallisen selailun mutta estävät UDP:n kokonaan, mikä jättää WireGuardin ja UDP-OpenVPN:n rikki ja TCP 443:n toimimaan. Jos TCP 443 menee läpi eikä UDP, se on paikan käytäntö eikä asiakas, jonka konfiguroit väärin, joten vaihda kuljetusta tai hyväksy raja ja jatka. Jos uudelleenyhdistäminen epäonnistuu silti, säilytä tarkka virhe; se nimeää vaiheen, johon olet juuttunut.

Muut viat asuvat laitteessa. Istunto, joka on yhä sidottu vanhaan MAC-osoitteeseen, toinen Wi-Fi-sovitin omalla vuokrallaan tai asiakas, joka on välimuistiin tallentanut portaalin varmennepoikkeuksen, voivat kukin jatkaa epäonnistumista puhtaan uudelleenvaltuutuksen jälkeen. Irrota liitos, valtuuta uudelleen ja yritä kerran ennen kuin kosket asiakkaan asetuksiin. RFC 8952 kannattaa lukea, jos haluat seuraamiesi komponenttien taustalla olevan arkkitehtuurin.

Jos portaali itse kieltäytyy valtuuttamasta, ongelma on tilissä tai laitejaossa, eikä mikään VPN-asetus korjaa sitä. VPN:n lähtömaan vaihtaminen ei nollaa paikan paikallista pääsytilaa; tuo taulukko on sidottu laitteeseesi, ei valitsemaasi palvelimeen. Kysy paikan operaattorilta ja anna sille aikaa, koska istuntotaulukko on se, mitä se katsoo.

Ennen seuraavaa matkaasi kirjoita kolme asiaa: portaalinsivu nollavaiheena, eston keskeyttämisen vaihe jokaiselle mukanasi kulkevalle laitteelle ja yksi varakuljetus, jota olet todella testannut. Kun kymmenen minuuttia sitten toiminut tunneli pysähtyy taas, käsittele sitä vanhentuneena valtuutuksena ja tarkista portaali uudelleen ennen kuin kosket VPN-profiiliin.

Aiheeseen liittyvät artikkelit