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

რატომ შეწყვიტა წესმა შესაბამისობა

RFC 4941 აღწერს დროებით მისამართებს: ჰოსტი ქმნის დამატებით მისამართებს შემთხვევითი იდენტიფიკატორებით და აუქმებს მათ, რაც დამკვირვებელს არ აძლევს საშუალებას ერთი ჰოსტი ვიზიტებს შორის დააკავშიროს. Windows ახორციელებს ამ ქცევას, ამიტომ გუშინდელი წყაროს მისამართი სულაც არ არის დღევანდელი. პროგნოზირებადი მისამართი კვლავ არსებობს ინტერფეისზე; უბრალოდ, ეს არ არის ის, რომელსაც გამავალი კავშირი ანიჭებს უპირატესობას.

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

ვარიანტი პირველი: ერთი სტაბილური მისამართი, ნაკლები კონფიდენციალურობა

ჩვეულებრივი შეკეთება გამორთავს ორივე ბრუნვის მექანიზმს ჰოსტზე: netsh interface ipv6 set privacy state=disabled store=persistent და netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent. დაამატეთ store=active, თუ გსურთ ცვლილება ძალაში შევიდეს გადატვირთვის მოლოდინის გარეშე, და მიიღეთ, რომ ახლა იდენტიფიკატორი ქსელებს შორის პროგნოზირებადი გახადეთ.

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

ვარიანტი მეორე: დაუშვით პრეფიქსი ან სახელი

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

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

ვარიანტი მესამე: დაე, გვირაბმა მიუნიშნოს მისამართი

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

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

აირჩიეთ თვალთვალის ხარჯის გათვალისწინებით

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

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

დაკავშირებული სტატიები