პირად Container Apps აპზე წვდომა წერტილიდან საიტამდე VPN-ით
შიდა Container Apps გარემოს სჭირდება პირადი შესასვლელი, შესაბამისი ჰოსტის სახელი და გადამწყვეტი, რომელსაც VPN მიაღწევს. შეასრულეთ ყველა ნაბიჯი, შემდეგ გადაამოწმეთ უარი.
ეს სახელმძღვანელო მოიცავს Container Apps გარემოს სამუშაო დატვირთვის პროფილებითა და შიდა ვირტუალური ქსელის შესასვლელით, რომელსაც ლეპტოპიდან აღწევენ დამტკიცებული წერტილიდან საიტამდე VPN-ით, აპის პირდაპირი FQDN-ის გამოყენებით და გარემოს დონეზე HTTP მარშრუტების გარეშე. გარემოს შესასვლელი კლიენტიდან ხელმისაწვდომია, აპის შესვლის არეალი კარნახობს მომხმარებელს, და ჰოსტის სახელი პირად შესასვლელში იხსნება. ქვემოთ მოცემული ყოველი ნაბიჯი ტოვებს შესამოწმებელ შედეგსა და უკუქცევას, რომელიც არ ეხება არაფერს, რაც არ შეგიცვლიათ. გაიარეთ ისინი მოცემული თანმიმდევრობით, რადგან არც ერთი შემდგომი ნაბიჯი ვერ აანაზღაურებს 1-ელ ნაბიჯში არასწორად მიღებულ არეალის გადაწყვეტილებას.
DNS-ზე შეხებამდე დააზუსტეთ სიტყვა შიდა. ამ პროდუქტში ის ორი სხვადასხვა არეალისთვის გამოიყენება, და მათი არევა ყველაზე გავრცელებული მიზეზია, რის გამოც მუშა სახელი მაინც ვერ აბრუნებს არაფერ სასარგებლოს.
ნაბიჯი 1: დააფიქსირეთ გარემოსა და აპის არეალი
წაიკითხეთ აპის შესვლის კონფიგურაცია, სანამ რომელიმე ჩანაწერს შეცვლით:
| Setting | Boundary |
|---|---|
| Internal environment | The environment entry is reached through its private network arrangement |
| App with internal ingress | Callers from the environment VNet only; a VPN laptop qualifies once it has a route into that VNet and the domain resolves privately |
| App with external ingress in an internal environment | The app accepts outside traffic through the environment's private entry |
შიდა შესვლა ვლინდება გარემოს შიდა დატვირთვის ბალანსერზე გარემოს VNet-ის შიგნით, ამიტომ კითხვა არ არის, არის თუ არა ლეპტოპი სხვა კონტეინერის აპი, არამედ ის, შეუძლია თუ არა მას ამ VNet-ზე მიღწევა. VPN კლიენტი, რომელსაც აქვს მარშრუტი VNet-ში და გარემოს ნაგულისხმევი დომენი პირადი ზონის მეშვეობით იხსნება, არის უფლებამოსილი მომხმარებელი, და სწორედ ამას აშენებენ დარჩენილი ნაბიჯები. საჯარო შესასვლელის გარეშე შიდა გარემო სხვა ფაქტია, ვიდრე შიდა შესვლის მქონე აპი, და აპის დონეზე გარე შესვლა გარემოს საჯარო კარს არ აძლევს. ჩაწერეთ არეალი ბილეთშიც და პორტალშიც, რადგან შემდეგი ინჟინერი ჯერ ბილეთს კითხულობს.
გაგრძელებამდე დაადასტურეთ ეს არეალი კონფიგურაციის მფლობელთან და კარიბჭე ვიწროდ შეინახეთ: თუ გარემოს VNet-ში მარშრუტი არ არსებობს, ან გარემოს ნაგულისხმევი დომენი პირადი ზონის მეშვეობით არ იხსნება, გაჩერდით და ჯერ ის გზა გაასწორეთ. არც ერთი შემდგომი ნაბიჯი ვერ შეცვლის მომხმარებელს, რომელსაც VNet-ზე მიღწევა ან სახელის გახსნა არ შეუძლია.
ნაბიჯი 2: შეაგროვეთ ნამდვილი ჰოსტის სახელი და შესასვლელის მისამართი
ჩაწერეთ გარემოს ნაგულისხმევი დომენი, მისი სტატიკური პირადი შესასვლელის მისამართი და აპის კონფიგურირებული FQDN, აღებული რესურსიდან და არა ძველი ეკრანის სურათიდან ან ვიკი გვერდიდან:
az containerapp env show -n ENV -g RG \
--query "{domain:properties.defaultDomain, ip:properties.staticIp}"
az containerapp show -n APP -g RG \
--query "properties.configuration.ingress.fqdn"Container Apps-ის პირადი შესასვლელის სახელმძღვანელო აღწერს გარემოს დომენის მის შიდა მისამართთან შესაბამისობას, აპლიკაციის ჰოსტის სახელების უცვლელად შენარჩუნებით. სწორედ ამ ფორმას აშენებთ აქ ხელით, ამიტომ ზონის შიგთავსი მასთან შეათანხმეთ და ნუ გამოიგონებთ ახალ სახელდების სქემას.
თუ წაკითხული დომენი არ ემთხვევა აპის მიერ მოხსენებულ FQDN-ს, გაჩერდით და ახლავე შეათანხმეთ ისინი. არასწორ სუფიქსზე ზონის აშენება ქმნის ჰოსტის სახელს, რომელიც სრულყოფილად იხსნება და მაინც არასწორ ვირტუალურ ჰოსტზე ხვდება.
ნაბიჯი 3: მოათავსეთ პირადი ზონა VPN-ის გადამწყვეტის გზაზე
შექმენით ან ხელახლა გამოიყენეთ მხარდაჭერილი პირადი DNS ზონა გარემოს ფაქტობრივი ნაგულისხმევი დომენისთვის, დოკუმენტირებული ველური ბარათისა და მისამართის ჩანაწერებით, რომლებიც სტატიკურ შესასვლელზე მიუთითებენ. დაუკავშირეთ ეს ზონა შესაბამის ვირტუალურ ქსელს, და პირადი ხელისუფლება ხელმისაწვდომი გახადეთ VPN-ის დამტკიცებული გადამწყვეტის გზით, ნაცვლად იმისა, რომ კავშირი საკმარისად ჩათვალოთ.
წერტილიდან საიტამდე კლიენტს, როგორც წესი, სჭირდება პირადი გადამწყვეტის შემომავალი საბოლოო წერტილი ან მხარდაჭერილი DNS გადამცემი ამ ზონამდე მისასვლელად. ზონის დაკავშირება ცვლის იმას, რასაც Azure წყვეტს დაკავშირებული ქსელებისთვის; ის არ გადამისამართებს ყოველი გარე ლეპტოპის საჯარო გადამწყვეტს. ნუ ჩაანაცვლებთ სხვა Container Apps ქსელური მოდელიდან ნასესხები პირადი საბოლოო წერტილის DNS ზონით, რადგან ჩანაწერების სახელები და ზონის სუფიქსი არ დაემთხვევა.
ამ ნაბიჯის უკუქცევა არის ზონის კავშირის ან თქვენ მიერ დამატებული ჩანაწერის მოცილება. ჩაწერეთ რომელი იყო მათგან, რადგან საერთო ზონის წაშლა ერთი კავშირის გასაუქმებლად ცნობილი გზაა მეორე გარემოს დასაფუჭებლად.
ნაბიჯი 4: შეამოწმეთ სახელი, შემდეგ უარყოფილი აუდიტორია
შეამოწმეთ ჰოსტის სახელი და TLS იდენტობა ერთად, და არა მხოლოდ მისამართი. კონტროლირებადი სახელების დაშვების დიაგნოსტიკისთვის შეგიძლიათ მისამართის დაფიქსირება ჰოსტის სახელის შენარჩუნებით:
curl --resolve app.ENVIRONMENT_DOMAIN:443:10.40.0.10 \
https://app.ENVIRONMENT_DOMAIN/შეცვალეთ ჰოსტის სახელი აპის ნამდვილი FQDN-ით, ხოლო მისამართი ნამდვილი შიდა შესასვლელით. ეს მხოლოდ იმ ერთ მოთხოვნაზე მოქმედებს და DNS უზრუნველყოფა არ არის. ნუ დაამატებთ -k იდენტობის წარუმატებლობის თვალსაჩინო გავლად გადასაქცევად, რადგან სერტიფიკატის შეუსაბამობა იმის სიგნალია, რომ არასწორ მსმენელს ხვდებით.
რიცხვითი მისამართის უშუალოდ მოთხოვნამ შეიძლება აირჩიოს არასწორი ვირტუალური ჰოსტი ან ვალიდაცია ჩააგდოს მაშინაც, როცა TCP 443 პასუხობს, ამიტომ წარმატებული IP ტესტი ქსელის შესახებ მტკიცებულებად ჩათვალეთ და მეტად არა. მიზნობრივი ლეპტოპიდან ჩვეულებრივი გადამწყვეტის გზა არის კლიენტის DNS გადამცემი ან ზონის მასპინძელი პირადი გადამწყვეტის შემომავალი საბოლოო წერტილი, და იქ წარუმატებლობა გადამწყვეტის ხელმისაწვდომობის პრობლემაა და არა დაკარგული ჩანაწერი. დაადასტურეთ, რომ იგივე მოთხოვნა ამ გზაზე წარმატებულია, შემდეგ დაადასტურეთ, რომ უარყოფილი აუდიტორია კვლავ უარყოფილია.
რა უნდა ჩაიწეროს და რა უნდა დაბრუნდეს
კონტეინერის სამიზნე პორტი და კლიენტის HTTPS პორტი ცალკე პარამეტრებია. ნუ გამოაქვეყნებთ კონტეინერის სამიზნე პორტს VPN-ით იმიტომ, რომ კონტეინერი იქ უსმენს, და ნუ გააფართოვებთ ქსელურ წესს პორტის ტესტის გასავლელად. ორივე ცვლილება გადარჩება ინციდენტს და მოგვიანებით ძნელია მათი მიკუთვნება.
დაასრულეთ ახალი აპლიკაციის ოპერაციით მიზნობრივი ლეპტოპიდან, მისი უფლებამოსილი იდენტობითა და ჩვეულებრივი DNS-ით, შემდეგ შეამოწმეთ, რომ არაუფლებამოსილი მომხმარებელი კვლავ წარუმატებელია. სანამ აპის კონფიგურაციაში ხართ, ასევე დაადასტურეთ, ხსნის თუ არა გარემოს დონის HTTP მარშრუტი ამ აპს სამიზნედ, რადგან ეს მარშრუტი მეორე კარია, რომელსაც შესვლის არეალი არ აღწერს.
ჩაწერეთ ხუთი მნიშვნელობა ერთად: გარემოს არეალი, აპის შესვლის არეალი, FQDN, პირადი შესასვლელის მისამართი და გადამწყვეტის მფლობელი. ეს ხუთი აღწერს მთელ წვდომის კონტრაქტს, და შემდეგი ადამიანი, ვინც ამას გამართავს, ზუსტად მათ მოითხოვს.