საწყისი დანიშნულებები გამჭვირვალე TCP-დან SOCKS-ზე გადაგზავნაში
ხსნის, თუ რატომ სჭირდება გამჭვირვალე TCP-დან SOCKS-ზე გადაგზავნას თარჯიმანი, რომელიც აღადგენს საწყის დანიშნულებას პროქსისთან მოლაპარაკებამდე.
ფაირვოლი შეიძლება შეცვალოს, სად მოხვდება TCP კავშირი. მაგრამ მხოლოდ ამ ცვლილებით ის ვერ ასწავლის საწყის აპლიკაციას SOCKS-ზე საუბარს.
ჩვეულებრივი SOCKS სერვერი ელოდება მოლაპარაკებას, რომელიც აღწერს მოთხოვნილ დანიშნულებას. პროქსის უცნობი აპლიკაცია სამაგიეროდ დაუყოვნებლივ აგზავნის საკუთარ პროტოკოლურ ბაიტებს. გადაამისამართეთ ეს ბაიტები პირდაპირ SOCKS მსმენელზე და ორი მხარე პირველ შეტყობინებაზე ვერ შეთანხმდება.
დაკარგული კომპონენტი თარჯიმანია
გამჭვირვალე TCP-დან პროქსიზე გადაგზავნის კომპონენტი ამ ინტერფეისებს შორის ზის. ის აღმოაჩენს დანიშნულებას, რომელიც აპლიკაციამ თავდაპირველად მოითხოვა, ამყარებს შესაბამის SOCKS ან HTTP CONNECT სესიას და შემდეგ გადასცემს აპლიკაციის მონაცემებს მიღებული ნაკადით.
თავის Linux iptables გზაზე redsocks-ის წყარო შენახულ დანიშნულებას SO_ORIGINAL_DST-ის საშუალებით იღებს. სხვა ოპერაციული სისტემები და გადამისამართების მეთოდები სხვა მექანიზმებს იყენებენ. ეს გადამისამართებისა და ქსელის კონფიგურაციის თვისებაა და არა ჩვეულებრივი SOCKS კლიენტის ფუნქცია.
საწყისი დანიშნულების ინფორმაცია ასევე ხსნის, თუ რატომ არ არის ყოველთვის ეკვივალენტური გადამისამართების წესის პროქსის ჰოსტიდან დაუკავშირებელ კარიბჭეზე გადატანა. მიმღებ პროცესს სჭირდება ის მეტამონაცემები, რომელსაც მისი ჩარევის რეჟიმი ითხოვს. სხვაგან გადაწერილი მისამართი შესაძლოა აღარ გვაწვდიდეს ამ ინფორმაციას მოსალოდნელი ფორმით.
შეინარჩუნეთ თარჯიმნის ფარგლები ნათელი. მომუშავე გადამისამართებული TCP კავშირი არ ამტკიცებს თვითნებური UDP-ის, ICMP-ის ან ყოველი რეზოლვერის გზის მხარდაჭერას. ზედა დონის პროქსის პროტოკოლი და თარჯიმნის იმპლემენტაცია კვლავ განსაზღვრავს მხარდაჭერილ ოპერაციებს.
როცა კონფიგურაცია კავშირისთანავე ფარდება, შეამოწმეთ პროტოკოლის საზღვარი, სანამ წვდომის წესებს გააფართოებთ. სრულად მისაწვდომმა SOCKS მსმენელმა შეიძლება უარყოს ბაიტები, რომლებიც არასდროს ყოფილა SOCKS მოთხოვნა.