მეორე ბრაუზერის გახსნა მეორე VPN მარშრუტს არ ქმნის

ორი ბრაუზერი, ორი ფანჯარა, ერთი სამსახურის ანგარიშზე და მეორე პირად ანგარიშზე, და ვარაუდია, რომ ახლა ისინი სხვადასხვა ბილიკს მიჰყვებიან. ასე არ არის. პროფილების გამიჯვნა ქუქებს ცალკე ინახავს, ხოლო მარშრუტიზაციის გადაწყვეტილება ბრაუზერის ქვემოთ მიიღება და არ იცის, რომელმა პროფილმა იკითხა. მეორე ბილიკს სჭირდება წესი, რომელიც მას ირჩევს, და მხოლოდ რამდენიმე ადგილია, სადაც ეს წესი შეიძლება ცხოვრობდეს.

მდგომარეობის გამიჯვნა ბილიკის გამიჯვნა არ არის

ბრაუზერის პროფილი იზოლირებს საცავს: ქუქები, ისტორია, გაფართოებები და ზოგჯერ სერტიფიკატები. ეს იზოლაცია ერთი პროცესის ხის შიგნით აღსრულდება და არაფერი აქვს სათქმელი იმაზე, რომელი ინტერფეისი ატარებს პაკეტს.

პირადი ფანჯრები გარეგნულად უფრო შორს მიდიან, მარშრუტიზაციაში კი არც ერთი ნაბიჯით. ყველაფერი, რასაც ბრაუზერი აგზავნის, კვლავ ოპერაციული სისტემის მიერ არჩეული ბილიკით გადის, თუ რაღაც სოკეტსა და ქსელს შორის არ შეცვლის მას. საცავის იზოლაციის ქსელის იზოლაციასთან არევა ქმნის მოლოდინებს, რომლებიც არცერთ ბრაუზერის მწარმოებელს არ დაჰპირდა და ვერც ერთი ტესტი ვერ დააკმაყოფილებს.

რა ირჩევს სინამდვილეში ბილიკს

ოთხმა რამ შეიძლება აირჩიოს სხვა ბილიკი: VPN წესი თითოეული აპისთვის, რომელიც ემთხვევა შესრულებად ფაილს ან პაკეტს, ბრაუზერში ან სისტემაში კონფიგურირებული პროქსი, ქსელის სახელთა სივრცე ან კონტეინერი, და მეორე ფიზიკური მოწყობილობა. თითოეული რაღაც რეალურს ცვლის, და თითოეულს თავისი ფასი აქვს.

წესი თითოეული აპისთვის ჩვეული პასუხია მობილურ პლატფორმებზე, სადაც VPN სერვისი იღებს პაკეტების სიას. დესკტოპზე ეს კლიენტზეა დამოკიდებული, და შესრულებად ფაილთან შესაბამისი წესი ფარავს ყველა პროფილს, რომელსაც ეს ფაილი ხსნის. თუ ორ პროფილს ნამდვილად სხვადასხვა ბილიკი სჭირდება, მათ ჩვეულებრივ ორი განსხვავებული იდენტობის პროცესი სჭირდებათ და არა ორი ჩანართი. ამიტომ საერთო ბრაუზერის ინსტალაცია ვერასოდეს გახდება საზღვარი პროფილზე დაფუძნებულ დიზაინში.

აპის დონის პროქსები კიდევ ერთ შუამავალს ამატებენ

ბრაუზერში პროქსის დაყენება ნამდვილად ქმნის ცალკე ბილიკს, და ასევე ქმნის ცალკე ნდობის ურთიერთობას მასთან, ვინც პროქსს მართავს. ეს ლეგიტიმური შეთანხმებაა ერთი პროფილისთვის, და ის არ უდრის მთელი მოწყობილობის დაფარვას.

აირჩიეთ პროქსი გააზრებულად: SOCKS მსმენელი იმავე ჰოსტზე, აუთენტიფიცირებული პროქსი გვირაბის შიგნით, ან დისტანციური სერვისი. პროქსის სრული გვირაბის VPN-თან შერევა ქმნის ბუდობრივ ბილიკებს, სადაც წარუმატებლობის რეჟიმები მრავლდება.

შეამოწმეთ თითოეული ბრაუზერის რეალური მოთხოვნა

გაგზავნეთ იგივე მოთხოვნა თითოეული ბრაუზერიდან და შეადარეთ დაკვირვებული გასასვლელი მისამართი, ნაცვლად პარამეტრების გვერდების შედარებისა. კონფიგურირებული პროქსი, რომელიც ჩუმად ვერ უკავშირდება, ძალიან გავრცელებული გზაა ნაგულისხმევ ბილიკზე დასაბრუნებლად.

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

შემდეგ გაიმეორეთ მოთხოვნა იძულებითი პროქსით და გამორთული გვირაბით, რომ ნახოთ, რომელი ფენა ატარებს ტრაფიკს სინამდვილეში. ჩაინიშნეთ DNS პასუხიც, რადგან საკუთარი დაშიფრული რეზოლვერის მქონე ბრაუზერს შეუძლია სისტემის ბილიკი სრულად გვერდი აუაროს და მაინც აჩვენოს ის გვერდი, რომელსაც ელოდით.

ჩაწერეთ განზრახული შესაბამისობა ორ სტრიქონად: რომელი პროცესი იყენებს რომელ ბილიკს, და ვის ეკუთვნის თითოეული. გაითვალისწინეთ ანგარიშების იდენტობებიც, რადგან ორი ბილიკი ხელს არ უშლის ერთი და იმავე შესვლის ორივე დანიშნულებისთვის წარდგენას. ხელახლა შეამოწმეთ შემდეგი ბრაუზერის განახლების შემდეგ, რადგან პროქსის პარამეტრი ადვილად იკარგება და ძნელად შესამჩნევია.