ერთი ქსელური ბარათი საკმარისია გამოკვეთილი პროქსისთვის

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

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

client → proxy listener
proxy → existing router → destination

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

ნაგულისხმევი კარიბჭე სხვა კითხვას პასუხობს

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

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

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

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