მარშრუტი ჰოსტის ბიტების გამო უარყოფილია? იპოვეთ განზრახული პრეფიქსი

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

რაზე უჩივის სინამდვილეში პარსერი

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

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

გაიარეთ მაგალითი ხელით

აიღეთ გვირაბი, რომელმაც უნდა მიაღწიოს 172.20.130.0-ს /20 ნიღბით. /20 მესამე ოქტეტიდან ოთხ ბიტს სესხულობს, ამიტომ ეს ოქტეტი მხოლოდ 16-ის ნაბიჯებით ითვლება: 0, 16, 32 და შემდეგ 240-მდე. მნიშვნელობა 130 ხვდება 128-სა და 143-ს შორის, რაც ნიშნავს, რომ მომცველი ქსელი იწყება 172.20.128.0-დან, და არა 172.20.130.0-დან ბოლო ოქტეტის ნულიზაციით.

წერილობით, ბლოკი გადის 172.20.128.0-დან 172.20.143.255-მდე და შეიცავს 4,096 მისამართს. იგივე მნიშვნელობების არამკაცრ პარსერზე გადაცემა აჩვენებს ჩანაცვლებას, რომელსაც ის თქვენ ნაცვლად გააკეთებდა:

$ python3 -c "import ipaddress; n=ipaddress.ip_network('172.20.130.0/20', strict=False); print(n, n.num_addresses)"
172.20.128.0/20 4096

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

უარყოფილი ხაზი ჩვეულებრივ სამი განზრახვიდან ერთს მალავს, და არჩევა მხოლოდ თქვენ შეგიძლიათ. თუ გვირაბს მთელი ბლოკი სჭირდება, ჩაწერეთ 172.20.128.0/20, კანონიკური ქსელური მისამართი. თუ გვირაბს მხოლოდ 130 სეგმენტი სჭირდება, ნიღაბი არასწორი იყო და 172.20.130.0/24 გულახდილი ფორმაა. თუ სამიზნე ერთი მანქანაა, IPv4 ჰოსტის მარშრუტი /32-ია და ნიღბის არითმეტიკა არ მონაწილეობს.

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

რატომ არასდროს იყო გადაცემა გამოსავალი

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

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

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

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

იკითხეთ წევრი მისამართი და ასევე ერთი ბლოკის გარეთ, რომ შედარება მნიშვნელოვანი იყოს და არა მხოლოდ ერთი დამამშვიდებელი ხაზი:

ip -4 route show 172.20.128.0/20
ip -4 route get 172.20.140.10
ip -4 route get 172.20.200.10

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