OpenVPN haiunganishi kwenye Wi-Fi ya hoteli? Jaribu TCP 443

Fungua mteja, bonyeza Ungana na usome mstari wa hali badala ya kidirisha kinachofuata. Wasifu unaokwama kwenye Inaunganisha au Inasubiri seva baada ya mtandao wa hoteli, chuo au simu kwa kawaida umepoteza usafirishaji wake mahali fulani njiani, si vitambulisho vyake. Hatua inayofuata yenye manufaa ni kujua mtandao huo unabeba nini kabla ya kugusa seva. Usibadilishe kitu chochote hadi wasifu huo huo ufanye kazi mahali pengine.

Jaribu kwanza kutoka kwenye hotspot ya simu. Ikiwa handaki itainuka hapo, seva, cheti na akaunti zote ziko sawa, na kigezo kimoja kilichobaki ni mtandao ulio mbele yako.

Anza kwa mteja: soma mstari wa hali

Mstari wa hali unakuambia hatua gani ilishindwa. Mteja aliyekwama kwenye Inaunganisha bado anatafuta jina la mwenyeji au anafungua soketi ya nje; yule anayefikia Inasubiri seva ana njia lakini hana jibu; yule anayejithibitisha kisha kuanguka ana tatizo tofauti kabisa. Kumbukumbu ya mteja na sehemu remote na proto za wasifu wenyewe zinaonyesha mteja anajaribu kufanya nini, na --verb 4 kwenye mteja wa mstari wa amri huchapisha maelezo yale yale. Kulinganisha hayo na mtandao ulio mbele yako ndiko kunabadilisha 'VPN imezuiwa' kuwa dai mahususi.

Kisha chunguza mtandao kwa zana ulizonazo tayari. nc -vzu 203.0.113.10 1194 hutuma datagram ya UDP, curl -v telnet://203.0.113.10:443 huripoti kama usalimiano wa TCP unakamilika, na kivinjari kinachopakia ukurasa wa HTTPS kinathibitisha tu kwamba kutoka 443 kunafikia mwenyeji huyo mmoja. Uchunguzi mdogo hujibu kile mteja wa VPN hawezi: bandari gani na itifaki gani zinaondoka kwenye mtandao huu kabisa.

Tabia tatu za mtandao zinaonekana sawa kutoka kwa mteja na zinahitaji majibu tofauti. Kutoka 443 kunaweza kuwa wazi, proksi pekee inaweza kuruhusiwa, au 443 inaweza kupelekwa kwa uwazi hadi sanduku la ukaguzi ambalo haliwezi kusoma linachobeba. La kwanza linarekebishwa na mabadiliko ya wasifu hapa chini, la pili na mipangilio ya proksi, na la tatu linaweza kukamilisha usalimiano kisha likakwama mkaguzi anapoamua kuwa hapendi mtiririko. Kujua ni ipi kati ya tatu unayokabiliana nayo ni tofauti kati ya mabadiliko ya dakika kumi na mchana mzima wa kusakinisha upya wateja.

Hamisha kisikilizaji na wasifu pamoja

Upande wa seva, weka kisikilizaji kwenye kile mtandao unaruhusu: port 443 na proto tcp katika usanidi wa seva, kisha anzisha tena huduma na uthibitishe soketi kwa ss -lntp. Upande wa mteja, wasifu lazima ukubali, kwa sababu usafirishaji na bandari ziko nje ya handaki: proto tcp na port 443 ndani ya .ovpn, au sehemu zinazolingana kwenye skrini ya mipangilio ya programu. Wasifu unaoelekea bado UDP 1194 hushindwa sawa na awali, na jaribu la kulaumu firewall iliyorekebishwa tayari huja. Ikiwa mwenyeji huyo hujibu pia HTTPS kwenye 443, visikilizaji viwili haviwezi kushiriki anwani na itifaki hiyo; ipe VPN anwani ya pili au weka kigawanyaji mbele.

Fuatilia muunganisho wa kwanza kwa tcpdump -ni any port 443 pande zote mbili. Pakiti zinazoondoka kwa mteja na kutofika kamwe zinamaanisha mtandao unachuja hata hivyo, au anwani iliyo kwenye wasifu si ile unayodhani. Pakiti zinazofika bila jibu zinakurudisha kwenye kumbukumbu ya seva, ambapo kutokulingana kwa itifaki huonekana mara moja kama pakiti iliyotupwa.

Wakati proksi pekee inatoka kwenye mtandao

Mitandao mingine ya wageni hairuhusu chochote isipokuwa proksi ya HTTP, ambayo ni kikwazo tofauti na bandari iliyofungwa na huondoa zaidi ya OpenVPN. Wateja wanaozungumza PPTP, L2TP/IPsec au IPsec pekee hawana njia ya kupita humo, kwa sababu miundo hiyo inatarajia itifaki yao ya nje kufikia seva moja kwa moja. OpenVPN inaweza, ikiwa na http-proxy proxy.example.net 8080 kwenye wasifu wa mteja, mradi proksi inaruhusu mbinu ya CONNECT hadi bandari yako. Proksi ya SOCKS ni rahisi zaidi, kwa sababu hupeleka mtiririko bila kujali kilicho ndani.

Mahali ambapo mteja hana msaada wa proksi, handaki ya SSH juu ya 443 kwa kawaida hubaki. Inaongeza tabaka la pili, na mwendeshaji wa mtandao anaweza kuwa na maoni kuhusu hilo, kwa hiyo ichukulie kama daraja la safari moja na si kama usanifu.

Pima gharama ya njia mbadala kabla ya kuihifadhi

TCP ndani ya TCP ina gharama inayojulikana. Wakati muunganisho wa nje ni TCP na mzigo pia ni TCP, sehemu iliyopotea husababisha utumaji upya katika tabaka zote mbili, na muunganisho wa ndani unarudi nyuma kutokana na hasara isiyoweza kuiona. Kuvinjari huvumilia hilo; vikao vya mwingiliano na simu huhisi. Hifadhi kisikilizaji cha TCP 443 kama njia mbadala kwa mitandao inayohitaji, na uache UDP kuwa chaguo-msingi kwa kila kitu kinachoiruhusu bado.

Rekodi chaguo kwenye jina la wasifu na kwenye maelezo ya msaada: bandari gani, itifaki gani na mtandao gani uliisababisha. Kisha muulize msimamizi wa mtandao ikiwa bandari hiyo itabaki wazi baada ya ubadilishaji wa vifaa ujao, kwa sababu njia mbadala inayotoweka kimya ni mbaya kuliko kukosa njia mbadala kabisa.