აპლიკაციის მოთხოვნები კორპორაციული VPN-ის უკან იშლება, ბრაუზერი კი მუშაობს

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

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

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

env | grep -i proxy            # Linux/macOS
netsh winhttp show proxy       # Windows, machine-wide
curl -sv --noproxy '*' https://svc.internal/
nc -vz svc.internal 8080

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

აპლიკაციამ მემკვიდრეობით მიიღო პროქსი, რომელიც არავის დაუყენებია

HTTP-ის დასტების უმეტესობა პროქსის კონფიგურაციას ნაგულისხმევად ოპერაციული სისტემიდან კითხულობს. კორპორაციული VPN კლიენტი ხშირად ამონტაჟებს ერთს თავისი წვდომის პროფილის ნაწილად, ამიტომ მოთხოვნები გადის პროქსიდან, რომელიც დეველოპერს კოდში არასოდეს უხსენებია. .NET-ში ნაგულისხმევი დამმუშავებელი IE/WinHTTP-ის პარამეტრებიდან იღებს; Java კითხულობს -Dhttp.proxyHost-ს; Node-ს არ აქვს ჩაშენებული პროქსის მხარდაჭერა, სანამ ბიბლიოთეკა არ დაამატებს. წარუმატებლობა იშვიათად არის სუფთა უარი, ამიტომ ხალხი სერვერზე იწყებს ყურებას.

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

var handler = new HttpClientHandler { UseProxy = false };
using var client = new HttpClient(handler);

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

თქვენს მიერ არჩეული პორტი არ არის ის პორტი, რომელსაც პოლიტიკა უშვებს

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

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

ნედლი TCP, რომელსაც გზა ახლიდან აყენებს

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

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

კავშირები, რომლებიც მხოლოდ დიდი დატვირთვისას იხურება

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

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

როგორ გავარჩიოთ ოთხივე ერთ გავლაში

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

შეინახეთ ერთი ცვლადი თითო ტესტზე და ჩაწერეთ გამოყენებული დანიშნულების ჰოსტი. ამ საბაზისო ხაზის გარეშე შემდეგი ადამიანი ოთხივე ნაბიჯს თავიდან იმეორებს.