უნდა გაიაროს თუ არა IPv6 ტრაფიკმა VPN-ით თუ პირდაპირ?
გადაწყვიტეთ, ეკუთვნის თუ არა ::/0 გვირაბის შიგნით, სამი პირობით: გასასვლელის მხარდაჭერა, საბოლოო წერტილის ხელმისაწვდომობა და მხოლოდ ლოკალური ქსელები.
გასულ თვეს ორმა ადამიანმა ჩემგან საპირისპირო შედეგები მოითხოვა: ერთს სურდა, რომ IPv6 VPN-ით დაფარულიყო, მეორეს სურდა, რომ ოფისის პრინტერი მუშაობა გაეგრძელებინა. ერთი მარშრუტი ::/0 დამოუკიდებლად ორივეს ვერ უზრუნველყოფს. გვირაბის შიგნით ეკუთვნის თუ არა ეს მარშრუტი, სამ პირობაზეა დამოკიდებული, და პირველი მას კომერციული გასასვლელების უმეტესობისთვის გამორიცხავს. თუ გასასვლელი IPv6-ს არ ატარებს, ნაგულისხმევი მარშრუტის იქ მიმართვა თქვენს ტრაფიკს მალავს გვირაბში, რომელსაც მისი გაგზავნის ადგილი არ აქვს.
პასუხს სამი პირობა განაპირობებს
ნაგულისხმევი მარშრუტი ერთი ხაზია, ::/0, და ერგება ნებისმიერ IPv6 დანიშნულების ადგილს უფრო კონკრეტული მარშრუტის გარეშე (RFC 4291). მისი დაყენება მარტივია. გადაწყვეტა, უნდა გააკეთოთ თუ არა, სამ პირობამდე მოდის.
პირველი პირობა: გასასვლელს, რომელზეც უერთდებით, აქვს მომუშავე IPv6 და მზადაა მისი გადაცემისთვის. მეორე პირობა: თქვენს კლიენტს შეუძლია შეინარჩუნოს გზა გვირაბის საბოლოო წერტილამდე, რომელიც ჩვეულებრივ იმ დიაპაზონშია, რომლის მარშრუტიზაციასაც აპირებთ. მესამე პირობა: შეგიძლიათ დაასახელოთ ის ლოკალური IPv6 დანიშნულებები, რომლებიც გვირაბის გარეთ უნდა დარჩეს.
თითოეული პირობა თავისებურად ცდება, ამიტომ გამოცნობა მთელი საღამო ჯდება. წარუმატებელი პირველი პირობა გაძლევთ სიჩუმეს და მარშრუტების ცხრილს, რომელიც სწორად გამოიყურება. წარუმატებელი მეორე პირობა ხელის ჩამორთმევას კლავს დაწყებიდან რამდენიმე წამში. წარუმატებელი მესამე პირობა ტოვებს მომუშავე გვირაბს და უკმაყოფილო კოლეგას პრინტერთან.
| What you see | Decision |
|---|---|
| Exit answers IPv6 probes, no local IPv6 devices to protect | Route ::/0 into the tunnel |
| Exit answers IPv6 probes, printer or NAS reachable by a global address | Route ::/0, then give those prefixes a route of their own |
| Exit is IPv4-only inside the tunnel | Do not route ::/0; block IPv6 on the client |
Endpoint is reached over IPv6 and sits inside ::/0 | Install a host route for the endpoint first |
ატარებს გასასვლელი ნამდვილად IPv6-ს?
გვირაბის ინტერფეისი IPv6 მისამართით მეორე მხარეზე არაფერს ამტკიცებს. ბევრი კომერციული პროფილი შიგნიდან მხოლოდ IPv4-ია: სერვერი გაძლევთ v4 მისამართს და დანარჩენს ყრის. დააყენეთ ზემოდან ნაგულისხმევი მარშრუტი AllowedIPs-იდან და ბირთვი სიამოვნებით გაგზავნის IPv6-ს ინტერფეისში, რომლის პარტნიორიც მას არასოდეს ხედავს.
შეამოწმეთ კლიენტიდან, სანამ გვირაბი აწეულია. ping -6 -c 3 2001:4860:4860::8888 და ip -6 route get 2001:4860:4860::8888 სხვადასხვა კითხვას პასუხობს: ბრუნდება თუ არა პასუხი, და რომელი მოწყობილობა აირჩია ბირთვმა. როცა მეორე თქვენს გვირაბს ასახელებს, პირველი კი არაფერს აბრუნებს, პრობლემა გასასვლელშია, არა მარშრუტში.
თუ თავად მართავთ გასასვლელს, კლიენტის ტესტი შეიძლება გაიაროს და გზა მაინც ჩიხში დასრულდეს. დაადასტურეთ, რომ კარიბჭეზე ჩართულია net.ipv6.conf.all.forwarding=1 და რომ მისი ფაირვოლი იღებს გვირაბიდან გადაცემულ პაკეტებს. სწორად მარშრუტიზებული პაკეტი გასასვლელში, რომელიც გადაცემაზე უარს ამბობს, კლიენტის მხრიდან ზუსტად მარშრუტიზაციის ხარვეზად გამოიყურება.
შეუძლია კლიენტს შეინარჩუნოს გზა საბოლოო წერტილამდე?
ეს ის შემთხვევაა, რომელმაც დამიჭირა ლეპტოპზე, რომლის WireGuard საბოლოო წერტილი მხოლოდ IPv6 იყო. საბოლოო წერტილის მისამართი ჩვეულებრივი გლობალური მისამართია, ამიტომ ის ::/0-ის შიგნით ხვდება. მარშრუტიზაცია გაუკეთეთ მთელ პრეფიქსს ინტერფეისში და ხელის ჩამორთმევის პაკეტები თავად აჩქარდებიან გვირაბში, რომლის აშენებასაც ჯერ კიდევ ცდილობენ. გვირაბი არასოდეს ადის და კლიენტის გამოსავალში არაფერი ამბობს, რატომ.
wg-quick Linux-ზე ამას აგვარებს. ის მარშრუტებს AllowedIPs-იდან გამოაქვს, საკუთარ ცხრილში აყენებს და ამატებს პოლიტიკის წესს, რათა საბოლოო წერტილისკენ ტრაფიკი ჯერ მთავარი ცხრილით გადაწყდეს: წესი suppress_prefixlength 0, რომელსაც ip -6 rule-ში იპოვით. ამიტომ wg-quick up აღწევს წარმატებას იქ, სადაც ხელით დაწერილი ip -6 route add default dev wg0 გაწყვეტთ.
შეამოწმეთ ორივე მდგომარეობა ip -6 route get <endpoint-v6>-ით, გვირაბის აწევამდე და მის შემდეგ. თუ პასუხი თქვენს გვირაბის მოწყობილობაზე იცვლება, თქვენ წაშალეთ გზა, რომელიც გვირაბს სჭირდება. როცა მარშრუტებს თავად წერთ, დაამატეთ ჰოსტის მარშრუტი საბოლოო წერტილამდე საწყისი კარიბჭის გავლით, ან დაუკავშირდით საბოლოო წერტილს IPv4-ით და დატოვეთ IPv6 დატვირთვას.
რა უნდა დარჩეს გვირაბის გარეთ?
უფრო კონკრეტული მარშრუტები იმარჯვებს ნაგულისხმევზე, ამიტომ ბმულზე არსებული პრეფიქსი ან საკუთარი მარშრუტის მქონე ULA დიაპაზონი დამატებითი ძალისხმევის გარეშე აგრძელებს მუშაობას. ეს არის ის მშვიდი მიზეზი, რის გამოც ამდენი სრული გვირაბის IPv4 კონფიგურაცია ცოცხლობს: LAN პრეფიქსები ნაგულისხმევზე კონკრეტულია და გვირაბში არასოდეს შედის.
ეს ირღვევა, როცა ლოკალური მოწყობილობა გლობალური მისამართით ხელმისაწვდომია, რაც ნორმალურია პრინტერისთვის, რომელსაც იმავე როუტერმა საჯარო პრეფიქსი მისცა, NAS-ისთვის ან ტელევიზორისთვის. ეს მისამართები ერგება ::/0-ს და სხვა არაფერს, ამიტომ ისინი დანარჩენთან ერთად გვირაბში გადადიან და ქრებიან.
გადაწყვიტეთ დანიშნულების მიხედვით, არა პროტოკოლის მიხედვით. თუ ორი-სამი ლოკალური ჰოსტი მნიშვნელოვანია, მიეცით მათ პრეფიქსებს გასვლის მარშრუტი ფიზიკური ინტერფეისით, ან ამოიღეთ ისინი შეთანხმებული ნაკრებიდან. თუ სია აგრძელებს ზრდას, პატიოსანი პასუხია IPv6-ისთვის გაყოფილი გვირაბი წერილობითი გამონაკლისების სიით, და არა ნაგულისხმევი მარშრუტი, რომელსაც გამუდმებით აკერებთ.
თუ პასუხი არაა, დაბლოკეთ
IPv6-ის მარშრუტის გარეშე დატოვება არ არის იგივე, რაც მისი მარტო დატოვება. მომუშავე IPv6 ნაგულისხმევის მქონე ჰოსტი განაგრძობს მის გამოყენებას, სანამ გვირაბი IPv4-ს ატარებს, ამიტომ ტრაფიკი VPN-ის გვერდით გადის და ყველა სერვისი, რომელიც IPv6-ს ამჯობინებს, ხედავს თქვენს ნამდვილ მისამართს. ეს გაჟონვაა, არა გაყოფილი გვირაბი.
აირჩიეთ ერთი და ჩაწერეთ, რომელი აირჩიეთ. მარშრუტიზაცია გაუკეთეთ ნაგულისხმევს და მიიღეთ ზემოთ მოცემული კომპრომისები, ან გამორთეთ IPv6 გვირაბის ხანგრძლივობით. პრეფიქსის AllowedIPs-იდან გამოტოვება თავისთავად საკმარისი არ არის, რადგან ოპერაციული სისტემა საკუთარ ნაგულისხმევს ინახავს. Linux-ზე უხეში ვერსიაა sysctl -w net.ipv6.conf.all.disable_ipv6=1; უფრო დახვეწილი ვერსია IPv6-ს გვირაბის გარეთ აგდებს ფაირვოლის წესით. ტელეფონის კლიენტებს აქვთ IPv6-ის დაბლოკვის მკაფიო გადამრთველი, რომელიც იმავეს აკეთებს.
შეამოწმეთ ის გაჟონვის მსგავსად
აწიეთ გვირაბი და წაიკითხეთ მდგომარეობა, ნაცვლად იმისა, რომ გადამრთველს ენდოთ. ip -6 route show default უნდა აჩვენებდეს ერთ ნაგულისხმევს, და ip -6 route get თქვენი LAN-ის გარეთ დანიშნულებისთვის უნდა ასახელებდეს გვირაბის მოწყობილობას. გაიმეორეთ ორივე გათიშვის შემდეგ: გვირაბზე მეტხანს მცხოვრები ნაგულისხმევი ის ხარვეზია, რომელსაც ეძებდით.
შემდეგ შეამოწმეთ საპირისპირო მიმართულება. ლოკალური ქსელის ჰოსტიდან მიაღწიეთ კლიენტამდე მისი ლოკალური IPv6 მისამართით. თუ ეს წყვეტს მუშაობას, მესამე პირობა არასოდეს შესრულებულა, რაც არ უნდა ამტკიცებდა მაშინ მარშრუტების ცხრილი.
დაწერეთ შედეგი იქ, სადაც შემდეგი ადამიანი იპოვის: რომელი პრეფიქსები რჩება ლოკალური, რატომ, და რას აკეთებს კლიენტი გათიშვის შემდეგ. ორი ხაზი runbook-ში ზოგავს შემდეგ ინჟინერს შუაღამისას საბოლოო წერტილის ციკლის ხელახლა აღმოჩენისგან.