VPN-ის ხელახლა დაკავშირების შემდეგ პროქსი კვლავ ძველ გვირაბის მისამართზეა?
ხელახლა დაკავშირებამ შეიძლება თქვენი გამტარი მიბმული დატოვოს მისამართზე, რომელსაც გვირაბი აღარ ფლობს. ოთხი რიგითი შემოწმება, დანომრილი გადაცემა და ნამდვილი სატესტო მოთხოვნა.
VPN კლიენტის ხელახლა გაშვება მხოლოდ იმას ამტკიცებს, რომ გვირაბი დაბრუნდა. ის არაფერს ამბობს იმ პროქსიზე, რომელსაც უთხრეს, რომ მის გავლით გასულიყო. Squid, tinyproxy და სხვა გამტარების უმეტესობა ინარჩუნებს გაშვებისას ნაპოვნ ლოკალურ წყაროს მისამართს, სანამ რამე ხელახლა ჩატვირთვას აიძულებს. როცა ხელახლა დაკავშირება ახალ გვირაბის მისამართს გასცემს, გამტარი ან ყოველ გამავალ კავშირზე ფეილდება, ან თქვენი ჩვეულებრივი მარშრუტით გასვლას იწყებს.
მეორე წარუმატებლობა საშიშია: გვირაბი მუშაობს, გვერდები იტვირთება და მხოლოდ გასასვლელი მისამართია არასწორი.
დაიწყეთ მსმენელით და არა გვირაბით
სამი მისამართია თამაშში და ხელახლა დაკავშირება მხოლოდ ზოგიერთს ცვლის. მსმენელი არის ის ადგილი, სადაც თქვენი ბრაუზერი მიუთითებს, ჩვეულებრივ 127.0.0.1 ან LAN მისამართი, და მას არ აინტერესებს, რომ გვირაბი შეიცვალა. გამავალი ლოკალური წყარო არის ის, რასაც გამტარი ბირთვს სთხოვს გამოიყენოს შემდეგი ნაბიჯის აკრეფისას, და ის გვირაბის მოწყობილობას უკავშირდება. საჯარო გასასვლელი არის ის, რასაც ვებ სერვერი იწერს, და შეიძლება იყოს რამდენიმე ნაბიჯით დაშორებული თარგმნილი მისამართი.
საჯარო IP-ის ძებნა მხოლოდ ბოლო კითხვას პასუხობს. ის ვერ გეტყვით, რომელ ლოკალურ მისამართს უნდა მიებას გამტარმა, რადგან ერთი საჯარო გასასვლელი რამდენიმე შიდა წყაროს დამალვას შეიძლება. მისამართი წაიკითხეთ იმისგან, ვინც კავშირს ფლობს: კლიენტის სტატუსის გამონატანიდან, თავად ინტერფეისიდან, ან იმ სახელთა სივრციდან, სადაც გვირაბი ცხოვრობს. პირველი გვირაბისებრი სახელის მქონე ინტერფეისის აღება არასწორ პასუხს იძლევა, როგორც კი მეორე პროფილი არსებობს.
კონტეინერებისა და სახელთა სივრცეების განლაგება ჩუმად ამსხვრევს ამ ვარაუდს. ერთ ქსელურ სახელთა სივრცეში მყოფი გამტარი ვერ მიება გვირაბს, რომელიც სხვაში არსებობს, და კონფიგურაციის რედაქტირების არც ერთი რაოდენობა არ ასწორებს ამას.
ოთხი შემოწმება სანამ რამეს შეცვლით
გაიარეთ ისინი რიგით. პირველი წარუმატებელი შემოწმება არის ადგილი, სადაც ჩერდებით, რადგან შემდეგები წინების ჭეშმარიტებას ვარაუდობენ.
- დაადასტურეთ, რომ გამოყენებული გვირაბი ის პროფილია, რომლის გარშემოც პროქსი აშენდა, და არა მეორე პროფილი, რომელიც თავისით დაუკავშირდა.
- ამობეჭდეთ მისამართი, რომელიც ახლა ამ მოწყობილობაზეა, და შეადარეთ იგი გაშვებულ კონფიგურაციაში არსებულ მისამართს.
- ჰკითხეთ გამტარს, რომელი წყარო იპოვა მან, და არა რას ამტკიცებს დისკზე არსებული ფაილი.
- დაადასტურეთ, რომ გამტარიდან მომავალი ტრაფიკი ნამდვილად ექვემდებარება იმ მარშრუტიზაციისა და ფაირვოლის პოლიტიკას, რომელსაც ელოდებით.
მოწყობილობის მისამართი მარტივია: ip -4 addr show dev tun0 ამობეჭდავს მიმდინარეს, ხოლო ip -4 route get 1.1.1.1 გვიჩვენებს, რომელ ინტერფეისს აირჩევდა ბირთვი ამ დანიშნულებისთვის. ზუსტ მისამართზე მიბმული გამტარი ხმამაღლა ფეილდება, როცა მისამართი ქრება. მოწყობილობაზე მიბმული ან ნაგულისხმევ წყაროზე დაბრუნებული გამტარი აგრძელებს მუშაობას და ჟონავს, და ეს არის ჩუმი შედეგი.
შეუსაბამეთ დოკუმენტაცია იმ გამოშვებას, რომელსაც აწარმოებთ, და არა ძებნის ზედა შედეგს. Squid-ის გამავალი მისამართის დირექტივა დოკუმენტირებულია v7 და უფრო ადრეულისთვის, ხოლო v8-ის დოკუმენტაცია ცხადად ამბობს, რომ დირექტივა იქ ხელმისაწვდომი არ არის, ამიტომ მის გარშემო აშენებული სკრიპტი ამ ზღვარს ვერ გადალახავს (იხილეთ Squid tcp_outgoing_address-ის ცნობარი). გადაამოწმეთ თავად პროდუქტის ანალიზატორით, სანამ რამე ხელახლა ჩაიტვირთება: squid -k parse უთითებს შეცდომებზე და გადის გაშვებულ პროცესს ხელის შეუხებლად.
დანომრეთ ყოველი გვირაბი და გადააგდეთ მოძველებული ცვლები
ხელახლა დაკავშირება გადაცემაა, გადაცემას კი რიგი სჭირდება. მონიშნეთ ყოველი დაკვირვებული კავშირი მთვლელით ან დროის ნიშნით, რომელიც ყოველ წარმატებულ დამყარებაზე იზრდება, შემდეგ ეს ნიშანი კანდიდატ კონფიგურაციაში გადაიტანეთ. როცა კანდიდატზე ნიშანი უფრო ძველია ვიდრე მიმდინარე, გადააგდეთ კანდიდატი მისი გამოყენების ნაცვლად, რადგან წინა გვირაბისთვის დაწერილი ნელი განახლება სხვაგვარად მიმდინარის პარამეტრებს გადაწერს. გააერთიანეთ მოვლენების აფეთქებები, რომ რხევადი კავშირი ერთი გადასვლა მოგცეთ თხუთმეტის ნაცვლად.
მოაწყვეთ სამუშაო ოთხ სვლად: გააუქმეთ ძველი გასასვლელი მდგომარეობა, დაელოდეთ კავშირის მფლობელის შეტყობინებას დასრულების შესახებ, ააშენეთ მხოლოდ მართული ნაწილი, შემდეგ გადაამოწმეთ და გაააქტიურეთ სერვისის მენეჯერის გავლით. მთელი ფაილის ორი მისამართის მნიშვნელობიდან ხელახლა გენერირება ის გზაა, რომლითაც მსმენელის შეზღუდვები, ავთენტიფიკაცია და დანიშნულების პოლიტიკა ჩუმად ქრება. პატივი ეცით განზრახ გაჩერებასაც. დამხმარე, რომელიც აგრძელებს მომხმარებლის მიერ გამორთული გვირაბის აკრეფას, ხარვეზია და არა გამძლეობა.
ღია სოკეტები ახალ მისამართს არ გაჰყვებიან
გამტარის გადაკონფიგურირება არაფერს ამბობს უკვე დამყარებულ კავშირებზე. დაცლიან თუ მოკვდებიან, პროდუქტზეა დამოკიდებული, ამიტომ დააკვირდით ქცევას და ნუ ჩათვლით წინასწარ.
ცვლამდე გახსნილ სოკეტზე მოწოდებული მოთხოვნა მაინც ძველი გზით გადის, მაშინაც კი როცა ახალი კონფიგურაცია სწორია. თუ ეს მნიშვნელოვანია, ცხადად გადაწყვიტეთ: მისეცით მოკლე დაცლის ფანჯარა და შეწყვიტეთ ახალი სამუშაოს მიღება, ან დახურეთ ძველი სოკეტები და მიიღეთ შეცდომები. შემდეგ გამოსცადეთ ახალი კავშირით და ეს შედეგი დაცლის შემოწმებისგან ცალკე შეინახეთ. წყაროზე მიბმა არც უსაფრთხოების ზღვარია. როცა ტრაფიკმა არასოდეს უნდა შეეხოს ჩვეულებრივ მარშრუტს, დააძალეთ ეს ნიშნებით და ფაირვოლის წესებით, DNS-ისა და IPv6-ის ჩათვლით, რომ წარუმატებელმა ხელახლა ჩატვირთვამ პროქსი ღიად კი არა, ცხადად გამორთული დატოვოს.
დაამტკიცეთ ახალი გასასვლელი ახალი მოთხოვნით
მნიშვნელოვანია მოთხოვნა, რომელიც გააქტიურების შემდეგ გაიხსნა, და არა ping და არა უკვე ქეშირებული გვერდი. სთხოვეთ პროქსის ნამდვილი URL და წაიკითხეთ გასასვლელი მისამართი, რომელსაც შორეული მხარე აცნობებს, შემდეგ შეადარეთ ის კლიენტის საკუთარ წარმოდგენას გვირაბზე, როცა მომწოდებელი ერთს აჩვენებს.
ანალიზი, ხელახლა ჩატვირთვა და მოთხოვნა ცალკე ბრძანებებად შეინახეთ, რომ წარუმატებლობამ ერთ ნაბიჯზე მიუთითოს. პირველი ორი არაფერს ცვლის, როცა ფეილდება, და სწორედ ამიტომ მუშაობს ისინი გადატვირთვამდე.
squid -k parse
sudo squid -k reconfigure
curl -x http://127.0.0.1:3128 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.comთუ ხელახლა ჩატვირთვა ფეილდება, შეაჩერეთ სერვისი და გაასწორეთ ნაწილი; მოძველებული გასასვლელით მომსახურე პროქსი უარესია ვიდრე მოკლე შეწყვეტა. თუ ხელახლა ჩატვირთვა წარმატებულია, მაგრამ ახალი მოთხოვნა მაინც სადღაც მოულოდნელად გადის, დაუბრუნდით მარშრუტიზაციის შემოწმებას მისამართების ხელახალი რედაქტირების ნაცვლად. ჩაწერეთ გვირაბის ის თაობა, რომლის წინააღმდეგაც შეამოწმეთ, რომ შემდეგ ხელახლა დაკავშირებას ჰქონდეს კონკრეტული რამ შესადარებლად.