Malfermi duan retumilon ne kreas duan VPN-vojon

Profiloj kaj privataj fenestroj apartigas la staton de la retumilo, ne la retajn vojojn. Dua vojo bezonas regulon por unuopa aplikaĵo, prokurilon aŭ nomspacon, kaj ĉiu havas sian prezon.

Du retumiloj, du fenestroj, unu ĉe la labora konto kaj unu ĉe persona konto, kaj la supozo estas, ke ili nun sekvas malsamajn vojojn. Ili ne sekvas. Apartigo de profiloj tenas kuketojn dise, dum la decido pri enkursigo okazas sub la retumilo kaj scias nenion pri tio, kiu profilo demandis. Dua vojo bezonas regulon, kiu elektas unu, kaj ekzistas nur kelkaj lokoj, kie tiu regulo povas loĝi.

Apartigo de stato ne estas apartigo de vojo

Retumila profilo izolas konservejon: kuketojn, historion, etendaĵojn kaj foje akreditilojn. Tiu izolo estas devigata ene de unu proceza arbo kaj havas nenion por diri pri tio, kiu interfaco portas paketon.

Privataj fenestroj iras pli malproksimen en aspekto kaj neniom pli en enkursigo. Ĉio, kion la retumilo sendas, ankoraŭ eliras laŭ la vojo elektita de la operaciumo, krom se io inter la ingo kaj la reto ŝanĝas ĝin. Konfuzi izolon de konservejo kun izolo de reto kreas atendojn, kiujn neniu retumila vendisto promesis kaj kiujn neniu testo povas plenumi.

Kio efektive elektas vojon

Kvar aferoj povas elekti malsaman vojon: regulo pri VPN por unuopa aplikaĵo, kiu kongruas kun la rulebla dosiero aŭ pakaĵo, prokurilo agordita ene de la retumilo aŭ de la sistemo, reta nomspaco aŭ ujo, kaj dua fizika aparato. Ĉiu ŝanĝas ion realan, kaj ĉiu havas prezon.

Regulo por unuopa aplikaĵo estas la kutima respondo sur moveblaj platformoj, kie la VPN-servo ricevas liston de pakaĵoj. Sur labortablo ĝi dependas de la kliento, kaj regulo, kiu kongruas kun la rulebla dosiero, kovras ĉiun profilon, kiun tiu dosiero malfermas. Se du profiloj vere bezonas malsamajn vojojn, ili kutime bezonas du procezojn kun malsamaj identecoj anstataŭ du langetojn. Tial komuna retumila instalado neniam povas esti la limo en profilo-bazita dezajno.

Prokuriloj ĉe aplikaĵa nivelo aldonas plian peranton

Prokurila agordo en la retumilo ja kreas apartan vojon, kaj ĝi ankaŭ kreas apartan fidan rilaton kun tiu, kiu funkciigas la prokurilon. Tio estas legitima aranĝo por unu profilo, kaj ĝi ne estas egala al kovrado de la tuta aparato.

Elektu la prokurilon konscie: SOCKS-auskultanto sur la sama gastiganto, aŭtentigita prokurilo ene de la tunelo, aŭ fora servo. Miksi prokurilon kun plentunela VPN produktas nestitajn vojojn, en kiuj la fiaskmanieroj multobliĝas.

Kontrolu la realan peton de ĉiu retumilo

Sendu la saman peton el ĉiu retumilo kaj komparu la observitan elir-adreson, anstataŭ kompari la agordajn paĝojn. Agordita prokurilo, kiu silenteme malsukcesas konektiĝi, estas tre ofta maniero reveni al la defaŭlta vojo.

curl -sS --max-time 8 https://api.ipify.org
curl -sS --max-time 8 --proxy socks5h://127.0.0.1:1080 https://api.ipify.org
dig +short example.com

Poste ripetu la peton kun devigita prokurilo kaj kun malŝaltita tunelo, por vidi, kiu tavolo fakte portas trafikon. Notu ankaŭ la DNS-respondon, ĉar retumilo kun propra ĉifrita solvilo povas tute preterpasi la sisteman vojon kaj tamen montri la paĝon, kiun vi atendis.

Skribu la celitan mapadon en du linioj: kiu procezo uzas kiun vojon, kaj kiu posedas ĉiun el ili. Tenadu ankaŭ kontajn identecojn en la vido, ĉar du vojoj ne malhelpas, ke la sama ensaluto estas prezentata al ambaŭ celoj. Retestu post la sekva retumila ĝisdatigo, ĉar prokurilan agordon facilas perdi kaj malfacilas rimarki.

Rilataj artikoloj