როგორ აღწევს საჯარო პროქსი კერძო საწყისამდე VPN-ის გავლით

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

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

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

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

სად ჩერდება TLS და რას ამტკიცებს ის სინამდვილეში

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

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

ენდეთ გადაცემულ სათაურებს მხოლოდ პროქსისგან

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

curl -s -o /dev/null -w '%{http_code}
' -H 'X-Forwarded-For: 203.0.113.9' http://172.20.5.40/

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

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

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

ss -ltnp | grep -E ':(80|443)'

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