Kial hotspot alidirektas DNS antaŭ ol la VPN konektiĝas?

Aliĝi al hotelreto metas du DNS-decidojn antaŭ vi en malsamaj momentoj: la serĉoj, kiujn la aparato faras dum ensaluto, kaj la serĉoj farataj post kiam la tunelo staras. Hotspot povas influi la unuajn per la reto, kiun ĝi regas. La duaj dependas de la politiko de la kliento mem, kio estas aparta afero por kontroli.

Trairu la konekton laŭorde, de la unua DHCP-luo ĝis la demando, kiu solvis privatan nomon. Tiam du fiaskoj, kiuj en subtena bileto aspektas identaj, apartiĝas klare: unu okazis antaŭ ol ekzistis la tunelo, la alia okazis ene de ĝi.

Kion hotspot povas kaj ne povas tuŝi

La alira reto disdonas solvilan adreson per DHCP kaj povas interkapti pordon 53 direkte al tiu adreso. Tio sufiĉas por respondi al ĉiu neprotektita serĉo per portala adreso aŭ blokada paĝo. Ĝi ankaŭ sufiĉas por rompi VPN-klienton, kies finpunkto estas skribita kiel hostnomo.

Kion hotspot ne povas, estas legi aŭ reverki demandon, post kiam ĝi veturas ene de starigita tunelo, supozante, ke la tunelo vere portas ĝin. Interkapto dependas de vidi la demandon en klarteksto.

Demandoj tamen forlasas la tunnelon pro kialoj ne ligitaj al hotspot: la sekura DNS-agordo de la retumilo, split-DNS-regulo, kiu tenas firmaan sufikson ĉe la loka solvilo, aŭ kliento agordita por ekskludi DNS el la tunelo. Ĉiu el ili estas elekto ĉe la klienta flanko, kaj ĉiu aspektas kiel hotspot-interfero, kiam oni rigardas de ekstere.

La komenca serĉo okazas antaŭ ol ekzistas la tunelo

Kliento, al kiu oni donas hostnomon, devas unue solvi ĝin, kaj en tiu momento neniu tunelo protektas la demandon. Se hotspot respondas per portala adreso, la intertraktado fiaskas aŭ haltas. Se ĝi respondas per nenio, la kliento raportas nomeraron kaj la tunelo neniam ekfunkcias. Ĉiu el la du rezultoj klarigas malplenan tunelan protokolon, kiu alie aspektas senkulpa.

Operaciumoj ankaŭ plenumas proprajn konektotestojn kaj portalotrovojn, priskribitajn en RFC 8910 kaj RFC 8952, kaj tiuj petoj foriras antaŭ ol iu ajn VPN staras. Vidi ilin en prokura protokolo estas atendata konduto, ne pruvo de liko.

La praktika solvo estas doni al la kliento finpunkton, kiu bezonas neniun serĉon. Kiam tio neeblas, finu la ensaluton unue kaj konektu poste.

Eltrovu, kiu solvilo respondis

Demandu la sistemon anstataŭ la retumilon, kaj rulu la demandon dufoje: unufoje per kiu ajn solvilo la aparato nun uzas, unufoje kontraŭ fiksa adreso.

resolvectl query vpn.example.com
dig +short vpn.example.com
dig +short vpn.example.com @1.1.1.1

Respondo el la unua komando, kiu diferencas de la tria, diras al vi, ke la loka solvilo redonas ion alian, kion ĝuste faras alidirekta hotspot. Fiasko el la tria kune kun sukceso el la unua montras al la portalo: la loka solvilo servis ensalutan adreson, dum la elira pordo 53 estis forĵetita. Tempolimoj ĉe ambaŭ signifas, ke la reto forĵetas DNS ĝis la aŭtentigo finiĝos.

Ripetu post konekto kaj komparu. Kaŝmemorita respondo postvivas la transiron, do malplenigu la kaŝmemoron aŭ demandu novan nomon por la dua observado.

Tenadu pli postajn serĉojn sur la vojo, kiun vi intencis

Plentunela profilo, kiu ankaŭ kaptas DNS, estas la plej simpla aranĝo: ĉiu demando de ĉiu aplikaĵo iras al la solvilo, kiun la tunelo puŝas, kaj la loka reto vidas nur ĉifritan trafikon. Pruvu ĝin per solvo de interna kaj publika nomoj post la konekto, kaj poste komparu ambaŭ respondojn kun tio, kion la solvilo de la tunelo redonas sola.

Split-DNS bezonas domajnliston skribitan kun intenco: firmaaj sufiksoj tra la tunelo, ĉio alia loke, kaj neniu interkovro inter la du.

Sekura DNS de la retumilo staras ekster tiu politiko, do se ĝi devas esti malŝaltita, por ke la profilo kondutu antaŭvideble, malŝaltu ĝin por tiu profilo, ne por la maŝino. Faru tion en la retumilaj agordoj, ne per redaktado de la sistema solvilo, por ke la ŝanĝo estu videbla venontfoje. Notu la respondon, la solvilon kaj la konektan etapon en unu linio por ĉiu testo. Raporto, kiu diras, ke DNS fiaskis en hotela Wi-Fi, priskribas simptomon kun almenaŭ tri malsamaj kaŭzoj.