Listen, Bind და BindSame Tinyproxy-ში: რომელი მისამართი იმარჯვებს
Listen ირჩევს მისამართს, რომელიც კლიენტებს იღებს, Bind გამავალი კავშირების წყაროს ირჩევს. არც ერთი მარშრუტს არ აყენებს, ამიტომ გზა ცალკე შეამოწმეთ.
პროქსი პასუხობს, მოთხოვნა სრულდება და მაინც დანიშნულება კვლავ LAN-ის მისამართს იწერს. პროქსის ჟურნალში არაფერი არ ჩანს არასწორად და ის ხაზი, რომელიც შეცვალეთ, სწორედ ის ხაზია, რომლის შეცვლასაც დოკუმენტაცია გვირჩევდა. ჰოსტზე, რომელსაც აქვს როგორც LAN-ის, ისე გვირაბის მისამართი, სამი დირექტივა წყვეტს, რომელი მისამართი სად გამოჩნდება და მხოლოდ ერთი მათგანი ეხება გამავალ მხარეს. არასწორი თანმიმდევრობით წაკითხვისას უმიზეზოდ აღმოჩნდებით მარშრუტიზაციის ცხრილში.
სიმპტომი: დანიშნულება LAN-ის მისამართს ხედავს
კლიენტი პროქსის LAN-ის მისამართზე უკავშირდება და პროქსი საკუთარ კავშირს ხსნის დანიშნულებისკენ. ეს მეორე კავშირი წყაროს მისამართს ბირთვის წესებით ირჩევს და ნაგულისხმევად ის არის, რასაც მარშრუტის ძიება ირჩევს. ამიტომ დანიშნულება ჰოსტის ძირითად მისამართს იწერს, მიუხედავად იმისა, რომ ყოველი ბაიტი პროქსიზე გაიარა. გადაცემის თვალსაზრისით არაფერი არ არის გატეხილი და სწორედ ამიტომ პროქსის ჟურნალს ამაზე სათქმელი არაფერი აქვს.
ამ ხარვეზის სარკული გამოსახულება უფრო ადვილი შესამჩნევია: გამავალი წყარო გვირაბის მისამართზე მიამაგრეთ და LAN-ის კლიენტები მსმენელს საერთოდ ვეღარ მიაღწევენ. ის ვერსია თავად აცხადებს საკუთარ თავზე, პირველი კი მუშა მოთხოვნის მიღმა იმალება. ორივე იმისგან მოდის, რომ ერთ დირექტივას ისე ვეპყრობით, თითქოს ორივე კითხვას პასუხობდეს.
სამი დირექტივა, სამი განსხვავებული მისამართი
Listen ასახელებს ლოკალურ მისამართს, რომელიც პროქსის კლიენტებს იღებს. Bind აძლევს წყაროს მისამართს იმ კავშირებს, რომლებსაც პროქსი გარეთ ხსნის, ხოლო BindSame ავალდებულებს მას, ხელახლა გამოიყენოს ახლახან მიღებული კავშირის ლოკალური მისამართი. ეს სამი ცალკე კითხვაა და ერთი ხაზი მხოლოდ ერთს პასუხობს. მათი არევა ჩვეულებრივი მიზეზია იმისა, რომ ცვლილება არაფერს აკეთებს.
| What you observe | Check first |
|---|---|
| A client cannot connect at all | Listen: the local address the listener binds |
| The request works but the far side logs the LAN address | Bind: the outgoing source is not being applied |
| A configured Bind appears to have no effect | BindSame yes: the accepted local address overrides the Bind list |
| The lookup names the LAN interface | The route, not the proxy: the source cannot reach that destination |
წაიკითხეთ დაყენებულ ვერსიასთან მოწოდებული კომენტირებული კონფიგურაცია, რადგან ნაგულისხმევი მნიშვნელობები და მისაღები სინტაქსი გამოშვებებს შორის იცვლება. პროექტის მაგალითი კონფიგურაცია თითოეულ დირექტივას სხვების გვერდით აღწერს. შეადარეთ ის ფაილი დისკზე არსებულს და არა სხვა დისტრიბუტივისთვის დაწერილ სახელმძღვანელოს.
დააყენეთ მსმენელი და გამავალი წყარო დამოუკიდებლად
აიღეთ ჰოსტი, რომლის LAN-ის მისამართია 192.168.50.10, ხოლო გვირაბის მისამართი 10.90.0.3. თუ LAN-ის კლიენტებმა პროქსის უნდა მიაღწიონ და მათი მოთხოვნები გვირაბიდან უნდა გავიდეს, ეს ორი დამოუკიდებელი გადაწყვეტილებაა და ორივე უნდა ჩაიწეროს. ქვემოთ მოცემული ფრაგმენტი ზუსტად ამას გამოხატავს და სხვას არაფერს.
Listen 192.168.50.10
Bind 10.90.0.3
BindSame noეს სრული კონფიგურაცია არ არის, ამიტომ შეინარჩუნეთ დამტკიცებული პორტი, ავთენტიფიკაცია, კლიენტების წვდომის კონტროლი და დანიშნულების შეზღუდვები. ორივე მისამართი უნდა ეკუთვნოდეს ამ ჰოსტს Tinyproxy-ის ქსელური სახელების სივრცეში, რადგან Bind-ის ის მნიშვნელობა, რომელსაც პროცესი ვერ ფლობს, კავშირის დროს ვარდება და არა გაშვებისას. BindSame yes სხვა პოლიტიკას აღწერს, სადაც მიღებული კავშირის ლოკალური მისამართი ხდება გამავალი წყარო. მიმდინარე გამოშვებებში ამ განშტოებას Bind-ის სიაზე უპირატესობა აქვს და სწორედ ასე ქრება კონფიგურირებული წყარო შეცდომის გარეშე.
შეამოწმეთ მარშრუტი, რომელსაც წყარო გულისხმობს
წყაროს მისამართის არჩევა გზას არ ქმნის, ამიტომ ჰკითხეთ ბირთვს, რას გააკეთებდა იმ წყაროსა და იმ დანიშნულებით. ძიება, რომელიც გვირაბის ინტერფეისს ასახელებს, მინიმალური მტკიცებულებაა, ხოლო LAN-ის ინტერფეისის დამასახელებელი ნიშნავს, რომ წყარო დაწერილი სახით ვერ იმუშავებს. ძიება კონტექსტურია: ის აფასებს პოლიტიკის წესებსა და ცხრილს, რომლებიც ამ სახელების სივრცეში მოქმედებს. ეს კავშირი არ არის და არაფერს ამბობს იმაზე, რასაც დაბლა მდგომი NAT წარუდგენს სერვისს.
ip -4 route get 203.0.113.25 from 10.90.0.3მაგალითში გამოიყენეთ დოკუმენტაციის მისამართი და ჩაანაცვლეთ იმ სერვისით, რომლის ტესტირების უფლებაც გაქვთ. როცა პროქსი კონტეინერში მუშაობს, ძიება პროქსის სახელების სივრცეში შეასრულეთ, რადგან ჰოსტის წესები არ არის ის წესები, რომლებსაც პროცესი ხედავს. თუ განზრახული გვირაბის მარშრუტი არ არსებობს, დაე, ქსელის მფლობელმა გამოასწოროს, ნაცვლად იმისა, რომ პროქსის ჰოსტს დანიშნულების სპეციფიკური წესები დაუმატოთ. ნუ გაასუფთავებთ ჰოსტის მარშრუტებს და ნუ გამორთავთ სერვერის მიერ გაგზავნილ მარშრუტებს ძიების წარმატებისთვის, თუნდაც ძველმა სახელმძღვანელომ ასე გააკეთა, რადგან ასეთი ცვლილებები ერთი პროქსის გზის გასწორებისთვის მთელი ჰოსტის დამტკიცებულ VPN ქცევას ცვლის.
დაადასტურეთ წყარო დანიშნულებაზე
წყარო წაიკითხეთ იქ, სადაც მოთხოვნა ჩადის და არა საიდანაც გადის. დანიშნულების აპლიკაციის ჟურნალი ან მის წინ მდგომი კიდური მოწყობილობა იწერს იმ მისამართს, რომელიც მან ნამდვილად ნახა, ხოლო პროქსი მხოლოდ საკუთარ განზრახვას გეტყვით. ცვლილების შემდეგ განზრახული მსმენელის გავლით ერთი ახალი მოთხოვნა გააგზავნეთ, რადგან ქეშში მყოფი კავშირი ახალი მიბმის შესახებ არაფერს ამტკიცებს. შემდეგ შეადარეთ ჩაწერილი მისამართი თქვენ მიერ დაყენებულს.
ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sScurl მხოლოდ ტრაფიკის გენერატორია; შესამოწმებელი მისამართი ის არის, რომელიც შორს მდგომმა მხარემ ჩაწერა და არა ის პირი, რომელსაც curl შემთხვევით დაუკავშირდა. თუ ეს ორი არ ემთხვევა, გადაწყვიტეთ, განსხვავება წყაროს არჩევიდან მოდის თუ შემდგომი გარდაქმნიდან, რადგან ისინი სხვადასხვა ადგილას სწორდება. დაგეგმეთ მისამართების ცვლილებები და პროქსის გადატვირთვები ერთად, რადგან იმ მისამართის მიბმა, რომელიც გვირაბს აღარ აქვს, ხელახალი დაკავშირების შემდეგ ჩუმად ვარდება. DNS-ისა და IPv6-ის ქცევაც ცალკე განსაზღვრეთ, რადგან ზემოთ მოცემული IPv4-ის ფრაგმენტი არც ერთ მათგანზე არაფერს ამტკიცებს.