mitmproxy, DevTools, Gradle: სამი ფენა VPN-ის უკან
loopback არასოდეს შედის გვირაბში. დააჯგუფეთ სიმპტომი მსმენელში, ნდობის საცავში ან პაკეტის ფილტრში და შეაკეთეთ ის ფენა, რომელიც ნამდვილად ჩავარდა.
VPN უკავშირდება, და სამი ურთიერთდაუკავშირებელი ხელსაწყო სამი სხვადასხვა გზით ჩავარდება იმავე შუადღეს. mitmproxy იწყებს მოთხოვნების აღარ ხედვას, Chrome უარყოფს დებაგერს, ხოლო Gradle BindException ლოკალური სოკეტის მიბმისას ისვრის. საერთო ეჭვია, რომ გვირაბი localhost-ს ბლოკავს. ეს არ შეუძლია: 127.0.0.1 მუშავდება ბირთვის შიგნით და არასოდეს აღწევს ადაპტერამდე, რომ აღარაფერი ვთქვათ კარიბჭეზე.
სამი ფენა, სამი განსხვავებული ავარია
რაც კლიენტთან შეიცვალა, loopback-ისკენ მიმავალი გზა არ არის. ეს არის ლოკალური პროქსი, მანქანის ნდობის საცავი და პაკეტის ფილტრი, და თითოეული მათგანი დეველოპერის სამუშაო ნაკადის სხვადასხვა ნაწილს ამტვრევს. სიმპტომის სწორ რიგში მოთავსება დიაგნოზის უდიდესი ნაწილია:
| Symptom | Layer | First check |
|---|---|---|
| Proxy sees no traffic | Local proxy or listener | ss -lntp, or netstat -ano on Windows |
| TLS error in one tool only | Trust store | Which CA bundle does that runtime read? |
| Local bind or connect refused | Packet filter or port owner | Who holds the port, and what rule drops it? |
ამ ტიპის თითქმის ყველა მოხსენება იწყება ბოლო რიგიდან და მაღლა მიემართება, რაც შებრუნებულია. გვირაბი ერთადერთი ფენაა, რომელიც დამტკიცებულად ვერ ხედავს loopback-ის ტრაფიკს, ამიტომ ყველაზე ნაკლებ ეჭვს იმსახურებს. დაიწყეთ იმით, რაც პროცესმა მიაბა, შემდეგ ჰკითხეთ, რომელ სერტიფიკატებს ენდობა, და მხოლოდ ამის შემდეგ შეხედეთ მანქანის პოლიტიკას.
დაიწყეთ მსმენელით, არა გვირაბით
როცა პროქსი 127.0.0.1:8080 ტრაფიკის მიღებას წყვეტს, მოხდა სამიდან ერთი: არასოდეს გაშვებულა, სხვა პორტი მიაბა, ან ფილტრმა loopback-ის კავშირი ჩამოაგდო. მსმენელი სოკეტების ჩამოთვლა ამას ერთი ბრძანებით პასუხობს და ასევე აჩვენებს, რომელი პროცესი ფლობს პორტს, როცა ორი ხელსაწყო არ თანხმდება, რომელი იყო პირველი.
მარშრუტის ძიებაში ლოკალური მისამართი იმავეს ადასტურებს მეორე მხრიდან. ip route get loopback-ის დანიშნულებისკენ იუწყება loopback-ის მოწყობილობაზე, არასოდეს გვირაბზე, რაც სასარგებლო წინადადებაა მზადყოფნაში, როცა ვინმე მარშრუტიზაციის ცვლილებას სთავაზობს გადაწყვეტად.
პროქსის ფენა: გარემო კონფიგურაცია არ არის
ბევრი კორპორატიული კლიენტი HTTP პროქსის ატარებს და ელოდება, რომ აპლიკაციები მას გამოიყენებენ. დაყენება HTTPS_PROXY შელში ასწორებს მის პატივისცემას ბრძანების ხაზის ხელსაწყოებში და არაფერს აკეთებს ხელსაწყოსთვის, რომელიც საკუთარ პარამეტრების ფაილს კითხულობს. Gradle, Selenium და gRPC თითოეული საკუთარ კონფიგურაციას ეკითხება, და ერთ ტერმინალში ექსპორტირებული პროქსი IDE-ს მიერ გაშვებული დემონისთვის უხილავია.
კონტეინერის ხელსაწყოები ჩვეულებრივი ადგილია, სადაც ეს თვალსაჩინო ხდება. კონტეინერის loopback თავისია, ამიტომ 127.0.0.1 კონტეინერის შიგნით არასოდეს ნიშნავს ჰოსტის პროქსის; საჭიროა ჰოსტის მისამართი ან ჰოსტის ქსელის პარამეტრი. შესწორება, რომელიც შელში მუშაობს და build-ში ჩავარდება, ჩვეულებრივ ეს რიგია, არა გვირაბი.
ნდობის ფენა: ხელსაწყო სხვა საცავს კითხულობს
ჩარევა მეორე ცვლილებაა და ყველაზე შემცდომელ შეცდომებს წარმოშობს. კლიენტი საკუთარ სერტიფიკატს წარადგენს შემოწმებული კავშირებისთვის, ამიტომ კორპორატიულ ფესვს მენდობის ბრაუზერი წარმატდება, მაშინ როცა ჩაშენებული CA საცავის მქონე ხელსაწყო ჩავარდება. Python-ის requests certifi-ის მეშვეობით კლასიკური შემთხვევაა: ოპერაციული სისტემის საცავი შეიძლება სწორი იყოს და მოთხოვნა მაინც ჩავარდეს, რადგან ის გაშვების გარემო მას არასოდეს კითხულობს. შეცდომის ტექსტი იშვიათად ახსენებს ჩარევას, ამიტომ ეს რიგი არასწორად დიაგნოსტირდება როგორც გატეხილი საბოლოო წერტილი.
შეადარეთ, რასაც საბოლოო წერტილი რეალურად წარადგენს, იმას, რაც ხელსაწყომ დაადასტურა. openssl s_client აჩვენებს სერვერის გამოგზავნილ ჯაჭვს; ხელსაწყოს საკუთარი დადასტურების გამომავალი აჩვენებს, რა გადაწყვიტა. როცა ისინი არ ემთხვევა, REQUESTS_CA_BUNDLE ან SSL_CERT_FILE არის ბერკეტი იმ გაშვების გარემოსთვის, და კორპორატიული ფესვი ეკუთვნის იმ საცავს, რომელსაც ის გარემო კითხულობს, და არა გლობალურ ადგილს, რომელსაც მხოლოდ ზოგიერთი ხელსაწყო პატივს სცემს.
ვერსიის ცვლილება, რომელიც SSL შეცდომას ასწორებს, ნდობისა და შიფრის პოლიტიკის მტკიცებულებაა, არა VPN-ის. Python-ის დაქვეითებამ, რომელმაც SOAP კლიენტი აამუშავა, შეცვალა ჩაშენებული CA საცავი და ნაგულისხმევი TLS პარამეტრები; ქსელის გზა არ გადაადგილდა.
ფილტრის ფენა: მასაც შეუძლია loopback-ის ჩამოგდება
მესამე ცვლილება პაკეტის ფილტრია და ზოგიერთი პროდუქტი აყენებს წესებს, რომლებიც გვირაბში არშესულ ტრაფიკს ჩამოაგდებს. ლოკალური მსმენელებიც შეიძლება შევიდნენ. ეს მუშა სოკეტს უარყოფილ ან ვადაგასულ კავშირად აქცევს, და მიღებული შეცდომა აპლიკაციის შეცდომას ჰგავს და არა მანქანის პოლიტიკას.
პორტის საკუთრება ამ ფენის მეორე ნახევარია. BindException ნიშნავს, რომ სოკეტი ვერ გაიხსნა, რაც განსხვავებული მარცხია უარყოფილი კავშირისგან. სანამ ფილტრს დაადანაშაულებთ, შეამოწმეთ, ხომ არ ფლობს პორტს სხვა პროცესი, შემდეგ მოძებნეთ წესი, რომელიც ლოკალურ ტრაფიკს ჩამოაგდებს, და დაამატეთ ვიწრო ნებართვა, რომელსაც პროდუქტი მხარს უჭერს. ორი ხელსაწყო, რომლებიც ერთი და იმავე დებაგ პორტისთვის იბრძვიან, ზუსტად იგივე შეტყობინებას იძლევა, რაც პოლიტიკის ბლოკია, და მათგან მხოლოდ ერთი სწორდება firewall-ის ცვლილებით.
Chrome-ის დებაგ პორტი იმავე ოჯახში ჩავარდება. ბრაუზერი ირთვება, დრაივერი ვერ აღწევს DevTools-ის საბოლოო წერტილამდე, და შეტყობინება ასახელებს DevTools-ს და არა ქსელს. დამატებითი გაშვების დროშები და ზედმეტი დრაივერის მენეჯერი ცვლიან იმას, თუ რომელი პროცესი ფლობს პორტს, ამიტომ მათი მოცილება ზოგჯერ VPN-ის შესწორებად გვეჩვენება.
შეაკეთეთ ჩავარდნილი ფენა
შეაკეთეთ ჩავარდნილი ფენა, არა გვირაბი. მიუწვდომელ loopback მსმენელს სჭირდება მსმენელის ან პორტის შესწორება. არასანდო სერტიფიკატს სჭირდება კორპორატიული ფესვი დაყენებული იქ, სადაც კონკრეტული გაშვების გარემო იყურება, გამონაკლისი ვიწროდ შენარჩუნებული. ლოკალურ ტრაფიკს ჩამომგდები ფილტრს სჭირდება კონკრეტული ნებართვის წესი და არა გამორთული ფილტრი, რადგან გამორთვა ხელახლა ხსნის ყველაფერს, რასაც ის იცავდა.
VPN-ის ხელახალი დაკავშირება ამ ფენებიდან არცერთს არ ამოწმებს. ის მხოლოდ ხელახლა უშვებს იმ ცვლილებას, რომელმაც ისინი გატეხა, ამიტომ იგივე სამი მარცხი ბრუნდება ყოველი ხელახალი დაკავშირების შემდეგ და ქრება ყოველი გადატვირთვის შემდეგ, რომელიც კლიენტს უმოქმედოდ ტოვებს.