გამოვრთოთ IPv6 VPN-ის გაჟონვის გამოსასწორებლად? სჯობს პოლიტიკა გადავწყვიტოთ
link-local მისამართი გაჟონვა არ არის და გლობალური IPv6 მარშრუტიც არა. ჯერ აირჩიეთ დაბლოკვა, ტარება თუ ხელის არ შეხება.
IPv6 დიაპაზონის მისამართი ჩნდება სატესტო გვერდზე, გვირაბი აშკარად არ ატარებს მას, და ინტერნეტში ყველაზე პოპულარული რჩევაა IPv6 ყველგან გამორთვა. ეს ბრძანება ნამდვილად აჩუმებს პანელს. ის ასევე აშორებს პროტოკოლს, რომელზეც წვდომის ქსელი შეიძლება იყოს დამოკიდებული, და გტოვებთ იმის გარეშე, რომ იცოდეთ მისამართი ნამდვილი გაჟონვა იყო, link-local ინტერფეისის მისამართი თუ resolver, რომელიც თავის საქმეს აკეთებს. სწორ კონტროლს სამი პირობა განსაზღვრავს და მხოლოდ ერთი მათგანი მიდის დაბლოკვამდე.
დაადგინეთ, რა გაზომა ხელსაწყომ სინამდვილეში
ყველაზე გავრცელებული ცრუ განგაშია link-local მისამართი, რომელიც იწყება fe80:-ით და არსებობს ყველა IPv6-უნარიან ინტერფეისზე, მიუხედავად იმისა, აღწევს თუ არა მანქანა ინტერნეტს IPv6-ით. ის ჩანს ინტერფეისების სიებში და ზოგიერთ აპლიკაციის დიაგნოსტიკაში და არაფერს ამბობს თქვენი ტრაფიკის გზაზე.
მეორე ცრუ განგაშია უნიკალური ლოკალური მისამართი fc00::/7-ში, რაც კერძო დიაპაზონია და ქსელის შიგნით გამოიყენება. ხელსაწყო, რომელიც ჰოსტის ყველა მისამართს ბეჭდავს, სიამოვნებით ჩამოთვლის მას საჯაროს გვერდით. ვინც სწრაფად კითხულობს, გაჟონვას უწოდებს და შემდეგ საათს ხარჯავს ისეთ პრობლემაზე, რომელიც არ არსებობს.
მესამე სულაც არ არის ცრუ განგაში. გლობალური მისამართი, რომელიც გვირაბის გარეთ აღწევს ინტერნეტს, სწორედ ნამდვილი გაჟონვაა და ღირს მისი გაზომვა სანამ რამეს გადაწყვეტთ:
ip -6 addr show scope global
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.coთუ პირველი ბრძანება ბეჭდავს გლობალურ მისამართს და მესამე აბრუნებს საჯარო IPv6 მისამართს, რომელიც გვირაბის არ არის, გაქვთ ნამდვილი გზა გვირაბის გარეთ. თუ პირველი მხოლოდ link-local ჩანაწერებს ბეჭდავს, გასწორებადი გაჟონვა არასდროს ყოფილა.
კონტროლს სამი პირობა განსაზღვრავს
გადაწყვეტილება არ არის „IPv6 კარგია“ ან „IPv6 ცუდია“. გადაწყვეტილებაა, სამი სიტუაციიდან რომელში ხართ, და თითოეულს განსხვავებული სწორი პასუხი აქვს, შეცდომის შემთხვევაში განსხვავებული ფასით.
| Situation | Correct control | Cost if you disable IPv6 instead |
|---|---|---|
| Exit has no IPv6, host does | Block IPv6 deliberately in the tunnel policy | Same visible result, no documentation of intent |
| Exit carries IPv6, host leaks | Route IPv6 into the tunnel and verify | You lose IPv6 reachability entirely |
| Access network is IPv6-only | Change nothing; use the tunnel's IPv6 | Machine loses connectivity completely |
პირველი სტრიქონია ის, რაც ხალხს ჩვეულებრივ აქვს მხედველობაში და ის ლეგიტიმურია. კლიენტმა, რომლის გასასვლელს IPv6 მხარდაჭერა არ აქვს, არ უნდა გაუშვას ჩუმად ჰოსტის საკუთარი IPv6 ტრაფიკი, რადგან ეს არის დოკუმენტირებული ორმაგი სტეკის გაჟონვა. არსი იმაშია, რომ დაბლოკოთ ის გამოცხადებულ პოლიტიკად, და არა გამორთოთ პროტოკოლი ბირთვში. ხილული შედეგი იდენტურია და მხოლოდ ერთი მათგანი შეიძლება გადამოწმდეს მოგვიანებით.
მესამე სტრიქონია ადგილი, სადაც ზოგადი რჩევა აქტიურად საზიანო ხდება. მობილური ოპერატორები და ზოგიერთი სახლის კავშირი მართავს IPv6-only ქსელებს IPv4 დანიშნულებისთვის ტრანსლაციით. იქ IPv6-ის მოცილება ნიშნავს ქსელის მიერ შემოთავაზებული ერთადერთი ტრანსპორტის მოცილებას, რაც ბევრად უარეს შეფერხებას იწვევს, ვიდრე ის, რომელსაც აგვარებდით.
თუ გასასვლელს IPv6 არ აქვს, დაბლოკეთ განზრახ
უპირატესობა მიანიჭეთ კლიენტის საკუთარ მექანიზმს, რადგან ის მოქმედებს ზუსტად მანამ, სანამ გვირაბი აწეულია, და უკან იხევს, როცა ის ვარდება. OpenVPN აქვს ამისთვის ოფცია, და iptables-ს აქვს ეკვივალენტური წესი სხვა კლიენტებისთვის:
block-ipv6
ip6tables -A OUTPUT -o eth0 -j REJECT --reject-with ipv6-port-unreachableდირექტივა პროფილს ეკუთვნის; წესი — firewall-ს, რომლის გადახედვა და მოცილება შეგიძლიათ. ორივე დახურულად ვარდება, რაც გსურთ, და ორივე ჩანს კონფიგურაციის diff-ში, რაც არ შეიძლება ითქვას გაშვების სკრიპტში ჩამარხულ ბირთვის sysctl-ზე.
ჩაწერეთ, რატომ არის ის იქ. კომენტარის გარეშე დაბლოკვის წესს მოხსნის შემდეგი ადამიანი, რომელსაც IPv6 დასჭირდება სხვა რამისთვის, და შემდეგ გაჟონვა ჩუმად დაბრუნდება.
თუ გასასვლელი ატარებს IPv6-ს, დაამარშრუტეთ და გამოსცადეთ ორივე ოჯახი
IPv6-ის ტარება უკეთესი პასუხია, როცა სერვერი მხარს უჭერს, და ბევრად უფრო რთული არ არის. მოთხოვნაა, რომ გვირაბის ინტერფეისს ჰქონდეს მისამართი ამ ოჯახში და მისი ნაგულისხმევი მარშრუტი გვირაბის შიგნით იყოს მიმართული, და არა ფიზიკური ინტერფეისიდან გარეთ:
ip -6 route get 2606:4700:4700::1111
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.co
curl -4 -sS --max-time 6 https://ifconfig.coმარშრუტის ძებნა გადამწყვეტი ტესტია: თუ ის ასახელებს გვირაბის ინტერფეისს, IPv6 ტრაფიკი ტარდება. შემდეგ ორი curl გამოძახება ადასტურებს, რას ხედავს თითოეული ოჯახი, და მათი შედარებაა იმის დამტკიცების გზა, რომ ორივე გზა ახლა ერთი და იმავე გასასვლელიდან გადის.
ნუ გაჩერდებით წარმატებულ კავშირზე. ხელახლა დაუკავშირეთ გვირაბი და კვლავ შეამოწმეთ, რადგან გაგზავნილი IPv6 მარშრუტი შეიძლება დაიკარგოს ხელახალი დაყენებისას, თუ სერვერი მას მხოლოდ საწყის კონფიგურაციაში აგზავნის. შემდეგ შეამოწმეთ ერთი გამორიცხული დანიშნულება, რადგან split-tunnel წესებია ის ადგილი, სადაც ორი ოჯახი ყველაზე ხშირად იშლება.
თუ წვდომის ქსელი მხოლოდ IPv6-ია, ხელი არ შეახოთ
ზოგიერთი ქსელი მხოლოდ IPv6-ს აძლევს და ელოდება, რომ მოწყობილობა IPv4 სერვისებს ოპერატორის მხარეს არსებული ტრანსლაციის მექანიზმით მიაღწევს. ასეთ მანქანაზე IPv6-ის გამორთვა უსაფრთხოების გაუმჯობესება არ არის; ის აშორებს ერთადერთ გზას ყველაფრისკენ. ეს თვითგამოწვეული შეფერხებაა იმ ტესტის შედეგის გულისთვის, რომელიც არავის სჭირდებოდა.
ამ შეცდომის სიმპტომი გამორჩეული და არასასიამოვნოა: გვირაბი თითქოს დგება, სახელების გარჩევა მუშაობს და არაფერი იტვირთება. თუ ამას IPv6-ის ცვლილების შემდეგ ხედავთ, დაუყოვნებლივ აღადგინეთ პარამეტრი და გააგრძელეთ დიაგნოსტიკა სხვაგან.
რაც არ უნდა აირჩიოთ, გადაწყვეტილება ღიად შეინახეთ პროფილში ან firewall-ში, დაუკავშირეთ იმას, რასაც გასასვლელი ნამდვილად უჭერს მხარს, და ჩაიწერეთ ორმაგი სტეკის ქცევა, რომელსაც აღწერს RFC 7359-ის ორმაგი სტეკის განხილვა . გამოცხადებული დაბლოკვა პოლიტიკაა. გამორთული პროტოკოლი გვერდის ავლაა, რომლის აუდიტი ვერავინ ვერ შეძლებს, და სატესტო გვერდიდან ისინი ერთნაირად გამოიყურებიან.