რატომ აჩვენებს Port-Share ყველა ვებსაიტის ვიზიტორს localhost-ის სახით

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

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

მიჰყევით ორ კავშირს და არა ჟურნალის ხაზს

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

ss -ltnp 'sport = :443'
ss -tnp 'dport = :8080'

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

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

ტრანსპორტის გადაცემა არ არის სათაურის ინექცია

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

ორი მექანიზმი შეიძლება ატარებდეს ორიგინალურ მისამართს და ორივე ორივე ბოლოში შეთანხმებას მოითხოვს. PROXY პროტოკოლი კავშირის დასაწყისში ამატებს პატარა სათაურს და ბექენდი უნდა იყოს კონფიგურირებული მის მოლოდინზე; ბექენდი, რომელიც მას არ ელის, ამ ბაიტებს მოთხოვნის დასაწყისად ჩათვლის და დამაბნეველად ჩავარდება. სანდო პროქსი სათაურები, როგორიცაა X-Forwarded-For, მუშაობს მაშინ, როცა HTTP-ს გაგებული პროქსი ადგენს მათ და ბექენდს ეუბნებიან, რომელ წყვილებს აქვთ მათი დამტკიცების უფლება.

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

curl -sS -H 'X-Forwarded-For: 127.0.0.1' https://site.example.com/health
grep -F '127.0.0.1' /var/log/nginx/access.log | tail -n 3

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

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

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

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

გადაწყვიტეთ, რომელი კომპონენტი იძლევა მისამართის გარანტიას

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

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

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

გამოსცადეთ წესი და არა გვერდი

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

curl -sS -o /dev/null -w '%{http_code}\n' https://site.example.com/
tail -n 5 /var/log/nginx/access.log
grep -c '' /var/log/nginx/access.log

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

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