HAProxy 302 კერძო აპამდე: ვინ ხსნის მეორე ნახტომს?

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

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

ორი გზა, რომლებიც კონფიგურაციაში ერთნაირად გამოიყურება

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

GET /app        client -> proxy
302 Location    proxy  -> client   (http://10.40.0.20:8080/)
GET /app        client -> 10.40.0.20:8080   client network, no route

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

GET /app        client -> proxy
GET /app        proxy  -> 10.40.0.20:8080   over the VPN
response        proxy  -> client

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

რა სჭირდება ბრაუზერს და რას არ აძლევს სერვერის VPN

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

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

როცა მხოლოდ პროქსი აღწევს აპამდე

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

backend private_app
    mode http
    option httpchk GET /health
    server app1 10.40.0.20:8080 check

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

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

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

თავად აპის გადამისამართებები კვლავ შიგნით მიუთითებს

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

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

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

გადაწყვიტეთ, რომელი დიზაინი გაქვთ სინამდვილეში

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

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

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

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

დაკავშირებული სტატიები