N2N გადაფარვა პროქსი არ არის: დახაზეთ ორივე კავშირი

Firefox მიუთითებს 127.0.0.1:8000-ზე, N2N კიდე მუშაობს, თანატოლი პასუხობს ping-ს საკუთარ გადაფარვის მისამართზე, და ბრაუზერი მაინც იუწყება, რომ პროქსიმ კავშირი უარყო. ამ ჯაჭვში არაფერია წინააღმდეგობრივი. გადაფარვა ჰოსტს აძლევს ხელმისაწვდომ მისამართს კერძო ქსელში; ის არ ქმნის პროცესს, რომელიც პროქსის პროტოკოლზე საუბრობს. ბრაუზერი არ ითხოვს მარშრუტს თანატოლისკენ. ის ითხოვს ლოკალურ მსმენელს.

აქ ორი კავშირი ერევა ერთმანეთს, და მათი ცალ-ცალკე დახატვა ხსნის დაბნეულობის უმეტეს ნაწილს ერთ წუთში.

ორი კავშირი, არა ერთი

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

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

სად უნდა იცხოვროს მსმენელმა

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

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

localhost არ არის თანატოლი

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

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

მარშრუტს არ შეუძლია handshake-ის შესრულება

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

თუ მიზანი მხოლოდ თანატოლზე სერვისამდე მისვლაა, ამოიღეთ პროქსის პარამეტრი და გამოიყენეთ სერვისის გადაფარვის მისამართი პირდაპირ.

შეამოწმეთ საზღვრები თანმიმდევრობით

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

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