VPN ჩართულია და localhost აღარ მუშაობს: სახელი, პროქსი თუ bind?

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

როცა localhost კორპორატიულ ზონაში იხსნება

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

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

შეცვალეთ ჰოსტის სახელი ლიტერალური მისამართით აპლიკაციაში, მონაცემთა ბაზის კლიენტში ან რვეულის URL-ში, შემდეგ გაიმეორეთ მოთხოვნა. თუ ხარვეზი ქრება, სახელდების პრობლემა გქონდათ და გვირაბი მხოლოდ გამშვები იყო. თუ გრძელდება, მომსმენი ან მარშრუტია შემდეგი ეჭვმიტანილი და სახელი მხოლოდ ცრუ კვალი იყო.

პროქსის პარამეტრები, რომლებიც loopback-ს იჭერენ

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

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

curl --noproxy '*' http://127.0.0.1:8080/health
NO_PROXY=localhost,127.0.0.1,::1 your-tool

bind მისამართი წყვეტს, ვის შეუძლია დაკავშირება

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

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

სად ელოდება გამართვის ხელსაწყო LAN-ს

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

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

გაჩერდით პირველ ჩავარდნილ ეტაპზე

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

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