VPN neu brocsi: beth mae pob un yn ei gwmpasu a beth nad yw

Mae VPN a phroesi ymlaen yn newid y cyfeiriad y mae gwefan yn ei weld, a dyna lle mae'r rhan fwyaf o gymariaethau'n stopio. Y gwahaniaeth sy'n penderfynu eich gosodiad yw'r cwmpas: cyfryngwr yw proesi ymlaen y mae eich ap yn dewis ei ddefnyddio, yn wahanol i'r proesi cefn sy'n sefyll o flaen gwefan, tra bod VPN yn symud popeth y mae'r system weithredu'n ei lwybro i dwnnel. Mae amgryptio, trin DNS ac ymddygiad methu i gyd yn dilyn o'r rhaniad hwn. Rhedwch y pum gwiriad hyn yn eu trefn, a'r cyntaf sy'n methu fydd yn dweud pa offeryn sydd ei angen arnoch mewn gwirionedd.

Pa apiau mae'r cyfryngwr yn eu cwmpasu?

Mae estyniad proesi porwr yn berthnasol i'r proffil porwr hwnnw yn unig. Mae cleientiaid post, rheolwyr pecynnau ac ail borwr yn parhau i ddefnyddio eu gosodiadau eu hunain, ac mae rhai apiau'n anwybyddu newidynnau proesi system yn gyfan gwbl. Mae VPN yn cwmpasu'r hyn y mae'r tabl llwybro'n ei anfon i'r twnnel, a all fod pob ap neu is-set mewn twnnel hollt yn dibynnu ar lwybrau a pholisi'r cleient.

Profwch yr apiau sy'n bwysig yn lle rhagdybio o un llwythiad tudalen. Mae curl https://ifconfig.me yn dilyn newidynnau proesi'r amgylchedd; efallai na fydd ap pen-desg yn gwneud hynny. Ar Windows, mae netsh winhttp show proxy yn argraffu'r proesi WinHTTP a ddefnyddir gan wasanaethau, ac mae hwnnw'n osodiad gwahanol i un y porwr.

A yw'r naid wedi'i hamgryptio, a ble mae TLS yn gorffen?

Mannau cyfarfod yw protocol proesi, nid gwarant. Mae SOCKS5 yn anfon TCP ymlaen heb ei amgryptio, ac mae proesi HTTP plaen yn cludo'r llinell gais a'r pennawdau mewn testun clir. Mae HTTPS drwy broesi'n defnyddio CONNECT, felly mae'ch sesiwn TLS yn dal i derfynu yn y cyrchfan, nid yn y proesi. Mae canllaw MDN i weinyddion proesi a thwnelu yn disgrifio'r gwahaniaeth hwnnw o safbwynt y protocol.

Mae VPN yn amgryptio'r segment rhwng eich dyfais a'i bwynt terfyn. Y tu hwnt i'r pwynt terfyn mae'r un rheolau'n gymwys ag ar unrhyw rwydwaith arall, a dyna pam nad yw twnnel ar ei ben ei hun yn amddiffyn ap sy'n anfon manylion mewngofnodi dros HTTP plaen. Nid yw'r naill ddyluniad na'r llall yn cuddio cyfrif sydd wedi mewngofnodi, cwci na llwybr ôl bysedd porwr.

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

Mae'r allbwn manwl yn dangos a yw curl wedi anfon CONNECT i borth 443 neu GET plaen gyda URL llawn. Gyda socks5h:// rhoddir enw'r gwesteiwr i'r proesi y tu mewn i gais SOCKS5 ac yna mae'n ailgyfleu TLS na all ei ddarllen, felly dim ond yr enw a chyfrif y beitiau a wêl. Trwy broesi http://, mae URL https:// yn CONNECT, felly mae'r proesi hwnnw hefyd yn gweld enw a chyfaint y gyrchfan, nid y cais na chorff yr ymateb.

Pa ddatryswr sy'n gweld yr enw?

Gall datrysiad enwau ddigwydd yn lleol cyn i'r cais adael, neu o bell yn y proesi. Gyda curl, mae socks5h:// yn anfon enw'r gwesteiwr i'r proesi tra bod socks5:// yn ei ddatrys yn lleol yn gyntaf. Mae gosodiadau proesi'r porwr yn cynnig opsiwn DNS tebyg, a gall ffeiliau PAC lwybro gwesteiwyr gwahanol mewn ffyrdd gwahanol.

Gall dau brotocol osgoi proesi heb unrhyw gamffurfweddiad. Mae WebRTC yn casglu ymgeiswyr dros STUN, ac mae QUIC yn rhedeg HTTP/3 dros UDP, na all proesi TCP ei gludo. Bydd porwr yn dychwelyd at TCP os yw UDP 443 wedi'i rwystro, felly rhwystro UDP 443 ar wal dân y gwesteiwr (neu ar y llwybrydd ar gyfer rhwydwaith cyfan), nid baner porwr, yw'r ffordd ddibynadwy o gadw HTTP/3 o fewn llwybr y proesi.

Gwiriwch y datryswr o safbwynt y gyrchfan, nid o safbwynt eich gliniadur. Mae cais sy'n cyrraedd â chyfeiriad allanfa'r proesi ond ag enw wedi'i ddatrys yn lleol yn dal i ddweud wrth y datryswr lleol pa safleoedd rydych chi'n ymweld â nhw.

Beth sy'n digwydd pan fydd'r cyfryngwr yn methu?

Mae proesi penodol yn methu ar gau: stopiwch broses y proesi ac mae'r porwr neu'r ap yn dychwelyd gwall cysylltiad yn lle mynd yn syth. Gosodiadau PAC a WPAD yw'r rhai sy'n methu ar agor - os na ellir nôl y sgript, mae'r cleient yn dychwelyd at DIRECT ac mae'r safle'n gweld eich gwir gyfeiriad eto. Gall VPN fethu ar agor neu ar gau yn dibynnu ar y cleient ac a yw switsh brys neu reol wal dân yn weithredol.

Profwch yr achos methu yn fwriadol: stopiwch wasanaeth y proesi ac ail-lwythwch; os cewch dudalen wall yn lle llwythiad uniongyrchol, pwyntiwch URL y PAC at westeiwr na ellir ei gyrraedd i weld sut mae'n methu. Os yw'r dudalen yn dal i lwytho drwy eich llwybr arferol, nid yw'r proesi'n cynnig unrhyw amddiffyniad rhag ei ymyrraeth ei hun, ac mae hynny'n briodwedd y dylech ei gwybod cyn dibynnu arno.

Mae trefn yn penderfynu beth mae'r safle'n ei weld. Mae proesi y mae ei draffig allan yn mynd drwy'r VPN yn gadael i'r safle weld cyfeiriad pwynt terfyn y VPN; rhowch y proesi y tu allan i'r twnnel (VPN i broesi ar westeiwr pell) ac mae'r safle'n gweld cyfeiriad allanfa'r proesi hwnnw yn lle hynny. Naill ffordd na'r llall, gall y ddau naid gofnodi pethau gwahanol.

Pum gwiriad, yn eu trefn

Y rhestr wirio isod yw'r penderfyniad cyfan mewn un man. Cwmpas sy'n dod gyntaf oherwydd ei fod yn dileu'r rhan fwyaf o gamgyfatebiaethau: os nad yw'r ap y mae'n rhaid ei gwmpasu'n parchu'r gosodiad, ni fydd unrhyw beth yn ddiweddarach ar y rhestr yn ei achub.

Yna cadarnhewch y canlyniad gyda'r ap a sbardunodd y newid. Llwythwch dudalen yn y porwr sydd wedi'i ffurfweddu, nolwch yr un dudalen â curl, a chymharwch y cyfeiriad y mae pob un yn ei adrodd. Os ydynt yn anghytuno, mae estyniad, rheol PAC neu orfodaeth ar lefel ap yn dal i fod ar waith, ac ni fydd unrhyw faint o diwnio twnnel yn ei drwsio.

Cofnodwch yr hyn a ffurfweddwyd gennych: pa apiau sy'n defnyddio'r proesi, a yw DNS yn lleol neu o bell, a yw UDP wedi'i rwystro, a beth yw'r ymddygiad methu. Y rhestr fach honno sy'n gwneud y gymhariaeth nesaf yn bosibl, oherwydd nid oedd “newidiodd yr IP” erioed wedi dweud wrthych pa un o'r pum gwiriad hyn a lwyddodd.