დომენური ფრონტინგი VPN არ არის: ორი სახელი, ერთი მოთხოვნა
ორი სახელი ერთ HTTPS მოთხოვნაში გვირაბი არ არის. ფრონტინგი დამოკიდებულია პროვაიდერის მარშრუტიზაციის წესებზე; VPN ირჩევს, რომელი პაკეტები მიდის. დახაზეთ ისინი ცალ-ცალკე.
ეს ორი ტექნიკა ერთად ინახება, რადგან ორივე შუამავალს მოიცავს და ორივე დამალვას ჰგავს. თუმცა ისინი სხვადასხვა ობიექტზე მუშაობს. დომენური ფრონტინგი ეხება იმას, რომელი სახელი ჩნდება ერთი HTTPS მოთხოვნის რომელ შრეზე. VPN ეხება იმას, რომელი პაკეტები მიდის გარკვეული გზით პირამდე. ფრონტინგის VPN-ის სახეობად წოდება იწვევს დიზაინებს, რომლებიც ვერ იმუშავებს, და მიმოხილვებს, რომლებიც არასწორ კითხვას სვამს.
ორი სახელი, ორი შრე
TLS კავშირს შეუძლია თავის ხელის ჩამორთმევაში სერვერის სახელი ატაროს. როცა კავშირი არსებობს, HTTP მოთხოვნა იდენტიფიცირებს სასურველ ავტორიტეტს, ჩვეულებრივ Host სათაურში. ეს ორი ველია, რომლებსაც ორ სხვადასხვა მომენტში ორი სხვადასხვა პროგრამული ნაწილი კითხულობს.
| Layer | What carries the name | Who reads it |
|---|---|---|
| TLS handshake | Server name indication | The TLS terminator in front of the service |
| HTTP request | Authority or Host header | The routing layer that picks a backend |
| Network path | Destination address and port | Routers, and the VPN peer if one is in use |
დომენური ფრონტინგი იყენებს პირველ ორს შორის განსხვავებას, რათა ფრონტინგ სერვისმა კავშირი მიიღოს და შემდეგ მოთხოვნა სხვაგან გადამისამართოს. ის მუშაობს მხოლოდ იქ, სადაც ეს სერვისი მზადაა მისი გადამისამართებისთვის, და ეს პროვაიდერის პოლიტიკის საკითხია და არა პროტოკოლური ხრიკი.
ფრონტინგი დამოკიდებულია პროვაიდერზე და არა ტექნიკაზე
შეზღუდული მაგალითისთვის, Front Door-ის ხშირად დასმული კითხვები Azure-ის გზამკვლევი აღწერს დომენური ფრონტინგისგან დაცვას. მასში აღწერილია დაშვებული შეუსაბამობა იმავე გამოწერისა და კონფიგურირებული მარშრუტების დომენებისთვის, და 421 Misdirected Request პასუხი, როცა შეუსაბამობის დაცვა მოთხოვნას ბლოკავს.
ეს ერთი დოკუმენტირებული პოლიტიკა ერთდროულად აუქმებს ორივე სლოგანს. არა ყოველი წყვილი განსხვავებული სახელისა მუშაობს, და არც ყოველი შეუსაბამობაა აკრძალული. სხვა სერვისებს აქვთ საკუთარი შემოწმებები, საკუთარი განლაგების მოთხოვნები და საკუთარი შეცდომის კოდები.
ეს ასევე არ არის ინსტრუქცია სხვა ქსელის შეზღუდვების გვერდის ავლისთვის. პროვაიდერის მარშრუტიზაციის წესების კითხვა იმის გასაგებად, თუ რას უშვებს ის, არქიტექტურული სამუშაოა; ამ წესების გვერდის ავლის რეცეპტად მიჩნევა სხვა საქმიანობაა სხვა შედეგებით. ეს ორი საქმიანობა ცალ-ცალკე შეინახეთ იმ დოკუმენტში, რომელსაც წერთ. მეორეა ის, რის გამოც დიზაინი მიმოხილვაში უარყოფილია.
რას ირჩევს VPN სინამდვილეში
ქსელურ VPN-ში მარშრუტიზაცია და პლატფორმის პოლიტიკა ირჩევს შიდა ტრაფიკს პირამდე გვირაბისთვის. განლაგებიდან გამომდინარე ამან შეიძლება დაფაროს რამდენიმე აპლიკაცია ან განსაზღვრული ქვესიმრავლე, და შეიძლება ატაროს პროტოკოლები, რომლებსაც საერთოდ არ აქვთ HTTP მოთხოვნა.
ფრონტინგი ამათგან არაფერს აკეთებს. ერთი HTTPS მოთხოვნის ფრონტინგ სერვისით მოწყობა არ აყენებს კერძო ქსელის მარშრუტს, არ ატარებს თვითნებურ UDP აპლიკაციებს და არ აიძულებს მოწყობილობის ყოველ პროგრამას გამოიყენოს სერვისი. თუ ეს დაფარვა გჭირდებათ, გჭირდებათ პროქსი ან გვირაბი და არა სახელის ხრიკი.
ამიტომაც ერევა ეს ორი მიმოხილვაში: ორივე შუამავლად აღიწერება და ორივე ჩნდება წვდომის შესახებ დოკუმენტებში. ინტერფეისი, რომელსაც თითოეული გვთავაზობს, სრულიად განსხვავებულია, და მხოლოდ ერთი მათგანია ქსელური გზა.
ხილვადობა ორობითი არ არის
შედარება ასევე არ არის უბრალოდ დამალული წინააღმდეგ ხილვადი. DNS მოთხოვნები, დანიშნულების მისამართები, ხელის ჩამორთმევის მახასიათებლები, პაკეტების ზომები და დრო ყველა დაკვირვებადი რჩება მათთვის, ვინც იმ პოზიციაზეა, რომ დაინახოს, და რასაც ის დამკვირვებელი სწავლობს, დამოკიდებულია იმაზე, სად ზის.
აპლიკაციის მონაცემები ასევე ჩანს იმ ბოლო წერტილებში, რომლებიც ამთავრებენ მათ. ფრონტინგ სერვისი, რომელიც თქვენს მოთხოვნას მარშრუტიზაციას უკეთებს, ერთ-ერთი ასეთი წერტილია, VPN პირი კი მეორე. არც ერთი განლაგება არ ხდის შიგთავსს გაუმჭვირვალეს იმ მხარისთვის, რომელმაც ის უნდა წაიკითხოს, რომ მოგემსახუროთ.
დახაზეთ სამი ყუთი
არქიტექტურული მიმოხილვისთვის დახაზეთ TLS-ის ბოლო წერტილი, HTTP მარშრუტიზაციის სერვისი და საბოლოო აპლიკაცია სამ ცალკე ყუთად, შემდეგ კი დახაზეთ ნებისმიერი VPN პირი კვლავ სხვაგან. ადგილი, რომელიც ირჩევს ვებ დანიშნულებას, და ადგილი, რომელიც კერძო ქსელის პაკეტებს გადაადგილებს, არ უნდა იყოს ერთი და იგივე სისტემა, და ჩვეულებრივ არც არის.
როცა ყუთები ცალკეა, კითხვები პასუხისმგებელი ხდება: რომელ სახელებს იღებს ეს პროვაიდერი, რომელ პროტოკოლებს სჭირდებათ გადაზიდვა და რომელი მხარე რას ხედავს. დიაგრამა, რომელიც მათ აერთიანებს, ქმნის დიზაინს, რომელსაც ვერავინ განახორციელებს, და მიმოხილვას, რომელიც ლექსიკაზე კამათობს.