მოძრავი ლეპტოპი: სტაბილური სახელი თუ ოფისის ფიქსირებული მისამართი?

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

გამოყავით სამი მოთხოვნა

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

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

აქციეთ სახელი სტაბილურ რამედ

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

dig +short laptop17.corp.example

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

როცა წყაროების ნებადართული სია ნამდვილი შეზღუდვაა

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

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

რას მოითხოვს სინამდვილეში უწყვეტობა

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

ss -tnp state established '( dport = :443 )'

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