VPN-ის დომენის წესი ირღვევა, როცა CDN თავის მისამართებს ცვლის

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

რატომ არ არის ერთი მოთხოვნა ინვენტარი

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

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

მესამე ხარვეზი მისამართების ოჯახია. მხოლოდ v4-ის წესი არაფერს ამბობს AAAA ჩანაწერზე, რომელიც კლიენტმა შეიძლება ამჯობინოს.

სამი პირობა, რომლებიც წყვეტენ დომენის წესს თუ დიაპაზონებს

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

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

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

სცადეთ სესია და არა გვერდი

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

ჩამოთვალეთ, რასთან ამყარებს სესია რეალურად კავშირს და არა რას აჩვენებს გვერდი:

dig +short example.com A
dig +short example.com AAAA
curl -sI https://example.com | head -5

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

რას ფარავს რეალურად თითოეული მექანიზმი

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

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

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

სერვისის შეცვლის შემდეგ ხელახლა შეამოწმეთ

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

ჩაწერეთ, რომელი მექანიზმი ფარავს რომელ ჰოსტის სახელს, და ბოლო შემოწმების თარიღი.

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