VPN au proksi: kila moja hufunika nini na kisichofunika

VPN na proksi ya mbele zote hubadilisha anwani ambayo tovuti inaona, na hapo ndipo ulinganisho mwingi huishia. Tofauti inayoamua usanidi wako ni ufunikaji: proksi ya mbele ni mpatanishi ambao programu yako yenyewe huchagua kutumia, tofauti na proksi ya nyuma inayosimama mbele ya tovuti, ilhali VPN huhamisha kila kitu ambacho mfumo wa uendeshaji unaelekeza kwenye handaki. Usimbaji fiche, utunzaji wa DNS na tabia wakati wa hitilafu vyote vinatokana na mgawanyo huo. Fanya ukaguzi huu watano kwa mpangilio, na wa kwanza kushindwa utakuambia ni chombo gani unachohitaji kwa kweli.

Mpatanishi hufunika programu gani?

Kiendelezi cha proksi kwenye kivinjari hutumika tu kwa wasifu huo wa kivinjari. Wateja wa barua pepe, wasimamizi wa vifurushi na kivinjari cha pili huendelea kutumia mipangilio yao wenyewe, na programu zingine hupuuza kabisa vigeu vya proksi vya mfumo. VPN hufunika kile ambacho jedwali la uelekezaji hutuma kwenye handaki, na hiyo inaweza kuwa programu zote au kikundi kidogo kwenye handaki iliyogawanywa kulingana na njia na sera ya mteja.

Jaribu programu ambazo ni muhimu badala ya kukisia kutokana na upakiaji mmoja wa ukurasa. curl https://ifconfig.me hufuata vigeu vya proksi vya mazingira; programu ya mezani inaweza isifuate. Kwenye Windows, netsh winhttp show proxy huchapisha proksi ya WinHTTP ambayo huduma hutumia, na huo ni mpangilio tofauti na ule wa kivinjari.

Je, hatua imesimbwa fiche, na TLS huisha wapi?

Itifaki ya proksi ni mahali pa kukutania, si uhakika. SOCKS5 hupeleka TCP bila kuisimba fiche, na proksi ya kawaida ya HTTP hubeba mstari wa ombi na vichwa kama maandishi wazi. HTTPS kupitia proksi hutumia CONNECT, kwa hiyo kipindi chako cha TLS bado huisha kwenye lengo, si kwenye proksi. Mwongozo wa MDN kuhusu seva za proksi na uvunguaji unaeleza tofauti hiyo kutoka upande wa itifaki.

VPN husimba fiche sehemu kati ya kifaa chako na sehemu yake ya mwisho. Zaidi ya sehemu ya mwisho kanuni zile zile hutumika kama kwenye mtandao mwingine wowote, ndiyo sababu handaki peke yake hailindi programu inayotuma vitambulisho kupitia HTTP ya kawaida. Hakuna moja ya miundo hiyo miwili inayoficha akaunti iliyoingia, kuki au alama ya vidole ya kivinjari.

curl -v -x http://127.0.0.1:3128 https://example.com/ -o /dev/null
curl -v -x socks5h://127.0.0.1:1080 https://example.com/ -o /dev/null

Matokeo ya kina yanaonyesha kama curl ilituma CONNECT kwenye bandari 443 au GET ya kawaida na URL kamili. Kwa socks5h:// jina la mwenyeji hupewa proksi ndani ya ombi la SOCKS5 kisha husambaza TLS ambayo haiwezi kuisoma, kwa hiyo huona jina na hesabu ya baiti. Kupitia proksi ya http://, URL ya https:// ni CONNECT, kwa hiyo proksi hiyo pia huona jina na ukubwa wa lengo, lakini si ombi au mwili wa jibu.

Ni kisuluhishi kipi kinaona jina?

Utatuzi wa majina unaweza kutokea ndani kabla ombi halijatoka, au kwa mbali kwenye proksi. Kwa curl, socks5h:// hutuma jina la mwenyeji kwa proksi ilhali socks5:// hulitatua ndani kwanza. Mipangilio ya proksi ya kivinjari hutoa chaguo la DNS linalolingana, na faili za PAC zinaweza kuelekeza wenyeji tofauti kwa njia tofauti.

Itifaki mbili zinaweza kukwepa proksi bila usanidi wowote mbaya. WebRTC hukusanya wagombea kupitia STUN, na QUIC huendesha HTTP/3 juu ya UDP, ambayo proksi ya TCP haiwezi kuibeba. Kivinjari kitarudi kwenye TCP ikiwa UDP 443 imezuiwa, kwa hiyo kuzuia UDP 443 kwenye ngome ya moto ya mwenyeji (au kwenye rauta kwa mtandao mzima), na si bendera ya kivinjari, ndiyo njia ya kuaminika ya kuweka HTTP/3 kwenye njia ya proksi.

Kagua kisuluhishi kwa mtazamo wa lengo, si wa kompyuta yako ya mkononi. Ombi linalofika na anwani ya kutoka ya proksi lakini jina lililotatuliwa ndani bado huiambia kisuluhishi cha ndani ni tovuti gani unazotembelea.

Nini hutokea mpatanishi anaposhindwa?

Proksi dhahiri hushindwa ikiwa imefungwa: simamisha mchakato wa proksi na kivinjari au programu hurudisha hitilafu ya muunganisho badala ya kwenda moja kwa moja. Mipangilio ya PAC na WPAD ndiyo inayoshindwa ikiwa wazi - ikiwa hati haiwezi kupatikana, mteja hurudi kwenye DIRECT na tovuti inaona anwani yako halisi tena. VPN inaweza kushindwa ikiwa wazi au imefungwa kulingana na mteja na kama swichi ya kuzima au kanuni ya ngome ya moto iko hai.

Jaribu kisa cha hitilafu kwa makusudi: simamisha huduma ya proksi na upakie upya; ukipata ukurasa wa hitilafu badala ya upakiaji wa moja kwa moja, elekeza URL ya PAC kwenye mwenyeji usioweza kufikiwa ili uone njia mbadala. Ikiwa ukurasa bado unapakiwa kupitia njia yako ya kawaida, proksi haitoi ulinzi wowote dhidi ya usumbufu wake yenyewe, na hiyo ni sifa unayopaswa kuijua kabla ya kuitegemea.

Mpangilio huamua kile tovuti inachokiona. Proksi ambayo trafiki yake ya kutoka hupita kupitia VPN huiacha tovuti ikiona anwani ya sehemu ya mwisho ya VPN; weka proksi nje ya handaki (VPN kwa proksi kwenye mwenyeji wa mbali) na tovuti itaona anwani ya kutoka ya proksi hiyo badala yake. Kwa vyovyote vile, hatua mbili zinaweza kurekodi mambo tofauti.

Ukaguzi watano, kwa mpangilio

Orodha ya ukaguzi iliyo hapa chini ni uamuzi wote mahali pamoja. Ufunikaji huja kwanza kwa sababu huondoa mengi ya kutokubaliana: ikiwa programu inayopaswa kufunikwa haiheshimu mpangilio, hakuna chochote zaidi kwenye orodha kitaiokoa.

Kisha thibitisha matokeo na programu iliyosababisha mabadiliko. Pakia ukurasa kwenye kivinjari kilichosanidiwa, pata ukurasa huo huo kwa curl, na linganisha anwani ambayo kila moja huripoti. Ikiwa hazikubaliani, kiendelezi, kanuni ya PAC au ubatilishaji wa kiwango cha programu bado kinafanya kazi, na marekebisho yoyote ya handaki hayatarekebisha.

Andika ulichosanidi: ni programu gani zinazotumia proksi, DNS ni ya ndani au ya mbali, UDP imezuiwa au la, na tabia wakati wa hitilafu ni ipi. Orodha hiyo ndogo ndiyo inayowezesha ulinganisho unaofuata, kwa sababu “IP ilibadilika” haikuwahi kukuambia ni ukaguzi upi kati ya hawa watano ulifanikiwa.