ორმა პროქსის პარამეტრმა შეიძლება შექმნას ჯაჭვი, რომელიც არ გინდოდათ

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

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

application → wrapper proxy A → application proxy B → website

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

მარტივ სქემას პირობები აქვს

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

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

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

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