IPv6 OpenVPN გვირაბით: სახლის როუტერის გავლით

ლეპტოპს IPv6 მისამართი აქვს, გვირაბი IPv4-ზეა აწეული და მაინც ყველა IPv6 ტესტი იშლება. ან უარესი: ტესტი წარმატდება და ტრაფიკი პროვაიდერის გზით გავიდა გვირაბში შესვლის გარეშე. ორივე შედეგი ერთ დაკარგულ გადაწყვეტილებას უბრუნდება: არავის მიუცია როუტერისთვის პრეფიქსი, რომლის მარშრუტიზებაც კლიენტებისკენ შეეძლო. გზის კლიენტიდან გარეთ გავლისას ირკვევა, რომელი ნაწილი აკლია.

დაიწყეთ იქ, სადაც კლიენტი ზის

სერვერზე შეხებამდე შეხედეთ კლიენტს. ip -6 addr-მა უნდა აჩვენოს გვირაბის მისამართი აუზიდან, ხოლო ip -6 route-მა — გვირაბის მოწყობილობაზე მიმთითებელი გაგზავნილი პრეფიქსი. როცა მისამართი არის, მაგრამ გზა არა, გაგზავნა აკლია ან კლიენტმა უგულებელყო იგი. როცა არც ერთი არ არის, სერვერს არაფერი გამოუყოფია.

შემდეგ შეამოწმეთ, რას ფიქრობს კლიენტი გარე სამყაროზე. გვირაბზე გამავალი ნაგულისხმევი გზა მთელ IPv6 ტრაფიკს ითხოვს, ხოლო 2000::/3-ისთვის გზა მხოლოდ გლობალურ unicast-ს ითხოვს. ორივე შეიძლება სწორი იყოს და ისინი ჟონვის შესახებ სხვადასხვა კითხვას პასუხობენ.

კლიენტი, რომელსაც IPv6-ის ნაგულისხმევი გზა საერთოდ არ აქვს, ყველა საჯარო ტესტზე იშლება, მაშინ როცა თავად გვირაბი სრულიად ჯანსაღია. ეს პოლიტიკის ხარვეზია და არა გატეხილი გვირაბი.

შეამოწმეთ აუზი, რომლის მარშრუტიზებაც სერვერს ნამდვილად შეუძლია

სერვერს გამოყოფა მხოლოდ იმ პრეფიქსიდან შეუძლია, რომელსაც ნამდვილად აკონტროლებს. თუ პროვაიდერი /56-ს დელეგირებს, გვირაბისთვის ერთი /64 დატოვეთ, დანარჩენი კი LAN-ს. სადაც პროვაიდერი WAN-ზე მხოლოდ ერთ /64-ს გადასცემს და მეტს არაფერს მარშრუტიზებს, LAN-ის პრეფიქსი მშვიდად დატოვეთ და გვირაბს უნიკალური ლოკალური დიაპაზონი მიეცით, იმის მიღებით, რომ კლიენტებს გლობალური გასასვლელი არ ექნებათ.

აუზი და გაგზავნა ერთად მიდიან. server-ipv6 2001:db8:80:10::/64 მისამართებს ანიჭებს, ხოლო push "route-ipv6 2000::/3" კლიენტებს ეუბნება, რა გააგზავნონ გვირაბში. 2000::/3-ის გაგზავნა ფარავს გლობალურ unicast-ს და link-local და multicast დიაპაზონებს გვირაბის გარეთ ტოვებს.

შერჩეული პრეფიქსი განლაგების ჩანაწერში ჩაწერეთ. ვინც შემდეგ ჯერზე შეცვლის პროვაიდერის გადაცემას, უნდა იცოდეს, რომელი /64 გვირაბმა უკვე დაიკავა.

ჩართეთ გადამისამართება მეორე ოჯახისთვის

IPv4-ის გადამისამართება IPv6-ის გადამისამართებას არ ნიშნავს. დააყენეთ net.ipv6.conf.all.forwarding=1 და აირეკლეთ ყველაფერი, რასაც IPv4-ის FORWARD პოლიტიკა უკვე უშვებს. როუტერზე, რომლის FORWARD ჯაჭვი ნაგულისხმევად ყრის, წესების ნაკრების არარსებობა ზუსტად მკვდარი გვირაბივით გამოიყურება.

ხელის ჩამორთმევა წარმატდება, კლიენტი მისამართს იღებს და უკან არაფერი ბრუნდება. დაამატეთ წესები ორივე მიმართულებისთვის და WAN-ის ნაწილისთვის, რადგან გვირაბი, რომელიც LAN-ს აღწევს, მაგრამ ინტერნეტს არა, მესამე ტესტზე იშლება. წარუმატებელი ცდის შემდეგ ნახეთ ჯაჭვის მრიცხველები, რადგან წესი, რომელიც არასოდეს დაემთხვა, სხვა პრობლემაა, ვიდრე დამთხვეული და გადაგდებული.

ip6tables -A FORWARD -i br0 -o tun0 -j ACCEPT
ip6tables -A FORWARD -i tun0 -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i tun0 -o wan0 -j ACCEPT

ერთი გვერდითი ეფექტი იჭერს მათ, ვინც საბოლოოდ გვირაბს ადანაშაულებს. გადამისამართების ჩართვისას ბირთვი გამოტოვებს მისამართის კონფიგურაციას Router Advertisement-ით, თუ სხვაგვარად არ უთხრით, და ასე ნასწავლი ნაგულისხმევი გზა მასთან ერთად ქრება. ან WAN-ის ინტერფეისზე აშკარა ნაგულისხმევი გზა მიამაგრეთ, ან იქ განზრახ დააყენეთ accept_ra 2-ზე. ნებისმიერი ცვლილების შემდეგ დაადასტურეთ, რომ როუტერს ჯერ კიდევ აქვს გარეთ გასვლის გამოსადეგი IPv6 გზა, სანამ კლიენტებს ხელახლა გამოსცდით.

უპასუხეთ მეზობლების აღმოჩენას, როცა ზედა ნაწილი არ მარშრუტიზებს

ზედა ნაწილის აღჭურვილობა ზოგჯერ დელეგირებულ /64-ს საკუთარი კავშირის ნაწილად მიიჩნევს და უარს ამბობს ნებისმიერი ქვეპრეფიქსის VPN ყუთისკენ მარშრუტიზებაზე. როცა ეს ხდება, რაღაცამ უნდა უპასუხოს მეზობლის მოთხოვნებს თითოეული კლიენტის მისამართისთვის ცალ-ცალკე.

OpenVPN გამოყოფილ მისამართს client-connect კაუჭს უხსნის, ამიტომ ჩანაწერებს შეუძლიათ ხელით შენახული სიის ნაცვლად რეალურ აუზს მიჰყვეს. კაუჭი ამატებს ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0-ს, ხოლო შესაბამისი client-disconnect კაუჭი ხსნის მას. მოხსნის გარეშე proxy ცხრილი ძველდება და მოგვიანებით მოსულ კლიენტს შეიძლება მემკვიდრეობით მიუვიდეს ჩანაწერი მისამართზე, რომელიც არასოდეს მიუღია. დაადასტურეთ მდგომარეობა ip -6 neigh show proxy-ით.

proxy-ს დროებით გადაწყვეტად მიუდექით. გვირაბის /64-ისთვის როუტერისკენ მიმართული სტატიკური გზა კლიენტების ცვლას უძლებს და პრივილეგირებული shell კაუჭი საერთოდ არ სჭირდება.

გაჰყევით გზას გარეთ, ნახტომ-ნახტომ

გამოსცადეთ გარეთ სამ ნაბიჯად: ჯერ როუტერის გვირაბის მისამართი, შემდეგ LAN-ის ჰოსტი და მესამე — საჯარო დანიშნულება traceroute6-ით. აუზს ამტკიცებს პირველი, გადამისამართებას და LAN-ის ფაირვოლს — მეორე, ხოლო ზედა ნაწილის გავლით დაბრუნების გზას — მესამე. ყოველი მარცხი ძიებას ერთ მოწყობილობამდე ავიწროებს, ნაცვლად მთელი დიზაინის ხელახლა გახსნისა.

თვალი ადევნეთ გვირაბის MTU-ს, რადგან გზაზე მყოფი IPv6 როუტერები თქვენს ნაცვლად არ დაყოფენ. ზედმეტად დიდი MTU ვლინდება როგორც packet-too-big შეცდომა და გაყინული TLS, და არა როგორც სუფთა მარცხი. დააყენეთ იგი ცალსახად და გამოსცადეთ ზღვართან ახლოს დატვირთვით.