VPN vai starpniekserveris: ko katrs aptver un ko ne

Gan VPN, gan tiešais starpniekserveris maina adresi, ko redz vietne, un tur vairums salīdzinājumu apstājas. Atšķirība, kas nosaka jūsu iestatījumu, ir pārklājums: tiešais starpniekserveris ir starpnieks, kuru lietot izvēlas pati jūsu lietotne, atšķirībā no apgrieztā starpniekservera, kas atrodas vietnes priekšā, bet VPN pārvieto visu, ko operētājsistēma maršrutē tunelī. Šifrēšana, DNS apstrāde un uzvedība kļūmes gadījumā izriet no šī dalījuma. Veiciet šīs piecas pārbaudes pēc kārtas, un pirmā, kas neizdodas, pateiks, kurš rīks jums patiešām nepieciešams.

Kuras lietotnes starpnieks aptver?

Pārlūka starpniekservera paplašinājums attiecas tikai uz šo pārlūka profilu. Pasta klienti, pakotņu pārvaldnieki un otrs pārlūks turpina izmantot savus iestatījumus, un dažas lietotnes pilnībā ignorē sistēmas starpniekservera mainīgos. VPN aptver to, ko maršrutēšanas tabula sūta tunelī, un tas var būt visas lietotnes vai apakškopa sadalītā tunelī atkarībā no maršrutiem un klienta politikas.

Pārbaudiet lietotnes, kas ir svarīgas, nevis vispāriniet no vienas lapas ielādes. curl https://ifconfig.me seko vides starpniekservera mainīgajiem; galddatora lietotne var arī nesekot. Windows sistēmā netsh winhttp show proxy izdrukā WinHTTP starpniekserveri, ko izmanto pakalpojumi, un tas ir cits iestatījums nekā pārlūkā.

Vai lēciens ir šifrēts, un kur beidzas TLS?

Starpniekservera protokols ir satikšanās vieta, nevis garantija. SOCKS5 pārsūta TCP to nešifrējot, un vienkāršs HTTP starpniekserveris pārnēsā pieprasījuma rindu un galvenes atklātā tekstā. HTTPS caur starpniekserveri izmanto CONNECT, tāpēc jūsu TLS sesija joprojām beidzas galamērķī, nevis starpniekserverī. MDN ceļvedis par starpniekserveriem un tunelēšanu apraksta šo atšķirību no protokola puses.

VPN šifrē posmu starp jūsu ierīci un tās galapunktu. Aiz galapunkta ir spēkā tie paši noteikumi kā jebkurā citā tīklā, tāpēc viens tunelis neaizsargā lietotni, kas sūta akreditācijas datus pa vienkāršu HTTP. Neviens no abiem dizainiem neslēpj pieteikušos kontu, sīkfailu vai pārlūka pirksta nospiedumu.

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

Detalizētā izvade parāda, vai curl nosūtīja CONNECT uz 443 portu vai vienkāršu GET ar pilnu URL. Ar socks5h:// resursdatora nosaukums tiek nodots starpniekserverim SOCKS5 pieprasījuma iekšienē, un pēc tam tas pārsūta TLS, ko tas nevar nolasīt, tāpēc tas redz nosaukumu un baitu skaitu. Caur http:// starpniekserveri https:// URL ir CONNECT, tāpēc arī šis starpniekserveris redz galamērķa nosaukumu un apjomu, bet ne pieprasījumu vai atbildes pamattekstu.

Kurš atrisinātājs redz nosaukumu?

Nosaukumu atrisināšana var notikt lokāli pirms pieprasījuma aiziešanas, vai attālināti starpniekserverī. Ar curl socks5h:// nosūta resursdatora nosaukumu starpniekserverim, bet socks5:// vispirms to atrisina lokāli. Pārlūka starpniekservera iestatījumi piedāvā līdzīgu DNS opciju, un PAC faili var maršrutēt dažādus resursdatorus dažādi.

Divi protokoli var apiet starpniekserveri bez jebkādas nepareizas konfigurācijas. WebRTC vāc kandidātus caur STUN, un QUIC darbina HTTP/3 virs UDP, ko TCP starpniekserveris nevar pārnēsāt. Pārlūks atgriezīsies pie TCP, ja UDP 443 ir bloķēts, tāpēc UDP 443 bloķēšana resursdatora ugunsmūrī (vai maršrutētājā visam tīklam), nevis pārlūka karodziņš, ir uzticamais veids, kā noturēt HTTP/3 starpniekservera ceļā.

Pārbaudiet atrisinātāju no galamērķa skatpunkta, nevis no sava portatīvā datora. Pieprasījums, kas pienāk ar starpniekservera izejas adresi, bet lokāli atrisinātu nosaukumu, joprojām pastāsta vietējam atrisinātājam, kuras vietnes jūs apmeklējat.

Kas notiek, kad starpnieks sabojājas?

Skaidrs starpniekserveris sabojājas aizvērtā veidā: apturiet starpniekservera procesu, un pārlūks vai lietotne atgriež savienojuma kļūdu, nevis iet tieši. PAC un WPAD iestatījumi ir tie, kas sabojājas atvērtā veidā - ja skriptu nevar iegūt, klients atgriežas pie DIRECT un vietne atkal redz jūsu īsto adresi. VPN var sabojāties atvērtā vai aizvērtā veidā atkarībā no klienta un tā, vai ir aktīvs avārijas slēdzis vai ugunsmūra noteikums.

Pārbaudiet kļūmes gadījumu apzināti: apturiet starpniekservera pakalpojumu un ielādējiet vēlreiz; ja saņemat kļūdas lapu, nevis tiešu ielādi, novirziet PAC URL uz nesasniedzamu resursdatoru, lai redzētu atkāpšanos. Ja lapa joprojām ielādējas pa jūsu parasto maršrutu, starpniekserveris nepiedāvā nekādu aizsardzību pret saviem traucējumiem, un šī ir īpašība, kas jāzina pirms paļaušanās uz to.

Secība nosaka, ko redz vietne. Starpniekserveris, kura izejošā datplūsma iet caur VPN, atstāj vietnei VPN galapunkta adresi; novietojiet starpniekserveri ārpus tuneļa (VPN uz starpniekserveri attālinātā resursdatorā), un vietne tā vietā redzēs šī starpniekservera izejas adresi. Jebkurā gadījumā abi lēcieni var reģistrēt dažādas lietas.

Piecas pārbaudes, pēc kārtas

Zemāk esošais kontrolsaraksts ir viss lēmums vienā vietā. Pārklājums ir pirmais, jo tas novērš lielāko daļu neatbilstību: ja lietotne, kas jāaptver, neievēro iestatījumu, nekas tālāk sarakstā to neglābj.

Pēc tam apstipriniet rezultātu ar lietotni, kas izraisīja izmaiņas. Ielādējiet lapu konfigurētajā pārlūkā, iegūstiet to pašu lapu ar curl un salīdziniet adreses, ko katra ziņo. Ja tās nesakrīt, joprojām darbojas paplašinājums, PAC noteikums vai lietotnes līmeņa ignorēšana, un nekāda tuneļa regulēšana to nelabos.

Pierakstiet, ko konfigurējāt: kuras lietotnes izmanto starpniekserveri, vai DNS ir lokāls vai attālināts, vai UDP ir bloķēts un kāda ir uzvedība kļūmes gadījumā. Tieši šis mazais saraksts ļauj veikt nākamo salīdzinājumu, jo „IP mainījās“ nekad nepateica, kura no šīm piecām pārbaudēm izdevās.