რას გვეუბნება სინამდვილეში PHP-ის REMOTE_ADDR VPN-ის უკან
ეს არის მნიშვნელობა, რომელიც თქვენმა ვებ სერვერმა მოგაწოდათ და არა კითხვა გვირაბში. გაიარეთ მოთხოვნის გზა, შეამოწმეთ ვის შეუძლია მისი გადაწერა და იდენტობა აპლიკაციაში შეინახეთ.
ვიღაც კითხულობს, რატომ ჩნდება VPN მომხმარებელი აპლიკაციის ჟურნალში შესასვლელის კუთვნილი მისამართით ან მისამართით, რომელიც სადილის შემდეგ შეიცვალა. პასუხი იწყება იმით, თუ რა არის ეს მნიშვნელობა: ჩანაწერი, რომელიც ვებ სერვერმა მოთხოვნის გარემოში ჩასვა. ეს არ არის კითხვა გვირაბში, არ არის სერტიფიკატის იდენტობა და არ არის დაპირება, რომ ნომერი ერთ ადამიანს ეკუთვნის. მისი ამ სამიდან რომელიმედ წაკითხვა იძლევა თავდაჯერებულ პასუხებს, რომლებიც სხვადასხვა გზით მცდარია.
მნიშვნელობა სერვერიდან მოდის, გვირაბიდან არა
PHP მოთხოვნის გარემოს იღებს იმისგან, რამაც სკრიპტი შეასრულა. PHP-ის სერვერის ცვლადების ცნობარი ამ ჩანაწერებს ვებ სერვერის მიერ შექმნილებად აღწერს, ხოლო მათი ხელმისაწვდომობა დამოკიდებულია იმაზე, თუ როგორ ჩამოვიდა მოთხოვნა.
VPN-ის ბრძანების ხაზის hook-ად გაშვებული სკრიპტი სრულიად სხვა შესრულების კონტექსტია. მას არ აქვს ვებ მოთხოვნა, კლიენტის სოკეტი და REMOTE_ADDR, ამიტომ hook-ში კოპირებული ვებ კოდი ცარიელ მნიშვნელობებს იძლევა არასწორის ნაცვლად. Hook-ს აქვს საკუთარი გარემო, რომელსაც დემონი ავსებს და ის ცალკეა დოკუმენტირებული. იქ REMOTE_ADDR-ისკენ გაწვდომა ნიშნავს იმ ცვლადისკენ გაწვდომას, რომელიც არასდროს დაყენებულა.
ეს განსხვავება გაითვალისწინეთ სანამ ორ ჟურნალს შეადარებთ. შეიძლება გვერდის მოთხოვნას hook-ს ადარებთ და ეს საერთოდ არ არის შედარება. ჯერ შესრულების კონტექსტი შეამოწმეთ, შემდეგ მისამართი.
გაიარეთ მოთხოვნის გზა სანამ ნომერს ენდობით
მოხსენებული მისამართი არის იმ კავშირის peer, რომელიც ვებ სერვერმა დაინახა. ჩასვით რამე კლიენტსა და ამ სერვერს შორის და peer შეიცვლება. თარგმანი, ტერმინაცია და დატვირთვის ბალანსირება თითოეული დაკვირვებას ერთი ნაბიჯით აშორებს მომხმარებელს.
ოთხი ჩვეულებრივი გზა იძლევა ოთხ სხვადასხვა დაკვირვებას.
| Path to the listener | What can be reported |
|---|---|
| Client routed straight to the private listener, no translation | The client's tunnel address |
| Gateway translates the source before forwarding | The gateway's translated address |
| Reverse proxy terminates the client and opens its own backend connection | The proxy's backend address |
| Load balancer in front of two proxies | Whichever hop the server treats as its peer |
ჩაწერეთ გზა დანიშნულების სახელით, მისამართების ოჯახით და ყოველი თარგმანის წერტილით. ამ რუკის გარეშე სწორი და არასწორი მნიშვნელობა ჟურნალის სტრიქონში ერთნაირად გამოიყურება. ორი სტრიქონი დიაგრამა ზოგავს ნახევარ დღეს კამათს.
ჩანაცვლება ხდება მხოლოდ იქ, სადაც კონფიგურირებულია
სერვერს ან ფრეიმვორკს შეუძლია განზრახ შეცვალოს კლიენტის მისამართი. Apache-ის remote-IP მოდული და NGINX-ის real-IP მოდული ორივე ამას აკეთებს, ხოლო მნიშვნელობა, რომელსაც PHP იღებს, დამოკიდებულია ამ კონფიგურაციაზე და სკრიპტის დამმუშავებლისთვის გადაცემულ პარამეტრებზე.
ანუ REMOTE_ADDR ყოველთვის არ არის ხელუხლებელი TCP peer. ეს არის peer ისე, როგორც სერვერმა გადაწყვიტა მისი მოხსენება საკუთარი პოლიტიკის გამოყენების შემდეგ. ეს განსხვავება წყვეტს, არის თუ არა მნიშვნელობა მტკიცებულება თუ მორთულობა.
ჰკითხეთ სერვერის მფლობელს, რომელი ველია ავტორიტეტული ამ განლაგებაში და როგორ ინახება საწყისი peer, როცა ჩანაცვლება ხდება. თუ ვერავინ გიპასუხათ, ჟურნალი ჯერ არაფერს ამტკიცებს.
გადამისამართების სათაურებს ნდობით არ წაიკითხოთ
გამომძახებელს შეუძლია თავად გაგზავნოს გადამისამართების სათაურები. მძიმით გამოყოფილი პირველი ჩანაწერის დადასტურებულ მომხმარებლის მისამართად მიღება ნიშნავს გადაწყვეტილებას ენდო ყველას, ვინც უკავშირდება, რაც სათაურის დანიშნულების საპირისპიროა. სათაური აღწერს ჯაჭვს და მხოლოდ სანდო შრეს შეუძლია ამ ჯაჭვის გარანტია.
გამოიყენეთ სერვერის ან ფრეიმვორკის სანდო პროქსების მხარდაჭერა რეალური პროქსი ჯაჭვით და მისცეთ საშუალება, რომ გადააგდოს ამ ჯაჭვის გარეთ არსებული წყაროებიდან მოსული მნიშვნელობები. ხელით დაწერილი ანალიზი არის ადგილი, სადაც ცხოვრობს საინტერესო წარუმატებლობების უმეტესობა.
პროქსის მიერ მოხსენებული მისამართი ასევე არ ცვლის იმ პაკეტის წყაროს, რომელსაც ზემოთ მდგარი ქსელური დამცავი კედელი ხედავს. შეინახეთ HTTP მეტამონაცემები და ქსელური ფილტრაცია ცალკე დაკვირვებებად, რადგან ისინი სხვადასხვა კითხვას პასუხობენ.
გადაწყვეტილებებისთვის გამოიყენეთ აპლიკაციის იდენტობა
მომხმარებლის ჩანაწერებზე წვდომისთვის დაეყრდენით ავთენტიფიცირებულ სუბიექტს და აპლიკაციის ავტორიზაციის წესებს. შიდა მისამართი შეიძლება ხელახლა გამოიყოს და ერთი თარგმნილი მისამართი შეიძლება ასობით ერთდროულ მომხმარებელს წარმოადგენდეს. ამ თვისებებიდან არცერთს მისამართის შემოწმება ვერ გამოასწორებს.
თუ ოპერაციებს სჭირდება მოთხოვნის VPN სესიასთან დაკავშირება, დააკავშირეთ დაკვირვებული მისამართი და დროის ნიშა ავტორიტეტულ სესიის ჩანაწერებთან თქვენს მიერ დოკუმენტირებული თარგმანის მოდელის მიხედვით. ეს იძლევა კავშირს, რომელსაც დაიცავთ; მხოლოდ მისამართი არ იძლევა.
დიაგნოსტიკისთვის ჩაწერეთ საჭირო რამდენიმე ველი მთელი სერვერის მასივის ნაცვლად, რომელიც შეიძლება ატარებდეს სათაურებს და ავთენტიფიკაციის მასალას. სასარგებლო დასკვნა ამბობს, რას ნიშნავს ეს მნიშვნელობა ამ განლაგებაში და არა რომელი მნიშვნელობა ჰგავს ყველაზე მეტად კლიენტს.