გახადეთ IPv4 გადაგზავნა მდგრადი VPN კარიბჭის გადატვირთვის შემდეგ

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

კარიბჭეზე მიღწევა იგივე არ არის, რაც გადაგზავნა

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

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

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

ჰოსტის სახელთა სივრცეში მარშრუტიზებულ კარიბჭეზე ერთი ბრძანება პასუხობს კითხვას: sysctl net.ipv4.ip_forward. როცა შემომავალი და შემდგომი გზა დასახელებულ სახელთა სივრცეში ცხოვრობს, ჰკითხეთ იმ სივრცეს: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. ჰოსტის მნიშვნელობა სახელთა სივრცის მნიშვნელობის შემცვლელი არ არის, და ერთიანობა ჰოსტზე არაფრის მტკიცებულება არ არის.

ყველა მარშრუტიზაციის კონტექსტს არ აქვს იარლიყი, რომელსაც ip netns-ს გადასცემთ. კონტეინერების გაშვების გარემოები და სერვისები ქმნიან სახელთა სივრცეებს, რომლებიც არასდროს არ რეგისტრირდება მეგობრული სახელით, და მათთვის იყენებთ გარემოს შემოწმების ხელსაწყოებს. შეცვალეთ vpn-gw რეალური სახელით ან იმავე კონტექსტს მიღწევადი გარემოს მექანიზმით, და შეწყვიტეთ ჰოსტის დონეზე გამოცნობა.

მიეცით პარამეტრს ერთი მფლობელი

ჩვეულებრივ systemd ჰოსტ-კარიბჭეზე მდგრადი ფორმა არის drop-in ფაილი ადმინისტრატორის მიერ არჩეული სახელით, მაგალითად /etc/sysctl.d/60-vpn-forwarding.conf, რომელიც შეიცავს net.ipv4.ip_forward = 1-ს. ჩაწერეთ ფაილი, შემდეგ ჩატვირთეთ სწორედ ის ფაილი, რომ ცოცხალი მდგომარეობაც შეიცვალოს: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, და შემდეგ უკუკითხვა. ფაილის სახელი მაგალითია და არა დაცული VPN გზა, და წამში მდგომი რიცხვი მნიშვნელოვანია, რადგან მოგვიანებით დალაგებული ფაილები იმარჯვებენ.

უპირატესობა ის ადგილია, სადაც მდგრადობა ჩუმად ირღვევა. შეამოწმეთ როგორც დისტრიბუტივის ჩამტვირთავი, ისე თქვენი drop-in, რადგან procps sysctl --system ბოლოს /etc/sysctl.conf-საც კითხულობს, მაშინ როცა systemd-ის sysctl.d-ის რიგი სრულიად სხვა მიმდევრობაა. გვიანდელმა მინიჭებამ შეიძლება იგივე გასაღები მაშინვე დააბრუნოს, და თქვენი ფაილი სწორი, ხოლო ეფექტური მნიშვნელობა არასწორი დარჩეს. არ გადაწეროთ არსებული ადმინისტრატორის ფაილი ამ კამათის მოსაგებად; იპოვეთ მფლობელი და შეცვალეთ იქ.

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

იცოდეთ, რა ღირს გადამრთველი, სანამ გადაატრიალებთ

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

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

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

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

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

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