რატომ სჭირდება თქვენს URL-ს შესასვლელი 80 ან 443 პორტზე და არა 45000-ზე

აკრიფეთ ჰოსტის სახელი ბრაუზერში და სქემა წყვეტს დანიშნულების პორტს: 80 http-სთვის, 443 https-სთვის. DNS პასუხში არაფერი აუქმებს ამას და თქვენს მანქანაზე არც ერთი გადამისამართების წესი ვერ გამოიგონებს მსმენელს პროვაიდერის კიდეზე. როცა VPN პროვაიდერი გაძლევთ მაღალ საჯარო პორტს, მაგალითად 45000-ს, აშკარა URL მუშაობს, სუფთა კი არა. უფსკრული შესვლის წერტილშია, არა აპლიკაციის შიგნით.

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

ნახეთ, სინამდვილეში სად მიდის მოთხოვნა

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

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

რატომ ვერ გამოასწორებს ლოკალური წესი კიდეს

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

DNS-იც ვერ ატარებს პორტს. HTTP სპეციფიკაცია განსაზღვრავს სქემის ნაგულისხმევებს და A ან AAAA ჩანაწერი აბრუნებს მისამართს, ხოლო CNAME სხვა სახელს. ბრაუზერი მაინც აერთებს სქემის პორტს, ამიტომ დანიშნულებას მხოლოდ URL-ში აშკარა პორტი ცვლის.

ვარიანტი ერთი: შეინარჩუნეთ აშკარა პორტი

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

სანამ იქ ხართ, შეამოწმეთ გადამისამართებები და cookie-ების არე, რადგან backend, რომელიც საკუთარ ჰოსტის სახელს წერს Location თავსართში, აუქმებს ამ მოწყობას.

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

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

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

ვარიანტი სამი: წინ დადეთ frontend

უკუპროქსის შეუძლია ხელმისაწვდომ მისამართზე 443-ზე მოსმენა და TLS-ის დასრულება და გახსნას ცალკე კავშირი backend-თან VPN-ის გავლით. ვიზიტორები ხედავენ frontend-ის სახელს და ნაგულისხმევ პორტს, ხოლო frontend თქვენი სახელით ელაპარაკება backend-ის მაღალ პორტს. ეს მუშაობს, რადგან ცვლის არქიტექტურას და არა ებრძვის შესვლის წერტილს. მაშინ backend-ს საერთოდ არ სჭირდება შემომავალი პორტი საჯარო ინტერნეტში.

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

შეინარჩუნეთ ერთი წარმომავლობა

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

შემდეგ გადაწყვიტეთ აუდიტორიის გათვალისწინებით. მოკლე URL-მა შეიძლება გაამართლოს მართული frontend და არ ღირს შემთხვევით მხოლოდ VPN-ისთვის განკუთვნილი კერძო სერვისის საჯაროდ ქცევა.