IPv6 link-local არ მუშაობს VPN-ზე: რატომ ჩერდება fe80 ბმულზე
fe80:: მისამართს მნიშვნელობა მხოლოდ ერთ ბმულზე აქვს. ნახეთ, რატომ ვერ გადაიტანს მას მარშრუტიზებული VPN, როგორ გამოიყურება ხარვეზი და რომელი მისამართი გამოიყენოთ სანაცვლოდ.
თქვენ ხსნით გვირაბს, აკეთებთ ping-ს fe80::1-ზე გვირაბით, როგორც წყაროს ინტერფეისით, და არაფერი ბრუნდება. ეს არ არის დავიწყებული firewall-ის წესი. Link-local მისამართს მნიშვნელობა მხოლოდ იმ ერთ ბმულზე აქვს, სადაც ის ჩამოყალიბდა, და მარშრუტიზებული VPN ის ბმული არ არის. დისტანციური როუტერის fe80::1 დისტანციურ LAN სეგმენტზე ცხოვრობს; თქვენ ერთი ნახტომით ხართ მოშორებული სხვა სეგმენტზე, და IPv6-ს საერთოდ არ აქვს მექანიზმი, რომ როუტერმა link-local პაკეტები გადააგზავნოს.
fe80 პრეფიქსი აღწერს ფარგლებს და არა დიაპაზონს
Link-local unicast არის fe80::/10, და განმსაზღვრელი თვისება არა რიცხვი, არამედ ფარგლებია. მისამართი ძალაშია მხოლოდ ერთ ბმულზე, და ყოველი ინტერფეისი ერთს საკუთარი იდენტიფიკატორიდან ქმნის, ამიტომ ორი უკავშირო მანქანა ორ უკავშირო ქსელში ორივე შეიძლება პასუხობდეს fe80::1-ს ყოველგვარი კონფლიქტის გარეშე. პრეფიქსი არსებითად ამბობს „რაღაც ბმულზე“; თავად ბმული კონტექსტიდან მოდის.
ჰოსტზე ეს კონტექსტი არის ზონა, ანუ scope ID, რომელსაც პროცენტის ნიშნის შემდეგ ამატებთ: fe80::1%eth0 Linux-ზე, fe80::1%3 ან fe80::1%12 Windows-ზე და ხელსაწყოებში, რომლებიც ინტერფეისის ინდექსებს აჩვენებენ. ბირთვი მისამართს ინტერფეისის ინდექსთან ერთად წყვეტს და შემდეგ აგზავნის. ზონას თუ მოხსნით, დანიშნულება ორაზროვანი ხდება, ამიტომ სტეკს სეგმენტის არჩევის გზა არ აქვს.
რატომ ვერ მიიტანს მას მარშრუტიზებული გვირაბი
მარშრუტიზებული VPN არის წერტილ-წერტილ ინტერფეისი, რომელიც საკუთარ მისამართებს ატარებს, ჩვეულებრივ გვირაბის შიგნით unique-local ან კერძო IPv6 სივრცის /64-ს. დისტანციური LAN ცალკე ბმულია, რომელსაც გვირაბის ბოლო წერტილი აღწევს თქვენი სახელით მარშრუტიზაციითა და გადაგზავნით. ეს ორი განსხვავებული სეგმენტია, ამიტომ ერთის მისამართი მეორეზე ვალიდური დანიშნულება არ არის.
გადაგზავნის წესი სტანდარტშია ნათლად ჩამოწერილი და არა თქვენი კლიენტის უცნაურობა: როუტერები არ გადააგზავნიან პაკეტებს link-local წყაროთი ან დანიშნულებით. ამიტომ პაკეტი იღუპება მაშინაც, როცა მარშრუტიზაციის ცხრილი სწორად გამოიყურება. დაამატეთ მარშრუტი fe80::/64-ზე გვირაბისკენ და შესაბამისი სტეკი ან უარყოფს მას, ან მიიღებს და ყველა შესაბამის პაკეტს ჩამოყრის: დანიშნულების ფარგლები ამბობს „მხოლოდ ეს ბმული“, და გამავალი ინტერფეისი ის ბმული არ არის.
მეზობლების აღმოჩენა იმავე საზღვარს ამტკიცებს. ჰოსტები link-local შემდეგ ნახტომებს წყვეტენ მეზობლის მოთხოვნით, რომელიც იგზავნება ბმულის ფარგლების multicast-ზე 255 ნახტომის ლიმიტით, ამიტომ როუტერებს შეუძლიათ უარყონ ყველაფერი გადაგზავნილი. ამის გვირაბზე მუშაობა ნიშნავს დისტანციური სეგმენტისთვის აღმოჩენის პროქსირებას, რაც Layer 2 ხიდია სხვა ქუდში.
არსებობს უფრო მშვიდი მეორე ხარვეზი, და ის იჭერს მათ, ვინც მაინც ცდილობს მარშრუტის იძულებას: ზონა. რა ზონასაც აკრეფთ ლოკალურად, ის გვირაბის ინტერფეისს ასახელებს, მაშინ როცა სასურველი მისამართი დისტანციური LAN ინტერფეისზეა მიბმული. ორივე არასდროს ემთხვევა, ამიტომ პაკეტის სწორ ინტერფეისზე მიმართვა შორეულ ბოლოში შეუძლებელია.
როგორ გამოიყურება ხარვეზი პრაქტიკაში
ფარგლების შეცდომის ხელსაწყოს გამონატანი იკითხება როგორც მარშრუტიზაციის ან firewall-ის შეცდომა, და სწორედ ამიტომ ატარებენ ადამიანები შუადღეს არასწორ შრეში.
| What you run | What you see | What it means |
|---|---|---|
| ping fe80::1 with no zone | Invalid argument on Linux, or a transmit failure on Windows | The stack cannot pick an interface for an ambiguous destination |
| ping -6 -I tun0 fe80::1 | Destination unreachable, or a silent timeout | The address is not on the tunnel link, so there is nothing on-link to answer |
| ssh user@fe80::1 after the tunnel is up | Hangs, then no route to host | The SYN never left the machine in a deliverable form; the server logs nothing |
| ip -6 neigh show dev tun0 | Empty table | No neighbor entry can exist for a link-local host that is not on this link |
| fe80::/64 inside AllowedIPs or route-ipv6 | Config accepted, traffic still dropped | The tunnel carried the packet; the receiving stack refused to forward it |
მესამე სტრიქონი ყველაზე მეტ დროს ხარჯავს, რადგან გამონატანის გარეშე ssh კლიენტი მოსმენის სერვისის პრობლემას ჰგავს. თუ შიგნით შესვლის რაიმე გზა გაქვთ, შეამოწმეთ შორეული მხარე და დაადასტურეთ, sshd ყველა მისამართზეა მიბმული თუ მხოლოდ ერთზე.
გამოიყენეთ მისამართი, რომელიც მარშრუტიზაციისთვის იყო განკუთვნილი
ყველაფრისთვის, რაც გვირაბის გავლით უნდა მიაღწიოთ, გამოიყენეთ ის მისამართი, რომელიც სერვისს სწორედ ამ მიზნით მიეცა: გლობალური unicast მისამართი, ან unique-local მისამართი fc00::/7-დან, დიაპაზონი, რომელიც ზუსტად ამ შიდა შემთხვევისთვისაა დაცული. დაადასტურეთ, რომ მსმენელი მას ნამდვილად ბოჭავს, და შეამოწმეთ დაბრუნების გზა და ჰოსტის ნებისმიერი firewall წესი.
შეხედეთ დისტანციურ ჰოსტს და ნუ გამოიცნობთ. ip -6 addr show ჩამოთვლის არსებულ მისამართებს, ხოლო ss -6 -ltn აჩვენებს, რას უსმენს დემონი. მხოლოდ fe80::-ზე მიბმული სერვისი მხოლოდ საკუთარი სეგმენტიდანაა ხელმისაწვდომი, რაც ჩვეულებრივ ნაგულისხმევია, რომელიც არავის განზრახ არ აურჩევია და ადმინისტრატორის თანხმობით იცვლება.
როცა სერვისი ნამდვილად ვერ მიება ხელახლა, ხიდი ქსელური შრის ნაცვლად აპლიკაციის შრეზე აიტანეთ. რელე დისტანციურ ჰოსტზე, რომელიც მარშრუტიზებად მისამართზე უსმენს და link-local-ზე უკავშირდება, პრობლემას ხსნის ყოველგვარი სეგმენტის გაფართოების გარეშე:
socat TCP6-LISTEN:8080,bind=[fd00:1:2::10] TCP6:[fe80::1%eth0]:80აქ ზონა სწორ მხარესაა, იმ ჰოსტზე, რომელსაც ნამდვილად აქვს eth0 ამ ბმულზე. თქვენი კლიენტი ესაუბრება fd00:1:2::10-ს, რომელიც ჩვეულებრივ მარშრუტიზდება, და რელე link-local ნახტომს ლოკალურად ასრულებს. იგივე ხრიკი მუშაობს მოწყობილობის ვებ UI-სთვის ან ძველი BMC-სთვის, რომელიც მხოლოდ link-local მისამართს აცხადებს.
როცა ხიდად შეერთება ნამდვილად პასუხია, და რა უნდა შემოწმდეს
ზოგიერთ განლაგებას ნამდვილად სჭირდება ერთი საერთო სეგმენტი: მოწყობილობა, რომელიც მხოლოდ link-local აღმოჩენაზე საუბრობს, აპარატი, რომელიც multicast-ზეა დამოკიდებული, ლაბორატორია, რომელიც ბრტყელ LAN-ს ამრავლებს. ეს Layer 2-ის პრობლემაა და Layer 2-ის პასუხი სჭირდება, როგორიცაა დისტანციურ ინტერფეისზე შეერთებული tap მოწყობილობა ან აშკარა ხიდური რეჟიმის მქონე კლიენტ პროდუქტი. ეს გიჯდებათ გვირაბის გადამკვეთი broadcast და multicast ტრაფიკი, პლუს მეზობლების აღმოჩენა, რომელიც ბოლოდან ბოლომდე უნდა მუშაობდეს.
ნუ მიუახლოვდებით ამას fe80::/64-ის მარშრუტიზებულ პროფილში დამატებით. ეს ქმნის ყველაზე ცუდ მდგომარეობას: კონფიგურაცია დასრულებულად გამოიყურება, მარშრუტიზაციის ცხრილი ჩანაწერს აჩვენებს, და ყოველი პაკეტი მაინც იკარგება სადღაც ორ სტეკს შორის, რომლებიც ორივე სწორად იქცევიან.
შეამოწმეთ ინტერფეისით და არა ping-ით. ip -6 addr show tun0 გეუბნებათ, შექმნა თუ არა გვირაბის ბმულმა საკუთარი link-local მისამართი, ხოლო ip -6 route get fe80::1%tun0 გეუბნებათ, რას გააკეთებდა ბირთვი ფაქტობრივად ფარგლიან დანიშნულებასთან. როცა ბირთვი ამბობს, რომ დანიშნულება მიუწვდომელია ამ ინტერფეისზე, ვერც ერთი გვირაბის პარამეტრი ვერ შეცვლის ამას, და დროა შეწყვიტოთ პროფილის რედაქტირება.
მოკლე თანმიმდევრობა, რომელიც საკითხს წყვეტს:
- წაიკითხეთ მისამართი დისტანციურ ჰოსტზე და დააკვირდით, fe80:: არის თუ მარშრუტიზებადი პრეფიქსი.
- თუ fe80:: არის, ხელახლა მიაბით სერვისი, გააკეთეთ რელე ამ ჰოსტზე ან ხიდად შეაერთეთ სეგმენტი; თუ მარშრუტიზებადია, შეასწორეთ მარშრუტი, firewall ან მიბმის მისამართი.
- ყოველ ხელახალ ტესტზე გადაამოწმეთ ზონა, რადგან კოპირებული ბრძანება ჩვეულებრივ არასწორ ინტერფეისს ინახავს.
წყაროები: RFC 4291, IPv6 მისამართების არქიტექტურა.