Artemis-ს შეუძლია გვერდი აუაროს SOCKS-ს loopback broker-ისთვის

Artemis broker-ის კავშირმა, რომელიც არასწორი SOCKS პაროლით წარმატდება, შესაძლოა proxy დამმუშავებელი გამოტოვა. შეამოწმეთ broker-ის დანიშნულება და არა მხოლოდ socksHost.

transport-ის დოკუმენტაცია loopback broker მისამართებს, როგორიცაა localhost და 127.0.0.1, აღწერს როგორც SOCKS კონფიგურაციის გვერდის ავლით მოქმედ მისამართებს. ჩვეულებრივი ლოკალური გადაწყვეტის გზისთვის გამოიყენეთ განზრახული არა-loopback broker მისამართი, როცა კავშირი შუამავალზე უნდა გაიაროს. სხვა alias, რომელიც ჯერ კიდევ loopback-ზე იხსნება, შეიძლება იგივე შედეგი მოგვცეს.

შეამოწმეთ connector-ის ვერსიის ზუსტი პირობა

უფრო ახალი upstream connector-ის კოდი შეიცავს აშკარა remote-DNS გამონაკლისს. proxy დამმუშავებლის პირობაა:

socksEnabled && (socksRemoteDNS || !isTargetLocalHost())

როცა socksRemoteDNS ჩართულია იმ რეალიზაციაში, რომელიც ამ პირობას შეიცავს, connector დანიშნულებას გადაუწყვეტელს ტოვებს და SOCKS დამმუშავებელს აყენებს loopback-ის მსგავსი დანიშნულებისთვისაც. დოკუმენტირებული ნაგულისხმევი false-ის შემთხვევაში ლოკალური მისამართის ტესტი კვლავ მნიშვნელოვანია.

ეს ცვლის localhost-ის მსგავსი hostname-ის მნიშვნელობას: როცა ის გადაწყვეტისთვის SOCKS სერვერს გადაეცემა, ის მიუთითებს proxy-ის დანიშნულების ხედვაზე. სანამ დისტანციურ გადაწყვეტას აირჩევთ, დაადასტურეთ, რომ ეს არის broker-ის განზრახული ადგილი.

შეესაბამეთ ქცევა დაინსტალირებულ Artemis კლიენტს. როცა დამმუშავებელი ნამდვილად მარშრუტშია, განასხვავეთ SOCKS ავთენტიფიკაცია broker-ის ავთენტიფიკაციისგან და გადაამოწმეთ მიღებული კავშირის გზა იმის ნაცვლად, რომ წარმატებული broker სესია proxy მონაცემების გამოყენების მტკიცებულებად მიიჩნიოთ.