რატომ ვერ ატარებს Cloudflare-ის პროქსი OpenVPN-ს ერთ სახელზე

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

ორი სახელი, ორი ტრანსპორტი

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

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

Cloudflare-ის ქსელური პორტების ცნობარი ჩამოთვლის, რომელ პორტებს იღებს ჩვეულებრივი ვებ პროქსი. ეს სია ეხება HTTP-სა და HTTPS-ს ამ პორტებზე, და არა თვითნებურ პროტოკოლებს, რომლებიც შემთხვევით იზიარებენ ერთ რიცხვს.

პორტი პროტოკოლი არ არის

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

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

მხოლოდ-DNS ჩანაწერი მოსაწყენი პასუხია, რომელიც მუშაობს, და სწორედ მას უნდა მივმართოთ პირველად.

ერთ მანქანას მაინც ორი მსმენელი სჭირდება

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

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

სერტიფიკატები მიჰყვებიან იმ კავშირს, რომელსაც იცავენ

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

Cloudflare ამ წყაროს სერტიფიკატს Full (strict) რეჟიმში ენდობა და ის ზოგადად სანდო ბრაუზერის სერტიფიკატი არ არის. თუ ვინმე პირდაპირ ეწვევა მხოლოდ-DNS ჰოსტის სახელს და გაფრთხილებას მიიღებს, ეს შეცვლილი ნდობის გზის მოსალოდნელი შედეგია, და არა მტკიცება, რომ დაშიფვრა შეწყდა.

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

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

გამოვლენა სახელს მიჰყვება

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

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

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

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