Hotela Wi-Fi: la VPN malsukcesas antaŭ ol ĝi atingas la servilon

La VPN-kliento turniĝas, poste raportas ke ĝi ne povas atingi la servilon, kaj ĉiuj konkludas ke la hotelo blokas VPN-ojn. Kutime nenio tiom drama okazis: la reto ankoraŭ ne lasis vin eliri. Kapta portalo tenas ĉiun konekton ĝis vi ensalutos, kaj tunelo ne povas kompletiĝi dum ensaluta paĝo interkaptas ĝiajn pakaĵojn. Trapasu la ensaluton antaŭ ol kulpigi la tunelon.

La mito: la hotelo blokas VPN-ojn

Plej multaj hotelaj retoj ne filtras tunelojn speciale. Ili interkaptas retan trafikon ĝis la gasto aŭtentikiĝas, kaj ili ankaŭ povas limigi aparatojn, eksvalidigi sesiojn aŭ malrapidigi trapon. Ĉiu el tiuj produktas fiaskon, kiu de interne de VPN-kliento aspektas kiel blokado.

La tunelo estas ĉi tie malbona diagnoza ilo, ĉar ĝi estas la sola aplikaĵo garantiite fiaskanta dum la portalo ne estas rajtigita. Ordinara reta aliro estas la pli bona indikilo, ĉar ĝi povas montri al vi la ensalutan paĝon mem.

Tiu ordo gravas pro alia kialo: kliento kun sekura ŝaltilo aŭ ĉiam-aktiva reĝimo rifuzos ŝargi la portalon, kaj la uzanto konkludos ke la reto rompiĝis, ne la agordo. Ambaŭ faktoj veras samtempe, kaj nur unu el ili povas ŝanĝiĝi en la hotelo. Malŝaltu la protekton per la propra regilo de la kliento, ensalutu, kaj reŝaltu ĝin. Io ajn alia estas flankvojo, kiu kaŝas la veran sinsekvon.

Unue finu la portalon, poste testu ordinaran HTTPS

Demandu la personaron pri la oficiala retnomo kaj la ensaluta metodo. Konvinka SSID ne estas pruvo de posedo, kaj dua reto kun simila nomo estas ordinara trompo en publikaj lokoj. Uzu la propran ensalutan inviton de la operaciumo kie ĝi proponiĝas, aŭ la dokumentitan paĝon de la hotelo.

curl -sS -o /dev/null -w '%{http_code} %{redirect_url}\n' http://captive.apple.com/hotspot-detect.html
curl -sS -o /dev/null -w '%{http_code}\n' https://www.example.com/

La unua peto demandas konatan finpunkton por detekti kaptan portalon per simpla HTTP; alidirekto aŭ neatendita korpo signifas ke vi ankoraŭ estas malantaŭ la portalo. La dua testas normalan HTTPS-ejon. Se la unua montras interkapton kaj la dua fiaskas, la ensaluto ne kompletiĝis kaj la VPN havas nenion komunan kun tio.

Sur persona aparato eble necesas malŝalti la sekuran ŝaltilon aŭ la ĉiaman VPN per la subtenata regilo de la kliento, por ke la portalo povu ŝargiĝi. Fermu sentemajn aplikaĵojn dum tiu periodo kaj tuj poste reŝaltu la protekton. Sur administrata aparato uzu la proceduron aprobitan de la administranto anstataŭ mem forigi regularon.

Neniam preteriru atestilan averton kaj neniam instalun nekonatan atestilon aŭ helpan aplikaĵon por ekiri rete. Se la portalo postulas ion neatenditan, konfirmu ĝin kun la personaro, kaj kun la administranto se la aparato apartenas al dunganto.

Konservu la originalan profilon kaj ĝian eraron

Post kiam ordinara aliro funkcias, konektu la originalan profilon kaj notu la precizan eraron. Aŭtentika rifuzo estas konta problemo, tempolimo dum intertraktado estas voja problemo, kaj tunelo kiu konfirmiĝas sed portas nenion estas problema de enkursigo aŭ regularo.

Tiuj tri bezonas malsamajn sekvajn paŝojn, kaj ekrankopio de la eraro valoras pli ol priskribo. Notu ankaŭ la horon, ĉar hotelaj sesiolimoj povas eksvalidiĝi ene de horo kaj produkti fiaskon kiu ŝajnas hazarda. Se la kliento proponas protokolon, konservu la sekcion ĉirkaŭ la unua fiasko anstataŭ la tutan dosieron. Tiu eltiraĵo kutime sufiĉas al la posedanto de la profilo por identigi la etapon.

Se ordinara aliro funkcias kaj la intertraktado ankoraŭ limtempas, demandu la hotelon ĉu ĝi subtenas tiun trafikon, kaj komparu kun fidinda alirpunkto tenante la aparaton kaj la profilon senŝanĝaj. Labori ĉe la alirpunkto mallarĝigas la atenton al la hotela vojo sen pruvi ion pri la profilo.

Uzu nur la alternativojn kiujn la operatoro provizas

Taŭga TCP-profilo povas sukcesi tie, kie la proponita UDP-vojo ne funkcias, sed nur se la servilo vere aŭskultas sur tiu transporto kaj pordo. TCP-pordo 443 ne estas aŭtomate traktata kiel ordinara HTTPS, kaj ĝi ne garantias trapason tra restrikta reto.

sudo openvpn --config /etc/openvpn/client/office-tcp.conf --verb 4

Ruli la provizitan profilon kun pli alta detalo tenas la unuan utilan eraron videbla anstataŭ kunpremi ĝin en ĝeneralan fiaskan dialogon. Uzu la dosieron kiun la operatoro donis anstataŭ mem redakti pordojn aŭ protokolojn, ĉar loka ŝanĝo ne povas krei taŭgan aŭskultanton ĉe la alia flanko.

Se la tunelo ripete restartiĝas, notu ĉu la portalo reaperas aŭ la loka signalo falas, kaj sekvu la stabileckontrolojn anstataŭ ŝalti plurajn protokolojn samtempe. Poste testu la aplikaĵon kiun vi vere bezonas kaj restarigu la normalajn privatecajn regilojn. Konekto kiu portas unu retejon sed ne alian estas demando de enkursigo aŭ regularo, ne de portalo.

Fine, kontrolu reakiron post kiam la tekokomputilo dormas. La rajtigo de la portalo povas eksvalidiĝi sendepende de la tunelo, do aparato kiu aŭtomate rekonektiĝas povas reveni al reto kiu jam forgesis ĝin. Remalfermi la portalpaĝon estas normala paŝo, ne signo ke la VPN rompiĝis.