Bakit gumagana ang isang OpenVPN profile sa bahay pero nabibigo sa hotel

Ang Wi-Fi ng opisina at isang kuwarto sa hotel ay maaaring magbigay sa iisang laptop ng dalawang lubos na magkaibang network, at ang profile sa gitna ay walang alam tungkol dito. Ang gumagana sa bahay ay ipinapalagay ang isang mapagparayang uplink, gumaganang resolusyon ng pangalan at isang lokal na subnet na hindi bumabangga sa anumang dinadala ng tunnel. Bawat isa sa mga palagay na ito ay maaaring mabigo nang hiwalay.

Ang kapaki-pakinabang na paraan upang i-debug ito ay tratuhin ang network bilang apat na hiwalay na katotohanan, pagkatapos ay subukan ang mga ito nang sunud-sunod. Ang manghula sa profile muna ay karaniwang gumagawa ng pagbabagong walang inaayos at nagtatakip sa ebidensya.

Apat na katotohanan ng network ang nagbabago sa bawat lokasyon

Ang unang katotohanan ay kung hinahayaan ka ng lokal na network na lumabas. Ang captive portal ay tumatanggap ng device sa isang login page at hinaharangan ang lahat ng iba pa hanggang makumpleto ang pahinang iyon, ibig sabihin ay hindi makapagsimula ang tunnel, gaano man katama ang profile.

Ang pangalawa ay resolusyon ng pangalan. Ang portal na humaharang sa DNS ay sumasagot sa bawat query gamit ang sarili nitong address, kaya ang hostname ng VPN ay nireresolba sa portal at sinisikap ng client na magtayo ng tunnel papunta sa isang web page.

Ang pangatlo ay pag-filter ng transport. Ang mga network na gustong payagan lamang ang pag-browse ay nagpapadaan ng TCP 443 sa kahit anong destinasyon at itinatapon ang halos lahat ng iba pa, kasama ang UDP.

Ang pang-apat ay pag-address. Ang lokal na subnet ay maaaring sumapaw sa isang network sa likod ng tunnel, o maaaring walang ibigay ang uplink na anumang magagamit na IPv4 path.

Resolusyon ng pangalan at ang captive portal

Palitan ang hostname sa profile ng numeric na address ng server at subukan muli. Kung kumokonekta ang IP at hindi ang pangalan, ang resolusyon ang may kasalanan, at maayos ang profile mismo.

Magbukas ng browser at subukan ang isang ordinaryong HTTP page bago hawakan ang VPN. Ang pag-redirect sa isang login page ay nangangahulugang nakabinbin pa ang portal; kumpletuhin ito, pagkatapos ay kumonekta muli. Maraming hotel ang nagpapaso rin ng session pagkalipas ng ilang oras, na mukhang pagkakadiskonekta sa kalagitnaan ng araw kaysa problema sa pag-login.

Kung nabigo rin ang numeric na address, hindi ang resolusyon ang paliwanag, kaya lumipat sa transport. Itago ang address na sinubukan mo, dahil sinasabi nito sa susunod na pagsusuri kung umalis man ang mga packet sa makina.

Pag-filter ng transport: UDP muna, TCP 443 bilang reserba

Ang daloy ng OpenVPN sa UDP 1194 ay hindi mukhang anumang kinikilala ng firewall ng hotel, kaya itinatapon ito nang walang error. Sinusubukan muli ng client hanggang mag-expire ang timeout nito, at nakikita ng user ang isang koneksyong hindi kailanman nabubuo kaysa pagtanggi. Ang mga firewall na ganoon ang ugali ay bihirang itala ang pagtatapon sa kahit saang lugar na makikita mo. Ang kawalan ng pagtanggi mismo ang palatandaan.

Ang TCP 443 ang maaasahang reserba dahil hindi ito maidistinguish ng network mula sa ordinaryong HTTPS. Gamitin ang TCP profile ng operator kapag mayroon, dahil kailangan ding makinig ng server sa transport at port na iyon; ang pagbabago lamang ng client ay gumagawa ng ibang uri ng kabiguan. Kung walang TCP profile, tanungin ang operator kaysa mag-imbento ng isa sa pamamagitan ng pag-edit ng port. Dapat sumang-ayon ang panig ng server, at ang hindi pagkakatugma ay mukhang problema sa firewall muli.

Asahan ang gastos sa performance. Ang TCP sa loob ng TCP ay nagpapalaki ng retransmissions sa isang link na may pagkalugi, kaya ang gumaganang TCP tunnel ay maaaring mabagal pa rin sa abalang network ng hotel. Iyon ay kapalit para sa maabot, hindi depektong dapat habulin.

Mga banggaan ng address at mga uplink na walang IPv4

Ang tunnel ay maaaring mabuo at wala pa ring madala. Kapag ang lokal na LAN at isang malayong network ay nagbabahagi ng prefix tulad ng 192.168.1.0/24, itinuturing ng client na direktang konektado ang malayong host at ipinapadala ang packet sa lokal na link kaysa sa tunnel. Ang sintomas ay isang matagumpay na koneksyon na may isang subnet na hindi maabot, na madaling mabasa nang mali bilang problema sa ruta sa panig ng server.

Ang permanenteng pagwawasto ay ilipat ang malayong LAN sa isang hindi karaniwang private range. Ang pagpili ng range na walang gumagamit sa bahay, tulad ng 10.42.0.0/24, ay pumipigil sa problema para sa bawat susunod na lokasyon kaysa isa lamang. Ang lokal na paraan ay iwasan ang hotel, hotspot o router na iyon, na hindi pagwawasto sa lahat.

Ang mga mobile uplink ay nagdaragdag ng dalawang uri. Ang carrier-grade NAT ay nangangahulugang hindi dumarating ang mga papasok na koneksyon, na mahalaga kung nagho-host ka ng server ngunit hindi para sa palabas na client. Ang APN na naka-configure na IPv6 lamang na may NAT64 translation ay maaaring magpabigo sa isang client na nagsisigi sa isang tunay na IPv4 path, at ang karaniwang lunas ay baguhin ang protocol ng APN sa IPv4 o dual stack.

Mga sintomas pagkatapos na umangat ang tunnel

Ang tunnel na kumokonekta at pagkatapos ay tumatahimik ay karaniwang problema sa keepalive o MTU, hindi isang naka-block na port. Ang koneksyong bumabagsak pagkatapos ng takdang bilang ng minuto ay tumuturo sa isang keepalive o renegotiation timer. Itakda ang client na sondahin ang kapareha nito at mag-restart kapag huminto ang mga sagot, at subukan ang mas maliit na MTU ng tunnel kung pumapasa ang ping habang natigil ang malalaking transfer.

Bago ka humingi ng tulong, isulat ang tatlong bagay: ang address na sinubukan mo at kung sumagot ito, ang transport at port na ginamit mo, at ang lokal na subnet ng network na nabigo. Sama-sama, hinihiwalay nila ang resolusyon ng pangalan mula sa pag-filter ng transport at mula sa banggaan ng address, at iyon ang mga sanhi na tumatagal sa pakikipag-ugnayan sa ebidensya.