NAT და CGNAT: რატომ ფუჭდება სახლის სერვერი

NAT ბევრ მოწყობილობას ერთი საჯარო მისამართის გაზიარების საშუალებას აძლევს მათი გამავალი ტრაფიკის გადაწერით, და მუშაობს იმიტომ, რომ ყოველი საუბარი შიგნიდან იწყება. თამაშის სერვერი პირიქითაა: საუბარს უცნობები გარედან იწყებენ. ჩვეულებრივ სახლის კავშირზე ამას როუტერზე port forward-ით ასწორებ. Carrier-grade NAT-ის (CGNAT) უკან ამას ვერ გააკეთებ, რადგან შენმა პროვაიდერმა შენი როუტერის წინ მეორე NAT დადგა, რომელსაც შენ არ აკონტროლებ - შენი "საჯარო" მისამართი სხვა კლიენტებთან ერთად გაზიარებულია, და შენს მხარეს ვერცერთი forward ვერ მიისაკუთრებს მასზე პორტს. თუ შენი როუტერის WAN მისამართი 100.64-დან 100.127-მდე იწყება, ეს შენ ხარ. გამოსავლებია პროვაიდერისგან საჯარო IPv4 მისამართი, IPv6, relay ან tunnel, ან სერვერი, რომელიც სხვაგან დგას.

ეს სტატია ხსნის, რატომ, ჩამონათვალზე უფრო სიღრმისეულად: როგორ იქცევა NAT, რას ნიშნავს სინამდვილეში NAT-ის ტიპები, რომლებსაც კონსოლები და launcher-ები აჩვენებენ, რატომ მუშაობს "host and invite", როცა გამოყოფილი სერვერი არ მუშაობს, და რომელი გამოსავალი რომელ სიტუაციას ერგება.

რას უკეთებს NAT კავშირს#

შენი როუტერი ტრანსლაციის ცხრილს ინახავს. როცა შენი კომპიუტერი 192.168.1.20-ზე UDP პაკეტს პორტ 50000-დან თამაშის სერვერს უგზავნის, როუტერი წყაროს საკუთარ საჯარო მისამართზე და თავისი არჩევის რომელიმე პორტზე გადაწერს, მიბმას იწერს და პაკეტს აგზავნის. პასუხი იმავე საჯარო პორტზე ბრუნდება, როუტერი მიბმას პოულობს, დანიშნულებას უკან 192.168.1.20:50000-ზე გადაწერს და აწვდის.

ჰოსტინგისთვის ორი შედეგი მნიშვნელოვანია:

• შემომავალი პაკეტები მიბმის გარეშე იყრება. მოთამაშის პირველი პაკეტი შენს სერვერამდე როუტერის საჯარო მისამართზე ჩადის და ცხრილში არაფერი ხვდება. როუტერმა არ იცის, რომელი მანქანისთვისაა.
• მიბმებს ვადა გასდით. UDP მიბმა მხოლოდ მანამ ცოცხლობს, სანამ ტრაფიკი მას ცოცხლად ინახავს. Linux-ზე დაფუძნებული როუტერები ნაგულისხმევად დაახლოებით 30 წამს აძლევენ ერთჯერად UDP ნაკადს და რამდენიმე წუთს დამყარებულს; სამომხმარებლო როუტერები განსხვავდება. თამაში, რომელიც ამაზე დიდხანს ჩუმდება, მიბმას კარგავს, და სერვერის შემდეგი პაკეტი იყრება.

Port forward ხელით დაწერილი მუდმივი მიბმაა, და სწორედ ამიტომ ასწორებს პირველ პრობლემას. Port forwarding თუ ჰოსტინგი ხსნის, როგორ დაწერო ის სწორად.

NAT-ის ქცევის ოთხი ვარიანტი#

ყველა NAT ტრაფიკს ერთნაირად არ ექცევა, და განსხვავებები წყვეტს, შეუძლიათ თუ არა NAT-ის უკან მყოფ ორ მოთამაშეს ერთმანეთთან პირდაპირ დაკავშირება. ძველი სახელები (cone და symmetric) ისევ ის სახელებია, რომლებსაც ხალხი იყენებს; RFC 4787-ის ფორმალური ტერმინები ორ ცალკეულ ქცევას აღწერს - mapping-სა და filtering-ს.

სახლის როუტერების უმეტესობა port-restricted cone-ის მსგავსად იქცევა. ბევრი CGNAT დანერგვა და ზოგი კორპორატიული და მობილური ქსელი სიმეტრიულად იქცევა, რაც peer-to-peer თამაშებისთვის ყველაზე ცუდი შემთხვევაა.

რას გულისხმობენ კონსოლები და launcher-ები NAT-ის ტიპში

კონსოლები ამას სამ ხარისხამდე ამარტივებენ.

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

Carrier-grade NAT#

პროვაიდერებს IPv4 მისამართები წლების წინ ამოეწურათ. Carrier-grade NAT არის ის, თუ როგორ ჭიმავენ დარჩენილს: პროვაიდერი საკუთარ ქსელში დიდ NAT-ს დგამს და ყოველი კლიენტის როუტერს საჯაროს ნაცვლად საერთო დიაპაზონიდან მისამართს აძლევს. შემდეგ ბევრი კლიენტი ინტერნეტში ერთი და იმავე საჯარო მისამართით გადის.

საერთო დიაპაზონი არის 100.64.0.0/10 - ყოველი მისამართი 100.64.0.0-დან 100.127.255.255-მდე - რომელიც RFC 6598-მა სწორედ ამისთვის გამოყო. ის განზრახ განცალკევებულია სახლებში გამოყენებული კერძო დიაპაზონებისგან, რომ სახლის ქსელი და ოპერატორის ქსელი არასოდეს შეეჯახოს ერთმანეთს.

ამ სქემას ზოგჯერ NAT444-ს უწოდებენ, რადგან ტრაფიკი სამ მისამართის სივრცეს კვეთს: შენს კერძო ქსელს, ოპერატორის საერთო დიაპაზონს და საჯარო ინტერნეტს. შენი როუტერის port forward ისევ იქაა და ისევ სწორია, მაგრამ პაკეტები მას ვერასოდეს აღწევს - ისინი ოპერატორის NAT-ზე იყრება, რომელსაც მიბმა არ აქვს და რომლის კონფიგურირებაც შენ არ შეგიძლია.

გვერდითი ეფექტები, რომლებიც შესაძლოა უკვე შეამჩნიე

• საერთო რეპუტაცია. შენი საჯარო მისამართი სხვა კლიენტებთან ერთად გაზიარებულია. თუ რომელიმე მათგანი ბოროტად იქცევა, ვებსაიტები ყველას captcha-ებით ამოწმებენ, ხოლო თამაშის სერვერი, რომელიც ამ მისამართს დაბანავს, ყველას გბანავს.
• პორტების ლიმიტები. ოპერატორის NAT ხშირად ყოველ კლიენტს მთელი დიაპაზონის ნაცვლად პორტების ბლოკს აძლევს. ჩვეულებრივი ბრაუზინგი ამას ვერასოდეს ამჩნევს; პროგრამა, რომელიც ათასობით კავშირს ხსნის, ზოგჯერ ამჩნევს.
• მისამართი, რომელსაც ხედავ, შენი არ არის. შენი საჯარო IP, რომელსაც "what is my IP" საიტი აჩვენებს, ოპერატორის NAT-ის მისამართია. მისი მიცემა მეგობრებისთვის შენს სერვერზე შესასვლელად არაფერს გამოიწვევს.

როგორ გაიგო

1. წაიკითხე WAN ან ინტერნეტის მისამართი შენი როუტერის სტატუსის გვერდზე.
2. იმავე კავშირზე ბრაუზერიდან გაიგე შენი საჯარო მისამართი.
3. თუ განსხვავდება, შენი როუტერის წინ NAT დგას. თუ როუტერის მისამართი 100.64.0.0/10-შია, ეს CGNAT-ია. თუ 192.168.x.x-ში ან 10.x.x.x-შია, უფრო სავარაუდოდ პროვაიდერის მოდემია, რომელიც NAT-ს შენი სახლის შიგნით აკეთებს - double NAT, რომლის გასწორებაც თავად შეგიძლია.

შიგნიდან გაშვებული traceroute იგივეს აჩვენებს: 100.64 დიაპაზონის hop შენი როუტერის მალევე ოპერატორის NAT-ია.

DS-Lite, გავრცელებული ვარიანტი

ბევრი საკაბელო და ოპტიკური პროვაიდერი - მათ შორის დიდები გერმანიაში - Dual-Stack Lite-ს იყენებს. კავშირი ნამდვილ, საჯარო IPv6-ს იღებს, ხოლო IPv4 tunnel-ით პროვაიდერამდე მიდის და ოპერატორის NAT-ით ზიარდება. როუტერმა შეიძლება IPv4 WAN მისამართი საერთოდ არ აჩვენოს. თამაშის ჰოსტისთვის ეფექტი IPv4-ზე იგივეა, რაც CGNAT-ის, ერთი სასარგებლო განსხვავებით: შემომავალი IPv6 მუშაობს, ასე რომ IPv6-ით მისაწვდომი სერვერი შესაძლებელია, თუ შენს მოთამაშეებსაც აქვთ IPv6. IPv6 და თამაშის სერვერები ხსნის, რამდენად შორს მიგიყვანს ეს, რაც საჯარო სერვერისთვის საკმარისად შორს არ არის.

რატომ მუშაობს "host and invite", როცა სერვერი არ მუშაობს#

აი თავსატეხი, რომელსაც ხალხი აწყდება: იგივე CGNAT კავშირი, რომელიც გამოყოფილ სერვერს ვერ ამუშავებს, co-op სესიას ჰოსტავს, რომელსაც მეგობრები Steam-ის მოწვევებით უერთდებიან. ეს წინააღმდეგობა არ არის.

ბევრ თამაშში მოთამაშის მიერ დაჰოსტილ სესიებს ღია პორტი არ სჭირდება. ორივე მხარე გამავალ კავშირს იწყებს rendezvous სერვისთან, რომელიც თითოეულს მეორის საჯარო მისამართსა და პორტს ეუბნება. შემდეგ თითოეული ერთსა და იმავე მომენტში მეორეს პაკეტებს უგზავნის და საკუთარ NAT-ზე მიბმას ქმნის, რომელიც მეორის პაკეტებს უშვებს. ეს UDP hole punching-ია, და ორივე ბოლოში cone-ტიპის NAT-ებით ჩვეულებრივ მუშაობს, CGNAT-შიც კი.

როცა ფუჭდება - ერთი მხარე სიმეტრიულია, ან ორივე შემზღუდველი ოპერატორების უკანაა - პლატფორმა relay-ზე გადადის. Steam-ის ქსელურ ფენას შეუძლია სესიის ტრაფიკი Valve-ის relay ქსელით გაატაროს, Valheim-ის crossplay სესიები კი PlayFab-ის relay-ზე გადის; სხვა პლატფორმებს საკუთარი აქვთ. Relay-ით გატარებული ტრაფიკი შემოვლით მიდის და დაყოვნებას ამატებს, მაგრამ უკავშირდება.

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

Timeout-ები და სავსე ცხრილები: NAT-ის პრობლემები დაკავშირების შემდეგ#

NAT-ის ყველა პრობლემა კავშირს არ აჩერებს. ორი მაშინ ჩნდება, როცა მოთამაშეები უკვე შიგნით არიან.

მიბმები, რომლებსაც სესიის შუაში ვადა გასდით. მოთამაშესა და სერვერს შორის ყოველი NAT UDP მიბმას მხოლოდ მანამ ინახავს ცოცხლად, სანამ პაკეტები მიედინება. თამაშები მდგომარეობას წამში ბევრჯერ აგზავნიან, ამიტომ თამაშის დროს ამას მნიშვნელობა არასოდეს აქვს. მნიშვნელობა აქვს ჩუმ მომენტებში: მოთამაშე, რომელიც მენიუში ზის, ჩატვირთვის ეკრანი, რომელიც ჭედავს, თამაში, რომელიც განახლებებს მხოლოდ მაშინ აგზავნის, როცა რაიმე იცვლება. თუ შუალედი გზაზე ყველაზე მოკლე timeout-ს გადააჭარბებს - იაფი სახლის როუტერი ან აგრესიულად მორგებული ოპერატორის NAT - მიბმა ქრება, და სერვერის შემდეგი პაკეტი იყრება. მოთამაშე timeout-ით გათიშვას ხედავს "უმიზეზოდ", ჩვეულებრივ ყოველ ჯერზე ერთი და იმავე ტიპის მომენტში. თამაშები ამას keep-alive პაკეტებით უმკლავდებიან, და უმეტესობა ამას კარგად აკეთებს; სადაც კონკრეტული თამაში ამას არ აკეთებს, გამოსავალი მოთამაშის მხარესაა (როუტერი უფრო გრძელი UDP timeout-ებით) და არა სერვერზე.

სავსე connection-tracking ცხრილი შენს საკუთარ მანქანაზე. თუ სერვერს საკუთარ Linux მანქანაზე ან VDS-ზე stateful firewall-ით უშვებ, kernel ყოველ ნაკადს აკვირდება, და ცხრილს ზომის ლიმიტი აქვს. გაყალბებული პაკეტების flood-მა, ან ძალიან დატვირთულმა სერვერმა სკანერთან ერთად, შეიძლება ის გაავსოს. როცა ივსება, kernel-ის log ამას პირდაპირ წერს:

nf_conntrack: nf_conntrack: table full, dropping packet

ამის შემდეგ ახალი მოთამაშეები ვერ უკავშირდებიან, არსებულები კი აგრძელებენ. შეადარე მიმდინარე რაოდენობა ლიმიტს cat /proc/sys/net/netfilter/nf_conntrack_count-ით და nf_conntrack_max-ით. ლიმიტის აწევა დატვირთულ სერვერზე გეხმარება; flood-ის წინააღმდეგ პასუხი upstream ფილტრაციაა და არა უფრო დიდი ცხრილი. Firewall-ის წესები, რომლებსაც მნიშვნელობა აქვს წესების მხარეს განიხილავს.

გამოსავლები, შედარებით#

ჯერ პროვაიდერს ჰკითხე. ბევრი პროვაიდერი კლიენტს მოთხოვნისამებრ CGNAT-იდან გადაიყვანს, ზოგჯერ უფასოდ, ზოგჯერ ფასიან "public IP" ოფციად, ზოგჯერ მხოლოდ ბიზნეს ტარიფებზე. კონკრეტულად საჯარო IPv4 მისამართი ითხოვე და არა უბრალოდ "static IP", და დარწმუნდი, რომ ამის შემდეგ როუტერის WAN მისამართი არა-100.64 მისამართად იქცა.

IPv6 უფასო და სუფთაა, თუ ორივე ბოლოს აქვს, და უსარგებლო მოთამაშეებისთვის, რომლებსაც არ აქვთ. კარგია ოთხი მეგობრისთვის, რომლებმაც შეამოწმეს; საჯარო სერვერისთვის გეგმა არ არის.

Overlay ქსელი ყველას ერთმანეთთან ერთ კერძო ქსელში აერთიანებს. არც პორტები, არც NAT, არც საჯარო ექსპოზიცია. ყოველმა მოთამაშემ უნდა დააყენოს და შეუერთდეს, რაც მას ერთმანეთის მცნობი ჯგუფებით ზღუდავს.

Tunnel ან relay შენს სახლის სერვერს საჯარო მისამართს სხვის ქსელში აძლევს და ტრაფიკს შენი სახლიდან გამავალი კავშირით აგზავნის. ეს ერთადერთი გზაა CGNAT-ის უკან საჯარო სერვერის გასაშვებად პროვაიდერის შეცვლის გარეშე, და მას ფასი აქვს დაყოვნებაში და მოთამაშეების ნამდვილი მისამართების დაკარგვაში. Tunnel-ები და proxy-ები თამაშის სერვერებისთვის განიხილავს playit.gg-ს, frp-ს, WireGuard-ს VPS-ზე და კომპრომისებს.

სერვერის სახლიდან გატანა პრობლემას აშორებს და არა მის გვერდის ავლას ცდილობს. ჰოსტინგზე მყოფი სერვერი საჯარო მისამართზე დგას NAT-ის გარეშე, რომელზეც ფიქრი მოგიწევდა. თამაშის სერვერი სახლში თუ ქირით ამ გადაწყვეტილების დანარჩენ ნაწილს აწონ-დაწონის.

NAT, რომელსაც ჰოსტინგზე მყოფ სერვერზე ვერ ხედავ#

ჰოსტინგზე მყოფი სერვერებიც ჩვეულებრივ მცირე NAT-ის უკან არიან, მაგრამ ისეთის, რომელიც შენთვის უკვე მორგებულია. Pterodactyl-ზე დაფუძნებულ პანელზე, რომელზეც RE:NODE მუშაობს, ყოველი სერვერი საკუთარ კონტეინერში ცხოვრობს, ხოლო node გამოყოფილ პორტებს საკუთარი საჯარო მისამართიდან ამ კონტეინერში აქვეყნებს. მოთამაშეები node-ის მისამართსა და გამოყოფილ პორტს უკავშირდებიან; ტრანსლაცია კონტეინერში ფიქსირებული მიბმაა, ზუსტად ისეთი, როგორიც port forward, რომელიც სხვამ დაწერა და უვლის.

ორი გვერდითი ეფექტი ზოგჯერ ჩნდება:

• თამაში საკუთარ თავს კერძო მისამართით ხედავს. რამდენიმე თამაში ბეჭდავს ან აცხადებს მისამართს, რომელზეც თავი ჰგონია. კონტეინერის შიგნით ეს კერძო მისამართია, რაც კავშირებისთვის უვნებელია, მაგრამ log-ებში დამაბნეველი. მოთამაშეებისთვის მისაცემი მისამართი ის არის, რომელიც პანელში სერვერის გვერდზე წერია.
• თამაში მოთამაშეების ნამდვილ მისამართებს ხედავს. Tunnel-ისგან განსხვავებით, პორტის მიბმა შემომავალი პაკეტების წყაროს მისამართს ინახავს, ასე რომ ban-ები, log-ები და IP-ზე დაფუძნებული ლიმიტები ჩვეულებრივ მუშაობს.

RE:NODE-ზე ყოველი გეგმა წერს, რამდენ პორტს მოიცავს, ხოლო დამატებითი - query, RCON - Network ჩანართზე ემატება. გადასამისამართებელი არაფერია და გზაზე CGNAT არ არის, რადგან სერვერი არავის სახლის როუტერის უკან არ დგას.

FAQ#

შემიძლია port forward CGNAT-ის უკან?

არა. პორტი, რომლის გახსნაც დაგჭირდებოდა, პროვაიდერის NAT-ზეა, რომლის კონფიგურირებაც არ შეგიძლია. შენი როუტერის forward სწორია, მაგრამ ტრაფიკს ვერასოდეს იღებს. გამოსავლებია პროვაიდერისგან საჯარო IPv4 მისამართი, IPv6, tunnel ან relay, ან სერვერის სხვაგან დაჰოსტვა.

CGNAT იგივეა, რაც double NAT?

ერთმანეთს ჰგვანან, მაგრამ განსხვავდებიან იმით, ვის ეკუთვნის მეორე NAT. Double NAT ჩვეულებრივ ნიშნავს ორ როუტერს შენს საკუთარ სახლში, მაგალითად პროვაიდერის მოდემს და შენს როუტერს, და მისი გასწორება bridge რეჟიმით შეგიძლია. CGNAT პროვაიდერის ქსელშია, და მისი შეცვლა მხოლოდ პროვაიდერს შეუძლია.

რატომ წერია ჩემს NAT ტიპზე Strict?

შენი კავშირი არ უშვებს მოულოდნელ შემომავალ ტრაფიკს და პორტებს ისე აბამს, რომ hole punching-ს აფუჭებს, ხშირად CGNAT-ის ან შემზღუდველი როუტერის გამო. გამოყოფილ სერვერებს მაინც ჩვეულებრივ უერთდები; გაგიჭირდება მოთამაშის სესიების ჰოსტინგი ან ზოგიერთ peer-to-peer lobby-ში შესვლა.

ასწორებს VPN CGNAT-ს ჰოსტინგისთვის?

ჩვეულებრივი სამომხმარებლო VPN არა, რადგან ისიც საერთო NAT-ია, რომელიც შენთვის პორტებს არ გადაამისამართებს. VPN ან tunnel სერვისი, რომელიც აშკარად გთავაზობს port forwarding-ს, ასწორებს, დამატებითი დაყოვნებისა და იმის ფასად, რომ შენი მოთამაშეების ტრაფიკი ამ პროვაიდერზე გადის.

შეუშლის ჩემი მოთამაშეების NAT ტიპი ჩემს სერვერზე შესვლას?

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