რატომ უკავშირდება curl localhost-ს და არა დისტანციურ URL-ს

თუ curl ცდილობს localhost-ს დაუკავშირდეს იმის მიუხედავად, თუ რომელი URL მიეცით, VPN არასწორი დასაწყისია. ლოკალური HTTP ან SOCKS პროქსი შეიძლება იყოს განზრახული პირველი კავშირი, მაშინაც კი, როცა სასურველი სერვისი სრულიად სხვაგანაა. თუ ეს პროქსი აღარ მუშაობს, localhost-ის მცდელობა ვერ ხერხდება მანამ, სანამ curl დანიშნულებას მიაღწევს. პროქსის პასუხი ასევე არ არის იმის მტკიცებულება, რომ დანიშნულებამ უპასუხა.

შეასრულეთ ეს ნაბიჯები თანმიმდევრობით და გაჩერდით პირველზე, რომელიც პირველ კავშირის მცდელობას ცვლის.

ჯერ წაიკითხეთ თავად curl-ის პროქსის წესები

curl კითხულობს პროტოკოლის სპეციფიკურ პროქსის ცვლადებს, მაგალითად https_proxy და HTTPS_PROXY, ასევე ALL_PROXY, როცა პროტოკოლის სპეციფიკური მნიშვნელობა არ მოქმედებს. შეამოწმეთ იმ shell-ის, სერვისის ან ამოცანის გარემო, რომელიც curl-ს რეალურად უშვებს და არა თქვენი მიმდინარე ტერმინალის. CI ამოცანა, systemd ერთეული და ინტერაქტიული shell შეიძლება სამ განსხვავებულ კომპლექტს მემკვიდრეობით მიიღებდეს. სწორედ ხილული shell-იდან გამოცნობა იწვევს იმას, რომ ეს გამოძიება მთელ ნაშუადღევს კარგავს.

ერთი გამონაკლისი დასამახსოვრებელია. curl http_proxy მხოლოდ პატარა ასოებით მიიღება; დიდი ასოებით დაწერილი HTTP_PROXY იგნორირდება, ამიტომ ერთი და იგივე გარემო სხვა ხელსაწყოებში სხვაგვარად იქცევა.

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

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

შეადარეთ სამი გამოძახება TLS-ით ჩართული

სამივე გაშვებისთვის გამოიყენეთ ერთი დამტკიცებული დიაგნოსტიკური დანიშნულება და იგივე ბინარული ფაილი.

curl -v https://service.corp.example/status
curl -q -v https://service.corp.example/status
curl -q --proxy '' -v https://service.corp.example/status

-q თრგუნავს ნაგულისხმევ curlrc-ს და სამუშაოდ უნდა იყოს სტრიქონის პირველი პარამეტრი. ის არ შლის პროქსის გარემოს ცვლადებს, რაც აკვირვებს მათ, ვინც სწორედ ამას ელოდება. მესამე ფორმა ამატებს ცარიელ --proxy მნიშვნელობას და გარემოს მიერ მოთხოვნილ პროქსის მხოლოდ ამ გამოძახებისთვის გადაფარავს. შეადარეთ პირველი კავშირის მცდელობა თითოეულ გამოსავალში და არა საბოლოო სტატუსის კოდი.

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

რას გამორიცხავს თითოეული შედეგი

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

მორგებული ბიბლიოთეკის ჩატვირთვა ან ინექციური ქსელური ქცევა უფრო გვიანდელი ფენაა და მხოლოდ გარემოს ცვლადი მისი მტკიცებულება არ არის.

პროქსის გადაწყვეტილება VPN-ისგან განცალკევებით შეინახეთ

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

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

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