რატომ ტოვებს net.ipv4.conf.default.forwarding tun0-ს უცვლელად

თქვენ დააყენეთ net.ipv4.conf.default.forwarding=1, გადატვირთეთ VPN და გვირაბი კვლავ ყრის პაკეტებს, რომლებიც კარიბჭეს უნდა მარშრუტიზებდეს. პარამეტრი ფაილში სწორად გამოიყურება და ინტერფეისი კვლავ იტყობინება, რომ გადაცემა გამორთულია. არაფერი გატეხილა: თქვენ შეცვალეთ მნიშვნელობა, რომელსაც მომავალი ინტერფეისები მიიღებენ მემკვიდრეობით და არა ის, რომელსაც მოქმედი გვირაბი იყენებს.

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

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

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

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.default.forwarding
sysctl net.ipv4.conf.tun0.forwarding

ჩვეულებრივი შედეგია ip_forward = 0, default.forwarding = 1 და tun0.forwarding = 0. პირველი ორი არ ეთანხმება ერთმანეთს ჰოსტის როლის შესახებ, ხოლო მესამე გვიჩვენებს, რას აკეთებს ინტერფეისი სინამდვილეში. ეს კომბინაცია შეესაბამება ჰოსტს, რომელიც არასდროს დაყენებულა მარშრუტიზატორად და მხოლოდ შაბლონური მნიშვნელობა მიუღია. სამი რიცხვი ერთმანეთს არ ეწინააღმდეგება; ისინი სამ სხვადასხვა კითხვას პასუხობენ. შაბლონური მნიშვნელობის ჩაწერა არც ჰოსტის როლს წყვეტს.

რატომ მოძრაობს სწორედ გლობალური გადამრთველი

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

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

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

გახადეთ პარამეტრი მუდმივი სწორ ადგილას

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

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

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

ნუ შეაკეთებთ ამას არასწორი იარაღით

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

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

გამოყავით IPv6 შემთხვევა

აქ ყველაფერი IPv4-ია. IPv6 გადაცემას, მარშრუტიზატორის განცხადებებს და accept_ra ქცევას საკუთარი მართვა აქვთ და ipv4 გზის ipv6 პარამეტრში კოპირება ქმნის ფაილს, რომელიც დამაჯერებლად გამოიყურება და სასარგებლო არაფერს აკეთებს. ორმაგი სტეკის კარიბჭეს ორივე ნაკრების განზრახ კონფიგურაცია სჭირდება.

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