IPv6 და თამაშის სერვერები: სად ეხმარება და სად გიშლის

გაუშვი ორივე stack ან დარჩი IPv4-ზე. სერვერი, რომელიც მხოლოდ IPv6-ით ჩანს, მოთამაშეების დიდი ნაწილისთვის მიუწვდომელია და ისინი ვერასოდეს მიხვდებიან რატომ, ხოლო სერვერი AAAA ჩანაწერით და მის უკან არაფრით, უარესია, ვიდრე სერვერი AAAA ჩანაწერის გარეშე, რადგან „ვერ ვუკავშირდები“-ს ცვლის „ხანდახან უკავშირდება, ზოგისთვის, ზოგი ქსელიდან“-ზე.

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

რას ცვლის IPv6 და რას არა#

IPv6 იგივე ინტერნეტია უფრო დიდი მისამართის ველით. მარშრუტიზაცია, TCP, UDP, DNS და ყველა თამაშის პროტოკოლი მის თავზე იდენტურად მუშაობს. რა იცვლება, ზუსტად ღირს ცოდნა, რადგან მის გარშემო არსებული ფოლკლორის ნახევარი არასწორია.

• მისამართები 32-ის ნაცვლად 128 ბიტია. დეფიციტი დასრულდა. ერთ საშინაო კავშირს ჩვეულებრივ /56 ან /48 ეძლევა, რაც მთელი IPv4 ინტერნეტზე მეტი მისამართია.
• NAT ჩვეულებრივ არ არის. ყველა მოწყობილობას გლობალურად მარშრუტირებადი მისამართი აქვს, რაც ნიშნავს, რომ firewall ერთადერთი რამაა მასსა და ინტერნეტს შორის. IPv4-ზე საშინაო როუტერის NAT შემთხვევით ამ საქმეს აკეთებდა. IPv6-ზე შემთხვევით არაფერი აკეთებს.
• ARP აღარ არის, მის ადგილას Neighbour Discovery დგას, რომელიც ICMPv6-ზე მუშაობს. ამიტომ ICMPv6-ის დაბლოკვა არღვევს იმას, რასაც ICMP-ის დაბლოკვა IPv4-ზე არასოდეს არღვევდა.
• როუტერები არ ფრაგმენტირებენ. IPv4-ზე შუალედურ როუტერს შეეძლო ზედმეტად დიდი პაკეტის დაჭრა. IPv6-ზე ის უკან Packet Too Big შეტყობინებას აგზავნის და გამგზავნი მასზე უნდა მოახდინოს რეაქცია. თუ ეს შეტყობინება გაფილტრულია, დიდი პაკეტები ქრება და პატარები - არა.
• მინიმალური MTU არის 1280 ბაიტი, IPv4-ზე 576-ის წინააღმდეგ.

რა არ იცვლება: latency, გამტარუნარიანობა, jitter და მანძილი შენს მოთამაშეებამდე. IPv6 პაკეტები იმავე ბოჭკოზე მოძრაობს იმავე სისწრაფით. თუ ვინმე გეუბნება, რომ IPv6 უფრო სწრაფია, ის აღწერს გზას, რომელიც უკეთ იყო peering-ში, და არა პროტოკოლის თვისებას. სამი რიცხვი, რომელიც სინამდვილეში წყვეტს, როგორი შეგრძნებაა თამაში, არის აღწერილი latency-ში, jitter-სა და packet loss-ში.

IPv6 მისამართის წაკითხვა და აკრეფა#

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

2001:0db8:0000:0000:0000:0000:0000:0010   full form2001:db8::10                              the same address, written sanely

პრეფიქსები, რომლებსაც მართლა შეხვდები:

სინტაქსის დეტალი, რომელიც კონფიგურაციის ფაილებს არღვევს: როცა მისამართი პორტის გვერდით ჩნდება, ის კვადრატულ ფრჩხილებშია. [2001:db8::10]:25565 არის სერვერი, 2001:db8::10:25565 სულ სხვა მისამართია და ალბათ შეცდომაა, რომელსაც ათ წუთს მიაჩერდები. იგივე ფრჩხილების წესი მოქმედებს URL-ებში, უმეტეს bind დირექტივაში და connection string-ებში.

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

რომელი მხარე ნამდვილად უჭერს მხარს#

მხარდაჭერა ერთი კითხვა არ არის, ოთხია: უსმენს თუ არა სერვერის binary IPv6-ზე, უკავშირდება თუ არა კლიენტი, იღებს თუ არა master სერვერების სია ან matchmaking მას, და ესმის თუ არა შენს ინსტრუმენტებს. ოთხივე დიახ უნდა იყოს, და მარცხები უხმოა.

Minecraft Java-ს შემთხვევას ერთი კონკრეტული მახე აქვს, რომელიც სახელს იმსახურებს. ::-ზე მიბმული socket Linux-ზე IPv4 კავშირებსაც იღებს, რადგან net.ipv6.bindv6only sysctl ნაგულისხმევად 0-ია და IPv4 კლიენტები IPv4-mapped მისამართებად მოდიან. მაგრამ JVM, გაშვებული -Djava.net.preferIPv4Stack=true-ით, IPv6 socket-ებს საერთოდ არ შექმნის, ამიტომ სერვერი მხოლოდ IPv4-ია, მიუხედავად იმისა, რას აკეთებს დანარჩენი მანქანა. ეს flag უამრავ ჩაკოპირებულ გაშვების სკრიპტში ჩანს. თუ flag-ების სიით მუშაობ, რომელიც შენ არ დაგიწერია, შეამოწმე ის, სანამ დაასკვნი, რომ თამაში IPv6-ს არ უჭერს მხარს.

Dual-stack სწორად: bind, ჩანაწერი, firewall#

სამი რამ ერთდროულად უნდა იყოს ჭეშმარიტი, და ხალხი ჩვეულებრივ ერთს ან ორს აკეთებს.

1. სერვისი IPv6-ზე უსმენს. შეამოწმე ss-ით და არა იმედით. მისამართი 0.0.0.0:25565 მხოლოდ IPv4-ია. [::]:25565 ორივეა, ნაგულისხმევ Linux ბირთვზე.
2. DNS მას აქვეყნებს. AAAA ჩანაწერი იმავე სახელზე, რომელიც A ჩანაწერს ატარებს. DNS ჩანაწერები ახსნილი ჩანაწერების ტიპებს აღწერს, ხოლო ქვედომენები სერვერებისთვის აღწერს, როგორ შეინახო მისამართი ერთ ადგილას, რომ მეორე ჩანაწერის დამატება მეორე რამის დავიწყებას არ ნიშნავდეს.
3. firewall მას უშვებს. IPv6-ის წესები iptables-სა და ip6tables-ში ცალკე წესების ნაკრებია, და კლასიკური შედეგია სერვისი, რომელიც IPv4-ზე იდეალურად მუშაობს და IPv6-ზე უხმოდ იჭრება.

$ ss -ltnp | grep 25565LISTEN 0 128 *:25565 *:*$ dig +short AAAA play.example.com @1.1.1.12001:db8::10$ ip6tables -L INPUT -n --line-numbers

ufw-ზე IPv6-ის დამუშავებას ერთი ხაზი აკონტროლებს /etc/default/ufw-ში, და წესი, რომელსაც დაამატებ, ორივე stack-ზე მხოლოდ მაშინ მოქმედებს, როცა ის ჩართულია:

IPV6=yes

თუ ამის ნაცვლად nftables-ს იყენებ, inet ოჯახი ორივე პროტოკოლს ერთი წესების ნაკრებით ფარავს, რაც შეცდომის მთელ ამ კატეგორიას აქრობს. წესები firewall-ში, რომლებსაც მნიშვნელობა აქვს მთელ წესების ნაკრებს ორივე სინტაქსით შეიცავს, და ufw-ის სახელმძღვანელო ინსტრუმენტის უფრო გრძელი გავლაა.

კონტეინერები მეორე გავრცელებული ხვრელია. Docker ისტორიულად IPv6-ის გამორთულით მოდის, ამიტომ კონტეინერი გამოქვეყნებული პორტით IPv4-ზე პასუხობს და IPv6-ზე არა, მაშინაც კი, როცა host სრულად dual-stack-ია. მისი ჩართვა ნიშნავს "ipv6": true-სა და fixed-cidr-v6-ს /etc/docker/daemon.json-ში, და daemon-ის restart - იხილე Docker VDS-ზე გარშემო არსებული მოწყობისთვის.

ICMPv6 და MTU: მარცხი, რომელიც packet loss-ს ჰგავს#

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

Neighbour Discovery, რომელიც შემდეგი hop-ის link-layer მისამართს პოულობს, არის ICMPv6. Router Advertisement-ები, რითაც უმეტესი host საერთოდ იღებს მისამართს, არის ICMPv6. და Packet Too Big, ტიპი 2, არის გზა, რითაც გამგზავნი სწავლობს პაკეტის ზომის შემცირებას, რადგან არცერთი IPv6 როუტერი მის მაგივრად არ დაფრაგმენტირებს.

დაბლოკე ICMPv6 ტიპი 2 გზაზე სადმე და მიიღებ ძალიან კონკრეტულ სიმპტომს: პატარა პაკეტები მუშაობს, handshake-ები სრულდება, კავშირი მყარდება, და შემდეგ ყველაფერი, რაც სრული ზომის პაკეტს საჭიროებს, ქრება. თამაში დაკავშირდება და შემდეგ პირველ დიდ state განახლებაზე გაიყინება. web გვერდი header-ებს დააბრუნებს და body-ზე ჩაიკიდება. ის ზუსტად packet loss-ს ჰგავს და არ არის - იხილე თავი loss-ის სხვა პრობლემებისგან გამოყოფაზე latency-ში, jitter-სა და packet loss-ში, რადგან დიაგნოზი იგივეა და წამალი არა.

დასამახსოვრებელი წესი მარტივია: დაუშვი ICMPv6 შემომავალი, თუ გინდა rate limit-ით, და არასოდეს გაწყვიტო მთლიანად. გვირაბით მიწოდებული IPv6 კავშირები, რომლებსაც ზოგი საშინაო პროვაიდერი ჯერ კიდევ გასცემს, გამოსაყენებელ MTU-ს 1500-ზე ქვემოთ ამცირებს და ამ მარცხს ბევრად უფრო სავარაუდოს ხდის სწორედ იმ მოთამაშეებისთვის, ვისაც დიაგნოსტიკა ყველაზე ნაკლებად შეუძლია.

ბლოკირება, allow-list-ები და ლოგები: /64-ის წესი#

IPv4 ბლოკი ერთ მისამართზე და ჩვეულებრივ ერთ ოჯახზე ეცემა. IPv6 ბლოკი ერთ /128-ზე ეცემა ერთ მისამართზე, რომელსაც კლიენტი საათში კარგად შეიძლება შეუცვალოს, რადგან privacy extension-ები host-ებს დროებით მისამართებს საკუთარ პრეფიქსში განზრახ აძლევს.

პრაქტიკული წესი: იდენტობის ერთეული IPv6-ზე არის /64 და არა მისამართი.

• დაბლოკე `/64`. 2001:db8:1234:5678::/64 არის ის, როგორც ერთი მომხმარებლის კავშირი გამოიყურება. 2001:db8:1234:5678::a1b2-ის დაბლოკვა ერთ ინტერფეისის იდენტიფიკატორს ბლოკავს, სანამ ის არ შეიცვლება.
• allow-list-შიც `/64` ჩასვი, თორემ ადმინი, რომელიც დილით შეუშვი, შუადღეს უცხო იქნება.
• ლოგში პრეფიქსი ჩაწერე. სრული მისამართების შენახვა და მათი მიხედვით დაჯგუფება უსარგებლო სტატისტიკას იძლევა; დაჯგუფე პირველი 64 ბიტით.
• შეამოწმე, იღებს თუ არა შენი ინსტრუმენტები პრეფიქსს საერთოდ. გასაკვირად ბევრი IPv4-ისთვის დაწერილი ban სისტემა მხოლოდ შიშველ მისამართს იღებს, რაც ნიშნავს, რომ IPv6 ბლოკები არ მუშაობს და თვეების განმავლობაში არავინ ამჩნევს.
• `/64`-ზე უხეშად ნუ წახვალ უდარდელად. /48 შეიძლება მთელი პროვაიდერის რეგიონი იყოს, ხოლო /32 ხშირად მთელი პროვაიდერია.

იგივე ეხება rate limit-ებს, რომლებიც აპლიკაციის დონის ბოროტად გამოყენების რეალური დაცვაა - მისამართის მიხედვით დათვლას აზრი არ აქვს, როცა თავდამსხმელს ერთ subnet-ში 18 კვინტილიონი აქვს. Rate limit-ები და ბოროტად გამოყენება აღწერს იმ ლიმიტების ფორმას, რომლებიც მუშაობს, ხოლო რას ვაკეთებთ თავდასხმებზე პატიოსანია იმაზე, პრობლემის რომელ ნაწილს წყვეტს ფილტრაცია და რომელს არა.

მისი ტესტირება და რას ნიშნავს „მუშაობს“#

dual-stack მანქანიდან ტესტირება თითქმის არაფერს ამტკიცებს, რადგან ის IPv4-ზე ჩუმად გადავა იმ წამს, როცა IPv6 ჩავარდება. უმეტესი კლიენტი ორივეს ცდის და IPv6-ს მოკლე დროის უპირატესობით ანიჭებს უპირატესობას, ამიტომ გატეხილი IPv6 გზა შეცდომის ნაცვლად წამის ნაწილის დაგვიანებად ჩანს. ეს შესანიშნავია მომხმარებლებისთვის და საშინელია ტესტირებისთვის.

აიძულე პროტოკოლი:

$ ping6 play.example.com$ curl -6 -sI https://api.example.com$ mtr -6 play.example.com$ dig AAAA play.example.com @2606:4700:4700::1111

თამაშისთვის ერთადერთი რეალური ტესტია კლიენტი IPv6-ის მქონე ქსელზე გამორთული IPv4-ით, ან მობილური კავშირი ოპერატორზე, რომელიც მხოლოდ IPv6-ზე მუშაობს NAT64-ით. თუ ეს კლიენტი უკავშირდება და რჩება დაკავშირებული რუკის შეცვლისა და დიდი state სინქრონიზაციის განმავლობაში, გზა მუშაობს. თუ უკავშირდება და იყინება, დაბრუნდი და წაიკითხე ICMPv6-ის თავი.

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

სად იმსახურებს IPv6 ადგილს ნამდვილად#

ამ პოსტის უმეტესობა გაფრთხილებებია, ამიტომ აი მეორე მხარე. არის სამი სიტუაცია, სადაც IPv6 უკეთესი პასუხია და ერთი, სადაც ერთადერთია.

სახლიდან ჰოსტინგი CGNAT-ის უკან. თუ შენი პროვაიდერი carrier-grade NAT-ის უკან გაყენებს, არ გაქვს საჯარო IPv4 მისამართი, რომელზეც პორტს გადამისამართებ, და როუტერის არანაირი კონფიგურაცია მას ვერ შექმნის. ბევრი იმავე კავშირიდან რეალურ, მარშრუტირებად IPv6 პრეფიქსს გასცემს. მხოლოდ IPv6 საშინაო სერვერი ზოგადი აუდიტორიისთვის არ გამოდგება, მაგრამ ის რეალური ვარიანტია კერძო ჯგუფისთვის, ვისაც ყველას აქვს IPv6. სახლში თვითჰოსტინგი თუ ქირაობა მას სხვა ხარჯებს ადარებს, რაც შენს საკუთარ ხაზზე სერვერის გაშვებას ახლავს.

როცა სხვამ უნდა დაგამატოს allow-list-ში. თუ API-ს, გადახდის პროვაიდერს ან კორპორატიულ firewall-ს შენი სერვერის დაშვება სჭირდება, IPv6 გაძლევს სტაბილურ პრეფიქსს IPv4 მისამართებზე მიმაგრებული დეფიციტური ფასის გარეშე. სტატიკური მისამართები და გჭირდება თუ არა ის უფრო ფართო კითხვაა, როდის ღირს გამოყოფილ მისამართში გადახდა.

ყველაფერი, რაც უბრალო HTTP ან ბაზის კავშირია. Web, API და ბაზის ტრაფიკი IPv6-ზე უჩვეულო არაფერია და წლებია ასეა. თუ შენი აპი სერვისს ეკავშირება, რომელიც AAAA ჩანაწერებს აქვეყნებს, ის ალბათ უკვე IPv6-ს იყენებს და არასოდეს შეგიმჩნევია. ეს არის სასურველი მდგომარეობა.

მოთამაშეებამდე მისვლა მხოლოდ IPv6 მობილურ ქსელებში. ზოგი ოპერატორი მხოლოდ IPv6-ზე მუშაობს NAT64 თარგმნით edge-ზე. ეს მოთამაშეები IPv4 სერვერებს თარგმნის საშუალებით აღწევენ, რაც TCP-სა და უმეტეს UDP-ზე მუშაობს და ამატებს hop-ს და თარგმნის მდგომარეობის ცხრილს, რომელიც ხანდახან უქმ სესიებს აგდებს. AAAA ჩანაწერის გამოქვეყნება თარჯიმანს გზიდან სწორედ ამ მოთამაშეებისთვის ხსნის.

RE:NODE-ზე ყველა სერვერი IPv4 მისამართითა და პორტით ქვეყნდება, და ეს არის ის, რაც შენს DNS ჩანაწერებში მიდის. IPv6 არ არის ის, რასაც სტანდარტულად ვაქვეყნებთ, ამიტომ თუ შენი პროექტი მასზე ნამდვილად არის დამოკიდებული, ჰკითხე, სანამ მასზე დააპროექტებ და არა შემდეგ. მხარდაჭერა პანელიდან ან Discord-იდან ბილეთია, და პასუხი იქნება პირდაპირი დიახ ან არა და არა ალბათ.

FAQ#

უნდა გამოვაქვეყნო AAAA ჩანაწერი ჩემი თამაშის სერვერისთვის?

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

შემიძლია თამაშის სერვერი მხოლოდ IPv6-ზე გავუშვა?

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

ხდის IPv6 ჩემს სერვერს უფრო სწრაფს?

არა. ეს იგივე გზაა იგივე სისწრაფით. ერთადერთი გაზომვადი განსხვავება კავშირის დამყარებისას არის, და მხოლოდ კლიენტებისთვის, რომლებიც სხვა შემთხვევაში carrier NAT64 gateway-ით ითარგმნებოდნენ.

როგორ დავბლოკო IPv6 მოთამაშე სწორად?

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

რატომ მუშაობს ჩემი სერვერი IPv4-ზე, მაგრამ არა IPv6-ზე?

სამი ჩვეულებრივი მიზეზი, თანმიმდევრობით: პროცესი ::-ის ნაცვლად 0.0.0.0-ზეა მიბმული, IPv6 firewall წესების ნაკრებს არ აქვს წესი, რომელიც IPv4-ისთვის დაამატე, ან კონტეინერის runtime-ს IPv6 გამორთული აქვს. ss -ltnp პირველს ერთ ხაზში პასუხობს.