IPv6 გასასვლელი იღუპება OpenVPN-ის გადატვირთვის შემდეგ: შეამოწმეთ პრეფიქსის მფლობელობა
IPv6 იღუპება გვირაბის ხელახალი შექმნის შემდეგ. სანამ რამეს გადატვირთავთ, გადაწყვიტეთ ვის ეკუთვნის დელეგირებული პრეფიქსი, კლიენტის მისამართები და დაბრუნების მარშრუტი.
IPv6 წყვეტს ტრაფიკის გატარებას იმ მომენტში, როცა OpenVPN გადაიტვირთება, და IPv4 აგრძელებს მუშაობას. გვირაბის ინტერფეისი ხელახლა შეიქმნა, და სხვა რაღაც, რაც მის IPv6 მდგომარეობას მართავდა, დაკარგა ან მისამართი, ან მარშრუტი, რომელიც პრეფიქსს ხელმისაწვდომს ხდის. ჩართულია მდგომარეობის სამი ცალკე ნაწილი, და თითოეულს განსხვავებული მფლობელი ჰყავს: პროვაიდერის დელეგირებული პრეფიქსი და მისი სიცოცხლის ხანგრძლივობა, VPN კლიენტებისთვის მიცემული მისამართები, და ზედა მარშრუტი, რომელიც ამ კლიენტის პრეფიქსს სერვერზე აბრუნებს. დაადგინეთ თითოეულის მფლობელი, სანამ რომელიმე დემონს შეეხებით, რადგან არასწორის გადატვირთვა პრობლემას დღით მალავს და შემდეგ კავშირზე აბრუნებს.
IPv6 მდგომარეობის სამი ნაწილი, სამი მფლობელი
| State | Typical owner | What breaks when it is wrong |
|---|---|---|
| Delegated prefix and lifetime | Upstream router or provider via DHCPv6-PD | Clients keep addresses that the upstream no longer routes |
| Client addresses inside the tunnel | OpenVPN server config or a delegation daemon | No global address, or an address outside the routed prefix |
| Return route for the client prefix | Upstream router, or the server's own routing table | Outbound works, replies never arrive |
გლობალური მასშტაბის მისამართი გვირაბის შიგნით თავისთავად საკმარისი არ არის. ზედა როუტერებმა მაინც უნდა გაგზავნონ ეს პრეფიქსი უკან VPN სერვერისკენ, და ისინი ამას არ გააკეთებენ მხოლოდ იმიტომ, რომ სერვერს შემთხვევით აქვს მისამართი მისგან.
ამიტომაც არის საშიში საჯარო /64-ის გვირაბის აუზში კოპირება. სერვერზე მიმართული პრეფიქსი არ არის იგივე, რასაც ზედა მხარე on-link-ად თვლის, და მეზობლების აღმოჩენა ამ ხარვეზს არ შეავსებს.
წაიკითხეთ სერვერის მდგომარეობა, სანამ რამეს შეცვლით
დააფიქსირეთ მდგომარეობა ორჯერ, ერთხელ სანამ IPv6 მუშაობს და ერთხელ გადატვირთვის შემდეგ, შემდეგ შეადარეთ. მხოლოდ წასაკითხი ხედები საკმარისია, და ტექნიკური მომსახურების ფანჯრის დროს არაფერი ღირს:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingმოძებნეთ სამი კონკრეტული განსხვავება: გამქრალი მარშრუტი, მოძველებულ ან არასწორ სიცოცხლის ხანგრძლივობაზე გადასული მისამართი, და პრეფიქსი, რომელიც ხელახალი დელეგირების შემდეგ შეიცვალა, მაშინ როცა VPN კონფიგურაცია ჯერ კიდევ ძველს აცხადებს.
თუ მისამართი გაქრა, მაგრამ პრეფიქსი არ შეცვლილა, მისი მიმნიჭებელი დემონი ინტერფეისის მართვას შეწყვიტა. თუ პრეფიქსი შეიცვალა, მაგრამ მისამართები არა, კლიენტის კონფიგურაცია მოძველებულია. ორი ხარვეზი ბრაუზერიდან ერთნაირად გამოიყურება და საერთო არაფერი აქვთ.
გადაწყვიტეთ, უნდა მართავდეს თუ არა dhcpcd გვირაბს
dhcpcd-ს შეუძლია ინტერფეისების აღმოჩენა და DHCPv6 პრეფიქსის ნაწილების ქვედა ინტერფეისებზე დელეგირება, და მის კონფიგურაციას შეუძლია დელეგირების სამიზნეების ცალსახად დასახელება. ცალსახა სამიზნის გარეშე, მისი დოკუმენტირებული ქცევა შეიძლება სხვა ინტერფეისებსაც მოიცავდეს, და ასე ხვდება გვირაბს ისეთი მისამართი, რომელიც არავის დაუგეგმავს.
ორმა პირობამ უნდა გიბიძგოთ იმისკენ, რომ გვირაბის სტატიკური ადრესიზაცია OpenVPN-ს დაუტოვოთ: სერვერი თავის კონფიგურაციაში ფიქსირებულ მისამართებს უბიძგებს, და გვირაბის სახელი ხელახალი შეერთებისას იცვლება. თუ ორივე სწორია, განზრახ გამორიცხეთ გვირაბი დელეგირების დემონიდან, კომენტარით, რომელიც მიზეზს განმარტავს.
თუ პირიქით, გვირაბზე დელეგირება განზრახ ხდება, დანერგეთ პრეფიქსის ცვლილების დამუშავება. ეს ნიშნავს რეაგირებას, როცა დელეგირებული პრეფიქსი ან მისი სიცოცხლის ხანგრძლივობა იცვლება, სერვერის მიერ გამოცხადებული კლიენტის პრეფიქსის განახლებას, და მარშრუტის ხელახლა დამატებას. ამ დიზაინში ინტერფეისის გამორიცხვა აშორებს ერთადერთ კომპონენტს, რომელმაც იცის ახალი პრეფიქსის შესახებ.
dhcpcd-ის გადატვირთვა შეიძლება ისე გამოიყურებოდეს, თითქოს ყველაფერს ასწორებს, რადგან მდგომარეობას ხელახლა ქმნის, მაგრამ ის ასევე აახლებს ან აუქმებს კონფიგურაციას იმ ინტერფეისებისთვის, რომლებზეც არ გიფიქრიათ. ასეთი აღდგენა მას სავალდებულოს არ ხდის ყოველი VPN გადატვირთვის შემდეგ. ის ასევე აბრუნებს ნულზე იმ მრიცხველებს, რომლებსაც მტკიცებულებად იყენებდით. უპირატესობა მიანიჭეთ იმ ინტერფეისის მიზანმიმართულ გადატვირთვას, რომელიც ნამდვილად შეცვალეთ.
შეამოწმეთ IPv6 IPv4 NAT-ისგან ცალკე
დარწმუნდით, რომ გადაგზავნა ჩართულია და ზედა მარშრუტი რეალურ კლიენტის პრეფიქსზე მიუთითებს, შემდეგ შექმენით ახალი ნებადართული IPv6 კავშირი. შეამოწმეთ კლიენტის საკუთარი IPv6 მარშრუტების ცხრილიც, რადგან საჯარო მისამართის მქონე კლიენტი არ ამტკიცებს, რომ მისი მოთხოვნა გვირაბს იყენებდა.
IPv4-ის ნიღაბი სხვა პრობლემას წყვეტს: დაბრუნების გზას კერძო წყაროებისთვის. ის არაფერს აკეთებს უკან გატანილი IPv6 პრეფიქსისთვის, და მისი დამატება IPv6-ს არ დააბრუნებს.
დაასრულეთ მფლობელობის ჩანაწერით: რომელი კომპონენტი დელეგირებს პრეფიქსს, რომელი ანიჭებს კლიენტის მისამართებს, რომელი ფლობს დაბრუნების მარშრუტს, და რა ემართება თითოეულს ხელახალი შეერთებისას. ოთხი სტრიქონი runbook-ში იხსნის შემდეგ ადამიანს სამი დემონის გადატვირთვისგან, რათა იპოვოს ის, რომელსაც მნიშვნელობა ჰქონდა.