IPv6 პრეფიქსის დელეგირება საიტებს შორის VPN-ში: შემოწმების სია
დელეგირებული IPv6 პრეფიქსის საიტებს შორის VPN-ის გავლით მარშრუტიზაციის შემოწმებები: პრეფიქსის რუკა, ტრაფიკის სელექტორები, გადამისამართება, MTU, დაბრუნების გზა და ხელახალი ნუმერაცია.
გვირაბის აწევა მარტივი ნახევარია. მინახავს საიტებს შორის კავშირი, რომელიც დღეების განმავლობაში დამყარებული რჩებოდა, მაშინ როცა შორეულ LAN-ში ყველა ჰოსტი სიჩუმეს იღებდა, რადგან ამ გეითვეის უკან არსებული დელეგირებული პრეფიქსი ინტერფეისზე იყო კონფიგურირებული, მაგრამ გვირაბში არასოდეს იყო მარშრუტიზებული. გვირაბის მისამართები მთელი დროის განმავლობაში პასუხობდა ping-ებს და სწორედ ამიტომ არავინ უყურებდა პრეფიქსს. აი რიგი, რომელსაც ვამოწმებ, როცა დელეგირებულმა IPv6 პრეფიქსმა საიტის VPN უნდა გადაკვეთოს: პრეფიქსის რუკა, ტრაფიკის სელექტორები, გადამისამართება და firewall, შემდეგ დაბრუნების გზა.
პრეფიქსის რუკა დაწერე, სანამ გვირაბს შეეხები
პრეფიქსის დელეგირება ბლოკს გადასცემს იმ როუტერს, რომელმაც მოითხოვა. ის არ აყენებს მარშრუტს პირზე, არ ავრცელებს ამ ბლოკს on-link-ად და არ ეუბნება შორეულ გეითვეის, რა დგას მოთხოვნის როუტერის უკან. ეს სამი თქვენ უნდა დააკონფიგურიროთ და ისინი მისამართების გეგმაში უნდა იყოს ნებისმიერი კონფიგ ფაილის შეცვლამდე.
თითოეული საიტისთვის ჩაწერეთ დელეგირებული პრეფიქსი, LAN-ზე რეალურად გამოყენებული /64, გვირაბის მისამართები და თითოეული მარშრუტის მფლობელი. პროვაიდერი საიტ A-ს ანიჭებს 2001:db8:a1::/56-ს, რომელიც თავის LAN-ზე ემსახურება 2001:db8:a1:10::/64-ს; საიტ B ინარჩუნებს 2001:db8:b2::/64-ს. თუ საიტ A მხოლოდ ამ ერთ /64-ს ემსახურება, ორივე ბოლომ უნდა დაასახელოს 2001:db8:a1:10::/64 და არა მთელი /56.
ორი შეცდომა თითქმის ყოველთვის ჩნდება. ერთია შორეული პრეფიქსის on-link-ად მოპყრობა, მისი ბრიჯვა ან გვირაბის ინტერფეისზე დადება, რათა გეითვეიმ უპასუხოს მეზობლის მოთხოვნას იმ ჰოსტებისთვის, რომლებამდეც ვერ აღწევს. მეორეა მთელი /56-ის გამოცხადება, როცა მხოლოდ ერთი /64 არის კონფიგურირებული: მარშრუტების ცხრილი აცხადებს, რომ ბლოკი მიღწევადია, და მისამართების უმეტესობა შავ ხვრელში ვარდება.
შეუთავსე ორივე ბოლოს ტრაფიკის სელექტორები მარშრუტებს
IKEv2 და WireGuard ორივე უარყოფს შეუთავსებელ ტრაფიკს, საკმარისად ჩუმად, რომ გვირაბი კვლავ ჯანმრთელად გამოიყურებოდეს.
strongSwan-ში სელექტორები აშკარაა. საიტ A-ზე:
conn a-to-b
left=2001:db8:ff::1
leftsubnet=2001:db8:a1:10::/64
right=2001:db8:ff::2
rightsubnet=2001:db8:b2::/64
auto=startსაიტ B-ის conn ასახავს ორ ქვექსელს. როცა ისინი არ ემთხვევა, პასუხისმგებელი უარყოფს CHILD_SA-ს TS_UNACCEPTABLE-ით, ასე რომ child SA არასოდეს ამოდის, თუმცა IKE_SA ამოვიდა. ორივე მხარეს კონფიგურირებული ქვექსელი უნდა უდრიდეს იმას, რასაც ლოკალური kernel მარშრუტიზებს გვირაბისკენ.
WireGuard იგივე ინფორმაციას AllowedIPs-ში ატარებს, ერთი ხრიკით: AllowedIPs არის წყაროს ფილტრი მიღებისას და მარშრუტი გაგზავნისას. თუ საიტ B-ის peer ჩანაწერი საიტ A-სთვის გამოტოვებს 2001:db8:a1:10::/64-ს, საიტ A-დან პაკეტები მოვლენ სწორ handshake-ზე და ჩააგდება როგორც დაუშვებელი. ეს ქმნის ნაცნობ ნიმუშს: handshake მუდმივად ახლდება, პასუხი კი არასოდეს გადის. შეადარე ორივე ბოლო wg show wg0 allowed-ips-ით. გადაამოწმე ეს სია ყოველ ჯერზე, როცა დელეგირება იცვლება; მოძველებული /64 სესიას ცოცხლად ინახავს და ახალ პრეფიქსს მიუწვდომელს ხდის.
ჯერ გამორიცხე გადამისამართება, firewall და MTU
სანამ კიდევ ერთ ლოგის სტრიქონს წაიკითხავ, დაადასტურე, რომ გეითვეები საერთოდ გადასცემენ. sysctl net.ipv6.conf.all.forwarding-მა ორივეზე უნდა დააბრუნოს 1, გამოყენებული გვირაბისა და LAN-ის ინტერფეისებზეც. ერთი ხაფანგიც მოყვება: გადამისამართების ჩართვის შემდეგ accept_ra=1 ინტერფეისი წყვეტს პროვაიდერის როუტერის რეკლამების მიღებას, ასე რომ მოწყობილობამ შეიძლება დაკარგოს აღმავალი ნაგულისხმევი მარშრუტი, თუმცა გვირაბის შიგნით სრულყოფილად მარშრუტიზებს. დააყენე accept_ra=2 იქ, სადაც პროვაიდერის RA კვლავ საჭიროა.
შემდეგ firewall-ის წესებმა პრეფიქსი ორივე მიმართულებით უნდა დაუშვას და ICMPv6-მა უნდა გადარჩეს: მეზობლის აღმოჩენა, packet-too-big და destination-unreachable სავალდებულოა. ჩააგდე ისინი და ბილიკის MTU აღმოჩენა გატყდება, რაც მოგცემს კავშირებს, რომლებიც იხსნება და შემდეგ პირველ დიდ პასუხზე ჩერდება. წესების მინიმალური წყვილი ასე გამოიყურება:
nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } acceptMTU ამის უკან დგას. გვირაბი ამცირებს გამოსაყენებელ MTU-ს 1500-ზე ქვემოთ და IPv6 მოითხოვს, რომ ყველა ბმულმა მინიმუმ 1280 გადასცეს. პატარა ping-ები გადის, SSH სესია იყინება დიდი ნაკადის დროს და /proc/net/snmp6 აჩვენებს packet-too-big შეტყობინებებს, რომლებიც არასოდეს ბრუნდება. დააყენე გვირაბის MTU ცხადად ან შეზღუდე TCP MSS mangle ცხრილში და მისცე ICMPv6-ს, რომელიც უფრო მცირე MTU-ს აცნობებს, დაბრუნების საშუალება.
შეამოწმე დაბრუნების გზა და არა გვირაბის მისამართი
ყველაზე მეტ დროს რომ წაიღოს, ესაა ცალმხრივი მარშრუტიზაცია. თითოეული გეითვეი შორეულ პრეფიქსს გვირაბში მარშრუტიზებს, მაგრამ ჰოსტები პასუხობენ საკუთარი ნაგულისხმევი გეითვეით, რადგან სწორედ იქ ცხოვრობს მათი /64. პაკეტის დანიშნულებამდე მიყვანა გზის ნახევარია.
| What you see | Likely cause | First check |
|---|---|---|
| Tunnel up, every host silent | remote prefix not routed into the tunnel | ip -6 route get on both gateways |
| Handshake renews, no replies | source prefix missing from selectors or AllowedIPs | ipsec statusall, wg show allowed-ips |
| Small pings pass, transfers stall | MTU or ICMPv6 packet-too-big filtered | /proc/net/snmp6 counters |
| Old prefix still works | stale /64 left in routes or selectors | delegation lease and route table |
ორი ბრძანება აგვარებს უმეტესობას. საიტ A-ზე ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 გვიჩვენებს, რომელ ინტერფეისს გამოიყენებდა პასუხი ამ წყაროდან; გაუშვი სარკისებური შემოწმება საიტ B-ზე. შემდეგ გამოიმუშავე ტრაფიკი ჰოსტიდან და არა გეითვეიდან და შეადარე მრიცხველები ორივე ბოლოზე.
თუ შორეულ პრეფიქსზე მეზობლის მოთხოვნა გვირაბზე ჩნდება, ის პრეფიქსი სადღაც on-link-ია, სადაც არ უნდა იყოს; გაასწორე ეს მარშრუტების კორექტირებამდე. Proxy NDP მოიცავს შემთხვევებს, როცა ბრიჯვა ნამდვილად საჭიროა და არა მარშრუტის შემცვლელი.
დაგეგმე, რომ პრეფიქსი შენ ქვეშ შეიცვლება
პრეფიქსის დელეგირება იჯარაა დელეგირებულ და მოთხოვნილ როუტერებს შორის და განახლებამ შეიძლება სხვა ბლოკი დააბრუნოს: სხვა /56 პროვაიდერის მიგრაციის შემდეგ, ან უფრო მოკლე იჯარა, ვიდრე გვირაბი ჩართულია. ყველა ადგილი, სადაც ძველი პრეფიქსია დასახელებული, ერთდროულად ძველდება: მარშრუტები, სელექტორები, AllowedIPs, firewall-ის წესები, DNS ჩანაწერები და ნებისმიერი მონიტორინგი, რომელიც ლიტერალურ მისამართებს ახისტებს. შეტყობინებების დინება არის RFC 8415-ში.
სადაც მოსალოდნელია პრეფიქსის გადაადგილება, შეინარჩუნე შიდა მისამართების გეგმა, რომელიც მასზე არ არის დამოკიდებული, და გადათარგმნე საზღვარზე. NPTv6 უმდგომარეობო ვარიანტია და შიდა პოლიტიკას წაკითხვადს ტოვებს, მაგრამ ეს პრეფიქსის თარგმანია და არა ჯადოსნური ფენა: /64 საზღვრები უნდა დაემთხვეს, ჩექსუმები კორექტირდება და აპლიკაციები, რომლებიც ლიტერალურ მისამართებს შეიცავენ, მაინც ტყდება. თუ პროვაიდერის მისამართებს ბოლოდან ბოლომდე ინარჩუნებ, ჩაწერე იჯარის ქცევა და ცვლილების პროცედურა მისამართების გეგმაში.
დაასრულე ტესტით, რომელიც დროს უძლებს: თითოეულ LAN-ში დაშვებული ჰოსტი აღწევს სერვისს მეორე LAN-ზე, პასუხი ბრუნდება გვირაბით და იგივე წყვილი კვლავ მუშაობს გვირაბის გადატვირთვისა და დელეგირების განახლების შემდეგ. თუ ბოლო ნაწილი ვარდება, დიზაინი დამოკიდებულია მდგომარეობაზე, რომელიც კვირას ვერ გაუძლებს.