რატომ სჭირდება გაზიარებულ TAP VPN-ს კვლავ HTTPS პორტალზე
TAP VPN ამოწმებს პარტნიორს და არა მის უკან არსებულ სერვისს. შეინარჩუნეთ ჰოსტის სახელის ვალიდაცია პორტალზე და გამოყავით მეზობლები, რომლებსაც არ ენდობით.
ორ მოწყობილობას აქვს ვალიდური VPN-ის სერთიფიკატები და იზიარებს ერთ დახიდულ Ethernet სეგმენტს. მათგან მხოლოდ ერთმა უნდა უპასუხოს ოფისის პორტალს, ხოლო მეორეს კვლავ შეუძლია პორტალის მისამართის მოთხოვნა ამ სეგმენტზე. გვირაბმა თავისი საქმე გააკეთა: მან ორივე პარტნიორი ამოიცნო და სერვერამდე ყოველი გზა დაშიფრა. რაც არ გააკეთა, არის იმის დამოწმება, რომელ მათგანს ეკუთვნის სერვისის სახელი, და სწორედ ეს ხარვეზია მიზეზი, რომ პორტალს კვლავ ვალიდური სერთიფიკატი სჭირდება.
რას ამოწმებს VPN სინამდვილეში
VPN-ის ხელის ჩამორთმევა ერთ კითხვას პასუხობს: რომელმა პარტნიორმა დაასრულა ეს გვირაბი და რა გასაღების მასალით. ეს პასუხი თითო პარტნიორზე და თითო კავშირზეა და არაფერს ამბობს იმ სერვისებზე, რომლებსაც ეს პარტნიორი შემდეგ ავლენს. TAP სეგმენტზე პარტნიორი ერთი მისამართიც არ არის, რადგან მას შეუძლია წარმოადგინოს ნებისმიერი MAC და ნებისმიერი IP, რომლის სწავლაც ხიდს სურს. ავთენტიფიკაცია გვირაბის ბოლო წერტილში ჩერდება და არა აპლიკაციაში.
გაყავით სამი კითხვა ერთში შერწყმის ნაცვლად. თითოეულს თავისი მექანიზმი და თავისი მარცხის რეჟიმი აქვს.
| Question | Answered by |
|---|---|
| Which peer sent this packet? | VPN transport authentication |
| Which device owns this IPv4 address? | ARP, trusted only as far as the segment |
| Which service am I talking to? | Application TLS and hostname validation |
განლაგებას შეიძლება ჰქონდეს სრულყოფილად ავთენტიფიცირებული გვირაბი და მის უკან სრულიად არაავთენტიფიცირებული სერვისი. მას ასევე შეიძლება ჰქონდეს ვალიდირებული სერთიფიკატი ჰოსტზე, რომლის მეორე დონის მისამართსაც სხვა პარტნიორი ითხოვს, და ამიტომ დიზაინში ორივე კონტროლი უნდა იყოს და არა ერთი მეორის ნაცვლად. ცხრილი მთელი არგუმენტია სამ რიგში.
ARP გაზიარებულ სეგმენტზე საძიებო არ არის
ARP აკავშირებს IPv4 მისამართს MAC-თან ლოკალურ ბმულზე და იღებს პასუხებს ნებისმიერისგან ამ ბმულზე. დაშვებულ დახიდულ სეგმენტზე პარტნიორს შეუძლია მოითხოვოს სხვა მოწყობილობის კუთვნილი მისამართი, და ხიდი კადრებს უგზავნის მას, ვინც ბოლოს უპასუხა. თითო კლიენტის გზის დაშიფვრა სერვერამდე ამას არ ცვლის, რადგან კადრები ხიდამდე მისვლამდე გაშიფრდება. ARP-ის ნდობის საზღვარი სეგმენტია და არა გვირაბი.
ნახეთ, რა ისწავლა ჰოსტმა სინამდვილეში: ip neigh show ჩამოთვლის მიმდინარე დაკავშირებებსა და მათ მდგომარეობას, და ჩანაწერი, რომელიც ნორმალური მუშაობის დროს ორ MAC მისამართს შორის იცვლება, სიმპტომია, რომელიც გამოკვლევას იმსახურებს და არა უგულებელყოფას. ჯანსაღ პატარა სეგმენტზე ასეთი ჩანაწერები დიდხანს სტაბილური რჩება.
პარტნიორების იზოლაცია და ხიდის პოლიტიკა ზუსტად ამ შემთხვევისთვის არსებობს. მარშრუტიზებული დიზაინი ჩვეულებრივ უკეთესი პასუხია, როცა სერვისი მხოლოდ IP არის და მოწყობილობებს ერთმანეთის კადრების დანახვის არავითარი მიზეზი არ აქვთ.
შეინარჩუნეთ სერთიფიკატის ვალიდაცია იქ, სადაც სერვისია
აპლიკაციის TLS პასუხობს კითხვას, რომელზეც გვირაბი ვერ უპასუხებს: არის ეს ის სერვისი, რომლამდეც მსურდა მისვლა? ბრაუზერი ამოწმებს ჰოსტის სახელს სერთიფიკატის მიმართ და ეს შემოწმება ჯაჭვის ერთადერთი ნაწილია, რომელიც პორტალს ასახელებს და არა პარტნიორს.
შეამოწმეთ, რას წარმოადგენს სერვერი, სანამ გადაწყვეტთ, რომ გაფრთხილება კოსმეტიკურია. openssl s_client -connect portal.example.internal:443 -servername portal.example.internal ბეჭდავს ჯაჭვს და სუბიექტის ალტერნატიულ სახელებს. თუ შეყვანილი სახელი ამ სიაში არ არის, გაფრთხილება სწორია და სერთიფიკატია ის, რაც უნდა გასწორდეს. მომხმარებლებისთვის მისი გამოტოვების სწავლება მოქმედ კონტროლს დეკორაციად აქცევს.
OpenVPN-ის ხიდირების გზამკვლევი აღწერს Ethernet მოდელს და მის გარშემო არსებულ პოლიტიკის ვარიანტებს, და ეს არის სწორი წყარო იმისა, თუ რას უნდა დაუშვას სეგმენტმა. წაიკითხეთ იგი ხიდის წესის შესუსტებამდე, რადგან აღწერილი მოდელი არის ის, რასაც ზემოთ მოცემული ყოველი შემოწმება ვარაუდობს.
გადაწყვიტეთ, საერთოდ უნდა გაიზიარონ თუ არა ამ პარტნიორებმა სეგმენტი
ყველაზე იაფი გამოსწორება ჩვეულებრივ მეორე დონის გაზიარების შეწყვეტაა, როცა მოთხოვნა მხოლოდ IP-ის ხელმისაწვდომობაა. მარშრუტიზებული VPN თითოეულ კლიენტს საკუთარ მისამართს აძლევს, შლის გაზიარებულ მაუწყებლობის დომენს და პარტნიორებს შორის ტრაფიკს პოლიტიკის გადაწყვეტილებად აქცევს ნაგულისხმევის ნაცვლად. მაშინ პორტალს ერთი დასაცავი მისამართი აქვს და არც ერთი მეზობელი, რომელსაც მისი მოთხოვნა შეუძლია.
თუ სეგმენტი უნდა დარჩეს, შეამოწმეთ სერვერის მხარის პარამეტრი, რომელიც კლიენტებს ერთმანეთამდე მისვლის საშუალებას აძლევს: grep -n client-to-client /etc/openvpn/server.conf. როცა ის გამორთულია, კლიენტური ტრაფიკი სერვერზე გადის და იქ შეიძლება გაფილტვრა. როცა ის ჩართულია, პარტნიორები კადრებს უშუალოდ ხიდის გავლით ცვლიან, და თქვენი ფილტრაციის წერტილები ხიდი და ჰოსტის ცეცხლოვანი კედელია.
ჩაწერეთ, რომელ დაცვებს ეყრდნობა სინამდვილეში თითოეული ჰოსტი: გვირაბის ავთენტიფიკაცია, სეგმენტის იზოლაცია თუ აპლიკაციის TLS. ჰოსტი, რომელიც სამივეს ეყრდნობა, რიგშია. ჰოსტი, რომელიც პირველს ეყრდნობა და ვარაუდობს, რომ დანარჩენი ორი მასთან ერთად მოვიდა, არის ის, რომელიც საბოლოოდ არასწორ შიგთავსს აწვდის.