Hindi kumokonekta ang OpenVPN sa Wi-Fi ng hotel? Subukan ang TCP 443

Buksan ang client, pindutin ang Kumonekta at basahin ang linya ng estado sa halip na ang dialog na sumusunod. Ang profile na natigil sa Kumokonekta o Naghihintay ng server pagkatapos ng network ng hotel, campus o mobile ay karaniwang nawalan ng transport saanman sa daan, hindi ang mga kredensyal nito. Ang susunod na kapaki-pakinabang na hakbang ay alamin kung ano ang dinadala ng network na iyon bago hawakan ang server. Huwag baguhin ang anuman hanggang gumana ang parehong profile sa ibang lugar.

Subukan muna mula sa hotspot ng telepono. Kung tumaas ang tunnel doon, maayos ang server, sertipiko at account, at ang natitirang baryabol ay ang network sa harap mo.

Magsimula sa client: basahin ang linya ng estado

Sinasabi ng linya ng estado kung aling yugto ang nabigo. Ang client na natigil sa Kumokonekta ay nilulutas pa ang host o binubuksan ang panlabas na socket; ang umabot sa Naghihintay ng server ay may daan ngunit walang sagot; ang nagpapatunay at pagkatapos ay bumabagsak ay may ganap na ibang problema. Ang log ng client at ang sariling remote at proto na field ng profile ay nagpapakita kung ano ang sinusubukan ng client, at ang --verb 4 sa client na command-line ay naglilimbag ng parehong detalye. Ang paghahambing nito sa network sa harap mo ang siyang nagpapalit ng 'harang ang VPN' sa partikular na pag-aangkin.

Pagkatapos suriin ang network gamit ang mga kasangkapan na mayroon ka na. Ang nc -vzu 203.0.113.10 1194 ay nagpapadala ng UDP datagram, ang curl -v telnet://203.0.113.10:443 ay nag-uulat kung nakumpleto ang TCP handshake, at ang browser na naglo-load ng HTTPS page ay nagpapatunay lamang na ang palabas na 443 ay umabot sa isang host na iyon. Ang maliliit na pagsusuri ay sumasagot sa hindi kayang sagutin ng VPN client: aling port at aling protocol ang lumalabas sa network na ito.

Tatlong pag-uugali ng network ang magkatulad mula sa client at nangangailangan ng magkaibang sagot. Maaaring bukas ang palabas na 443, maaaring proxy lang ang pinapayagan, o maaaring transparent na ipasa ang 443 sa isang kahon ng inspeksiyon na hindi mabasa ang dinadala nito. Ang una ay inaayos ng pagbabago sa profile sa ibaba, ang pangalawa ng mga setting ng proxy, at ang pangatlo ay maaaring makumpleto ang handshake at pagkatapos ay natigil kapag nagpasya ang inspektor na hindi niya gusto ang stream. Ang pag-alam kung alin sa tatlo ang iyong kinakaharap ay ang pagkakaiba ng sampung minutong pagbabago at kalahating araw ng muling pag-install ng mga client.

Ilipat ang listener at profile nang sabay

Sa panig ng server, itakda ang listener sa pinapayagan ng network: port 443 at proto tcp sa configuration ng server, pagkatapos ay i-restart ang serbisyo at kumpirmahin ang socket gamit ang ss -lntp. Sa panig ng client, dapat sumang-ayon ang profile, dahil ang transport at port ay nasa labas ng tunnel: proto tcp at port 443 sa .ovpn, o ang katumbas na field sa screen ng mga setting ng app. Ang profile na nakatutok pa rin sa UDP 1194 ay nabibigo nang eksakto tulad ng dati, at nariyan ang tukso na sisihin ang firewall na naayos na. Kung ang parehong host ay sumasagot din ng HTTPS sa 443, hindi maaaring ibahagi ng dalawang listener ang address at protocol na iyon; bigyan ang VPN ng pangalawang address o maglagay ng demultiplexer sa harap.

Sundan ang unang koneksyon gamit ang tcpdump -ni any port 443 sa magkabilang dulo. Ang mga packet na umaalis sa client at hindi kailanman dumarating ay nangangahulugang nagsasala pa rin ang network, o ang address sa profile ay hindi ang inaakala mo. Ang mga packet na dumarating na walang sagot ay nagpapabalik sa iyo sa log ng server, kung saan ang hindi pagkakatugma ng protocol ay agad na lumilitaw bilang itinapong packet.

Kapag proxy lamang ang lumalabas sa network

Ang ilang guest network ay walang pinapayagan maliban sa HTTP proxy, na ibang hadlang kaysa saradong port at nagbubukod ng higit pa sa OpenVPN. Ang mga client na nagsasalita lamang ng PPTP, L2TP/IPsec o hubad na IPsec ay walang daan dito, dahil inaasahan ng mga disenyong iyon na ang panlabas na protocol nila ay direktang umabot sa server. Kaya ng OpenVPN, gamit ang http-proxy proxy.example.net 8080 sa profile ng client, basta pinapayagan ng proxy ang CONNECT method sa iyong port. Ang SOCKS proxy ay mas madali pa, dahil ipinapasa nito ang stream nang walang pakialam sa nilalaman.

Kung saan walang suporta sa proxy ang client, ang SSH tunnel sa 443 ang karaniwang natitira. Nagdaragdag ito ng pangalawang layer, at maaaring may opinyon ang operator ng network tungkol dito, kaya ituring itong tulay para sa isang paglalakbay at hindi bilang arkitektura.

Presyuhan ang fallback bago mo ito panatilihin

Ang TCP sa loob ng TCP ay may kilalang halaga. Kapag ang panlabas na koneksyon ay TCP at TCP din ang payload, ang nawalang segment ay nagdudulot ng retransmission sa parehong layer, at ang panloob na koneksyon ay umuurong mula sa pagkalugi na hindi nito nakikita. Nakakayanan ito ng pagba-browse; nararamdaman ito ng interactive na session at tawag. Panatilihin ang TCP 443 listener bilang fallback para sa mga network na nangangailangan nito, at hayaang UDP ang default para sa lahat ng pinapayagan pa rin ito.

Itala ang pinili sa pangalan ng profile at sa mga tala ng suporta: aling port, aling protocol at aling network ang nagdulot nito. Pagkatapos ay tanungin ang administrator ng network kung mananatiling bukas ang port na iyon pagkatapos ng susunod na pagpapalit ng kagamitan, dahil ang fallback na tahimik na nawawala ay mas masama kaysa walang fallback.