Miksi hotspot uudelleenohjaa DNS:n ennen kuin VPN yhdistää?
Hotspot kirjoittaa haut uudelleen omassa verkossaan, ja isäntänimen päätepiste ratkaistaan ennen kuin mitään tunnelia on olemassa. Seuraa, mikä ratkaisija vastasi mihinkin kyselyyn.
Hotelliverkkoon liittyminen asettaa eteesi kaksi DNS-päätöstä eri hetkinä: haut, jotka laite tekee kirjautumisen aikana, ja haut, jotka tehdään tunnelin pystyttämisen jälkeen. Hotspot voi vaikuttaa ensimmäisiin hallitsemansa verkon kautta. Toiset riippuvat asiakkaan omasta käytännöstä, mikä on erikseen tutkittava asia.
Käy yhteys läpi järjestyksessä ensimmäisestä DHCP-vuokrauksesta kyselyyn, joka ratkaisi yksityisen nimen. Silloin kaksi tukipyynnössä samalta näyttävää vikaa erottuvat puhtaasti: toinen tapahtui ennen tunnelin olemassaoloa ja toinen sen sisällä.
Mihin hotspot voi ja mihin se ei voi koskea
Käyttöverkkö jakaa ratkaisijan osoitteen DHCP:ssä ja voi siepata portin 53 kyseiseen osoitteeseen. Se riittää vastaamaan jokaiseen suojaamattomaan hakuun portaalin osoitteella tai estosivulla. Se riittää myös rikkomaan VPN-asiakkaan, jonka päätepiste on kirjoitettu isäntänimenä.
Sen hotspot ei voi tehdä, on lukea tai kirjoittaa uudelleen kyselyä, kun se kulkee jo muodostetun tunnelin sisällä, olettaen että tunneli todella kuljettaa sen. Sieppaus edellyttää kysymyksen näkemistä selkokielisenä.
Kyselyt lähtevät tunnelista joka tapauksessa syistä, joilla ei ole tekemistä hotspotin kanssa: selaimen suojatun DNS:n asetus, split-DNS-sääntö, joka pitää yrityksen jälkiliitteen paikallisella ratkaisijalla, tai asiakas, joka on määritetty jättämään DNS tunnelin ulkopuolelle. Jokainen on asiakaspuolen valinta, ja jokainen näyttää ulkopuolelta hotspotin häirinnältä.
| Path | Who answers | What a failure looks like |
|---|---|---|
| Lookup before the tunnel is up | The network's resolver | The client never reaches its endpoint |
| Lookup inside the tunnel | The resolver pushed by the client | Local policy or tunnel DNS is misconfigured |
| Browser secure DNS | A DoH provider over port 443 | Both the hotspot and the tunnel policy are bypassed |
Alkuhaku tapahtuu ennen kuin tunnelia on olemassa
Asiakkaan, jolle annetaan isäntänimi, on ensin ratkaistava se, eikä tuolla hetkellä mikään tunneli suojaa kyselyä. Jos hotspot vastaa portaalin osoitteella, neuvottelu epäonnistuu tai jää jumiin. Jos se ei vastaa millään, asiakas ilmoittaa nimivirheen eikä tunneli koskaan käynnisty. Kumpi tahansa tulos selittää tyhjän tunnelilokin, joka muuten näyttää viattomalta.
Käyttöjärjestelmät tekevät myös omat yhteydentarkistuksensa ja portaalin etsintänsä, joita kuvataan dokumenteissa RFC 8910 ja RFC 8952, ja nuo pyynnöt lähtevät ennen kuin mikään VPN on pystyssä. Niiden näkeminen välityspalvelimen lokissa on odotettua käytöstä eikä todiste vuodosta.
Käytännön korjaus on antaa asiakkaalle päätepiste, joka ei tarvitse hakua. Kun se on mahdotonta, viimeistele kirjautuminen ensin ja yhdistä sen jälkeen.
Selvitä, mikä ratkaisija vastasi
Kysy järjestelmältä äläkä selaimelta, ja aja kysely kahdesti: kerran sen ratkaisijan kautta, jota laite parhaillaan käyttää, ja kerran kiinteää osoitetta vastaan.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
Ensimmäisen komennon vastaus, joka eroaa kolmannesta, kertoo, että paikallinen ratkaisija palauttaa jotain muuta, mitä uudelleenohjaava hotspot juuri tekee. Kolmannen epäonnistuminen yhdessä ensimmäisen onnistumisen kanssa viittaa portaaliin: paikallinen ratkaisija tarjosi kirjautumisosoitteen, kun lähtevä portti 53 pudotettiin. Aikakatkaisut molemmissa tarkoittavat, että verkko hylkää DNS:n, kunnes todennus valmistuu.
Toista yhdistämisen jälkeen ja vertaa. Välimuistiin tallennettu vastaus säilyy siirtymän yli, joten tyhjennä välimuisti tai kysy uusi nimi toista havaintoa varten.
Pidä myöhemmät haut aiotulla polulla
Koko tunnelin profiili, joka kaappaa myös DNS:n, on yksinkertaisin järjestely: jokaisen sovelluksen jokainen kysely menee ratkaisijalle, jonka tunneli työntää, ja paikallinen verkko näkee vain salattua liikennettä. Todista se ratkaisemalla yhdistämisen jälkeen sisäinen ja julkinen nimi ja vertaamalla sitten molempia vastauksia siihen, mitä tunnelin ratkaisija yksin palauttaa.
Split-DNS tarvitsee tarkoituksella kirjoitetun verkkotunnusluettelon: yrityksen jälkiliitteet tunnelin kautta, kaikki muu paikallisesti, eikä näiden kahden välillä päällekkäisyyttä.
Selaimen suojattu DNS on tuon käytännön ulkopuolella, joten jos sen on oltava pois päältä, jotta profiili käyttäytyy ennustettavasti, poista se käytöstä kyseiselle profiilille äläkä koneelle. Tee se selaimen asetuksissa, älä muokkaamalla järjestelmän ratkaisijaa, jotta muutos näkyy seuraavalla kerralla. Kirjaa vastaus, ratkaisija ja yhteyden vaihe yhdelle riville testiä kohden. Raportti, joka sanoo DNS:n epäonnistuneen hotellin Wi-Fi-verkossa, kuvaa oireen, jolla on ainakin kolme eri syytä.