განაახლებს თუ არა Pi-ის კარიბჭის ჰოსტის სახელი სტატიკურ მარშრუტებს დამოუკიდებლად?

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

DNS პასუხი და მარშრუტი სხვადასხვა ობიექტია

ვთქვათ, თქვენი Pi პასუხობს vpn-gw.lan-ს და 10.44.0.0/16-ს გადასცემს გვირაბს. 192.168.30.0/24-ის კლიენტები მას სტატიკური მარშრუტით აღწევენ. როცა Pi-ის მისამართი 192.168.30.4-დან 192.168.30.11-ზე გადავიდა, ჩანაწერი თავის TTL-ში გაჰყვა, მარშრუტები კი არა.

ორი ხედვა იმგვარად ეწინააღმდეგება ერთმანეთს, რომ ადვილად გამორჩენადია, რადგან ცალ-ცალკე კითხვისას ორივე დამაჯერებლად გამოიყურება:

$ ip route get 10.44.0.1
10.44.0.1 via 192.168.30.4 dev eth0 src 192.168.30.20
$ dig +short vpn-gw.lan
192.168.30.11

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

რა რჩება ცხრილში ბრძანების დასრულების შემდეგ

Linux-ის მარშრუტი ორ რამეს იწერს, რაც აქ მნიშვნელოვანია: შემდეგ ნახტომს როგორც პროტოკოლის მისამართს, და გამავალ ინტერფეისს როგორც ინდექსის ნომერს. rtnetlink-ის მარშრუტის ატრიბუტები უწოდებენ ამ პირველ ველს RTA_GATEWAY-ს, და ის ინახავს ბაიტებს. როგორც კი ჩანაწერი ადგილზეა, მასზე არც TTL არის მიმაგრებული და არც ფონური ძიება აახლებს.

ამიტომ ip route add 10.44.0.0/16 via vpn-gw.lan შეიძლება მუშაობდეს. ინსტრუმენტი ხსნის სახელს ბრძანების გაშვებისას, წერს მიღებულ მისამართს და სახელს სრულიად ივიწყებს. ამის შემდეგ გაუშვით ip route show 10.44.0.0/16 და უკან ლიტერალურ მისამართს მიიღებთ.

ამ ქცევის ცოდნა ღირს სანამ გვირაბს დაადანაშაულებთ.

ინსტრუმენტები, რომლებიც სახელს თქვენ ნაცვლად ხსნიან, და როდის

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

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

მონიტორინგით განახლება სხვა ლეგიტიმური ნიმუშია, და მას მფლობელი სჭირდება.

მიამაგრეთ მისამართი ან თვითონ გაუშვით განამახლებელი

პატარა LAN-ისთვის DHCP სერვერზე დაჯავშნა ყველაზე იაფი გადაწყვეტაა. აირჩიეთ მისამართი დინამიკური აუზის გარეთ, მიაბით ის Pi-ის MAC მისამართს და დაადასტურეთ ip -4 addr show dev eth0-ით შემდეგი იჯარის განახლების შემდეგ. შემდეგ მიმართეთ კლიენტების შემდეგი ნახტომი ერთხელ ამ მისამართზე. ახლა გაქვთ სტაბილური კარიბჭე და ჩანაწერი, რომელიც მას აღწერს, და ეს არის ის რიგი, რომლითაც ეს კავშირი რეალურად მუშაობს.

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

new=$(dig +short vpn-gw.lan | head -n1)
cur=$(ip route get 10.44.0.1 | awk '{print $3}')
if [ "$new" != "$cur" ]; then
  ip route replace 10.44.0.0/16 via "$new"
fi
ip route get 10.44.0.1

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

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