Sons of the Forest სერვერი სიაში არ ჩანს ან ვერ უერთდები

როცა Sons of the Forest dedicated server სიაში არ ჩანს ან ხალხს არ უშვებს, მიზეზი თითქმის ყოველთვის ხუთიდან ერთ-ერთია და სიმპტომი გეუბნება, რომელი. სიაში არ ჩანს, მაგრამ მისამართით უერთდები: ან query პორტი 27016, ან LanOnly. სიაშია, მაგრამ ყოველი შეერთება timeout-ით მთავრდება: game პორტი 8766 ან არასწორ ინტერფეისზე მიბმული IpAddress. უერთდება და ჩატვირთვის ეკრანზე სამუდამოდ ჩერდება: BlobSync პორტი 9700. გუშინ მუშაობდა, დღეს ყველას უარყოფს: თამაშის patch გამოვიდა და სერვერი არ განახლებულა. უარყოფს მხოლოდ ერთ ადამიანს: მისი პაროლი, კლიენტის ვერსია ან ქსელი. სამივე პორტი UDP-ა და TCP-ს გახსნა ყველაზე გავრცელებული გზაა, რომ ყველაფერი სწორად გააკეთო და მაინც არაფერი იმუშაოს.

ეს გზამკვლევი თანმიმდევრობით ჩაივლის თითოეულ მათგანს და გაჩვენებს შემოწმებებს, რომლებიც მათ ერთმანეთისგან განასხვავებს. ინსტალაცია, dedicatedserver.cfg-ის ყველა გასაღები და owner-ების სია აღწერილია Sons of the Forest dedicated server-ის გზამკვლევში; save-ის სლოტები და სამყაროს გადატანა - Sons of the Forest-ის პარამეტრებსა და save-ებში. აქ ერთადერთი თემაა, როგორ მოხვდნენ მოთამაშეები მენიუდან სამყაროში.

სიმპტომი მიაბი მიზეზს#

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

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

სამი პორტი და რას არღვევს თითოეული#

Sons of the Forest სამ UDP პორტს იყენებს და სამივე dedicatedserver.cfg-ში მოდის:

{  "IpAddress": "0.0.0.0",  "GamePort": 8766,  "QueryPort": 27016,  "BlobSyncPort": 9700}

თითოეული თავისებურად ირღვევა და ეს გვეხმარება: დახურულ პორტს ხშირად მხოლოდ სიმპტომითაც დაასახელებ.

• `QueryPort` (`27016`) არის ის, რითაც Steam-ის master server და თამაშის შიდა ბრაუზერი სერვერს ხედავს, მის სახელსა და მოთამაშეთა რაოდენობას კითხულობს და ping-ს ზომავს. დაბლოკე და სერვერი ისევ მუშაობს და პირდაპირ შეერთებებსაც იღებს, მაგრამ სიაში არასოდეს ჩნდება. თუ სია სერვერს ping-ის გარეშე ან მოძველებული მოთამაშეთა რაოდენობით აჩვენებს, query ტრაფიკი წყვეტილად ან საერთოდ არ აღწევს.
• `GamePort` (`8766`) თამაშის რეალურ სესიას ატარებს. დაბლოკე და სერვერი შეიძლება სიაში გამოჩნდეს - query პორტი ხომ პასუხობს - მაგრამ შეერთებაზე დაჭერა timeout-ით მთავრდება.
• `BlobSyncPort` (`9700`) შემოსულ მოთამაშეს სამყაროს მდგომარეობას გადასცემს. დაბლოკე და კავშირი დგება, ჩატვირთვის ეკრანი ჩნდება და არასოდეს სრულდება. ეს ის პორტია, რომელსაც ხალხი ივიწყებს: Steam-ის თამაშების უმეტესობას მხოლოდ პირველი ორი აქვს და სხვა თამაშიდან გადმოწერილ ჩამონათვალში ის არ იქნება.

სამივე უნდა იყოს UDP. სახლის როუტერების port forwarding გვერდები ხშირად TCP-ზე ან „TCP/UDP“-ზეა ნაგულისხმევად დაყენებული; შეამოწმე, რომელი აირჩიე. 8766 TCP-ზე გადამისამართება ამ თამაშისთვის არაფერს აკეთებს. თუ განსხვავება შენთვის ახალია, TCP vs UDP თამაშის სერვერებისთვის ხსნის, რატომ იყენებენ თამაშები UDP-ს და რატომ ართულებს ეს ტესტირებას.

სამივე ნომრის შეცვლა შეგიძლია. ჩვეულებრივი მიზეზი ერთსა და იმავე მანქანაზე მეორე სერვერია და მაშინ სამივე პორტი ორ სერვერს შორის განსხვავებული უნდა იყოს - ორი სერვერი ერთ BlobSync პორტზე ზუსტად ჩატვირთვაზე გაჩერების სიმპტომს იძლევა იმ სერვერისთვის, რომელიც მეორე გაიშვა. როცა კონფიგში პორტს ცვლი, ერთდროულად შეცვალე forward-იც, firewall-ის წესიც და ყველაფერი, რაც მოთამაშეებს აკრეფა უთხარი. ერთ ადგილას შეცვლილი და სხვაგან დარჩენილი პორტი „დალაგების მერე გაფუჭდა“ ტიპის ისტორიების დიდი ნაწილია. თამაშის, query და გადაცემის პორტების ზოგადი სურათი თამაშის სერვერის პორტების განმარტებაშია, ხოლო query პორტები და A2S გვიჩვენებს, რას პასუხობს ფაქტობრივად query პორტი.

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

IpAddress: რას აკეთებს bind პარამეტრი სინამდვილეში#

IpAddress არის ლოკალური მისამართი, რომელზეც სერვერი უსმენს. ის არ არის მისამართი, რომელსაც მოთამაშეები აკრეფენ, და არ არის შენი public IP.

0.0.0.0 ნიშნავს მანქანის ყველა ინტერფეისს და სახლის კომპიუტერზე, VPS-ზე თუ container-ში სწორედ ეს გინდა. შეცდომა, რომელიც ისევ და ისევ მეორდება, არის public მისამართის აქ ჩაწერა, რადგან ჩანს, თითქოს სერვერმა საკუთარი მისამართი უნდა იცოდეს. როუტერის უკან მყოფ მანქანაზე public მისამართი ამ მანქანის არც ერთ ინტერფეისს არ ეკუთვნის - ის როუტერს ეკუთვნის - ამიტომ სერვერი ცდილობს მისამართზე მოსმენას, რომელიც მას არ აქვს. build-ის მიხედვით, ეს ან გაშვებისას ვარდება, ან იძლევა სერვერს, რომელიც მუშაობს და რომელსაც ვერავინ აღწევს.

0.0.0.0-ისგან განსხვავებული მნიშვნელობის დაყენების ორი კანონიერი მიზეზია:

• მანქანა რამდენიმე ქსელური ინტერფეისით, მაგალითად სერვერი public და private ქსელით, სადაც თამაში ერთზე გინდა და არა მეორეზე. გამოიყენე ამ ინტერფეისის მისამართი ზუსტად ისე, როგორც ოპერაციული სისტემა აჩვენებს.
• მანქანა რამდენიმე public მისამართით, სადაც თითოეულ თამაშის სერვერს თავისი უნდა ჰქონდეს. აქაც მისამართი ისეთი უნდა იყოს, რომელიც მანქანას რეალურად აქვს.

Windows-ზე ipconfig აჩვენებს მანქანის მისამართებს; Linux-ზე - ip -4 addr. თუ IpAddress-ის მნიშვნელობა ამ გამოტანაში არ არის, ის არასწორია. მასთან დაკავშირებული მახე არის სახლის კომპიუტერი, რომლის LAN მისამართი reboot-ის შემდეგ იცვლება, რადგან როუტერი მას DHCP-ით გასცემს. თუ 192.168.1.40-ზე გამოიბი და მანქანა ახლა 192.168.1.52-ია, სერვერი არაფრისმომცემ მისამართზე უსმენს, როუტერი კი ცარიელ მისამართზე აგზავნის. გამოიყენე 0.0.0.0 კონფიგში და როუტერში კომპიუტერს DHCP reservation მიეცი, რომ forward ყოველთვის ერთსა და იმავე მანქანაზე მოხვდეს.

სერვერს Steam-თან დასარეგისტრირებლად public IPv4 მისამართიც სჭირდება. კავშირს, რომელსაც მხოლოდ IPv6 აქვს, ან რომლის IPv4 carrier-grade NAT-ის უკან არის გაზიარებული, შეუძლია სერვერი გაუშვას, მაგრამ ვერ შეძლებს მის სიაში ჩვენებას ან შეერთებების მიღებას. ლოგი დაწერს, რომ Steam-დან public მისამართი ვერ მიიღო, ან ქსელის ტესტი ყველა პორტზე ერთდროულად ჩავარდება. IPv6 და თამაშის სერვერები განმარტავს, რატომ ეყრდნობა Steam-ის თამაშები მაინც IPv4-ს.

LanOnly, hairpin NAT და სწორი ადგილიდან ტესტირება#

LanOnly, დაყენებული true-ზე, სერვერს საჯარო ინტერნეტიდან მთლიანად აშორებს. ის Steam-ის საჯარო სიაში არ რეგისტრირდება და შენი ქსელის გარეთ მყოფი მოთამაშეები ვერ უერთდებიან. ეს სწორი პარამეტრია LAN party-სთვის და არასწორი ყველაფრისთვის დანარჩენისთვის; და რადგან სერვერი ორივე შემთხვევაში წესიერად იწყება, ღირს, ეს როუტერის მენიუებში ძიებამდე შეამოწმო.

მეორე მახე სახლში საკუთარი ქსელიდან ტესტირებაა. მომხმარებლის უმეტეს როუტერს hairpin NAT (ანუ NAT loopback) არ აქვს: შენი LAN-ის კომპიუტერი, რომელიც საკუთარ public მისამართს უერთდება, უკან შიგნით არ მარშრუტდება. შედეგი არის სერვერი, რომელსაც ქალაქის მეორე ბოლოდან მეგობრები პრობლემის გარეშე უერთდებიან, მასპინძელი კი public IP-ით ვერ აღწევს. ეს სერვერის ბრალი არ არის. მასპინძელმა სერვერის კომპიუტერის LAN მისამართით უნდა შეუერთდეს, დანარჩენებმა - public მისამართით.

იგივე ეფექტი სერვერის საკუთარ თვითტესტსაც ამტვრევს. ის თავის public მისამართს ქსელის შიგნიდან ამოწმებს და hairpin მხარდაჭერის გარეშე ეს შემოწმება ჩავარდება სერვერზე, რომელიც გარედან სავსებით მისაწვდომია. SkipNetworkAccessibilityTest-ის true-ზე დაყენების ერთადერთი კარგი მიზეზი ესაა: შენ დაადასტურე შენი ქსელის გარეთ მყოფ მოთამაშესთან, რომ შეერთება მუშაობს, ტესტი კი მაინც სხვას ამბობს. ტესტის გამორთვა, რომელიც ბოლომდე არ გაგიგია, მხოლოდ შეცდომის შეტყობინებას მალავს, მოთამაშეები კი ისევ ვერ უერთდებიან.

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

სახლიდან ჰოსტინგი: forward-ები, firewall-ები და CGNAT#

თუ სერვერი სახლის კომპიუტერზე მუშაობს, მოთამაშეებსა და თამაშს შორის სამი ფენაა და სამივეს ერთი და იგივე სამი UDP პორტი სჭირდება.

1. როუტერი. გადაამისამართე UDP 8766, 27016 და 9700 სერვერის კომპიუტერის LAN მისამართზე. ზოგიერთ როუტერს წესზე დიაპაზონი უნდა; სამი ცალკე ერთპორტიანი წესი კარგია.
2. ოპერაციული სისტემის firewall. Windows-ზე, როცა SonsOfTheForestDS.exe პირველად იწყებს მოსმენას, Windows Defender Firewall გეკითხება, დაუშვას თუ არა. თუ ამ დიალოგს დახურავ, ან მხოლოდ „private networks“-ს მონიშნავ მაშინ, როცა შენი ქსელი public-ადაა მონიშნული, შემომავალი ტრაფიკი უხმოდ იკარგება.
3. თვით კავშირი. თუ პროვაიდერი carrier-grade NAT-ს იყენებს, ვერც ერთი forward ვერასოდეს იმუშავებს, რადგან შენს როუტერს public მისამართი არ უჭირავს.

Windows-ზე აშკარა შემომავალი წესი დიალოგის იმედზე ყოფნას სჯობს. administrator-ის ბრძანების ველიდან:

$ netsh advfirewall firewall add rule name="Sons of the Forest server" dir=in action=allow protocol=UDP localport=8766,27016,9700

Linux ჰოსტზე, სადაც სერვერი Wine-ის ან Proton-ის ქვეშ მუშაობს და firewall-ად ufw გაქვს:

$ sudo ufw allow 8766/udp$ sudo ufw allow 27016/udp$ sudo ufw allow 9700/udp

თუ სერვერი Docker-ში მუშაობს, თითოეული პორტი პროტოკოლითაც უნდა გამოქვეყნდეს, მაგალითად -p 9700:9700/udp. Docker ნაგულისხმევად TCP-ს აქვეყნებს და container, გაშვებული -p 9700:9700-ით, იმავე უჩინარი UDP-ის პრობლემას იძლევა, რასაც TCP-ზე დაყენებული როუტერის forward. მნიშვნელოვანი firewall-ის წესები და ufw-ის გზამკვლევი უფრო ფართო სურათს აღწერს.

CGNAT რომ აღმოაჩინო, შეადარე როუტერის სტატუსის გვერდზე ნაჩვენები WAN მისამართი იმას, რასაც „what is my IP“ ტიპის საიტი აჩვენებს. თუ ისინი განსხვავდება, ან როუტერის WAN მისამართი 100.64.0.0/10-შია, შენი კავშირი გაზიარებულია და შემომავალი forwarding ვერ იმუშავებს. გამოსავალია, პროვაიდერს სთხოვო public IPv4 მისამართი, რომელსაც ზოგი მოთხოვნით იძლევა და ზოგი ფულს ართმევს, ან სერვერი იქ გაუშვა, სადაც ასეთი აქვთ. NAT და CGNAT თამაშის ჰოსტებისთვის ვარიანტებს გადის, ხოლო port forwarding vs hosted სერვერები პატიოსანი შედარებაა: ამაზე სახლში ჭიდილი თუ დაქირავება.

hosted სერვერზე ამის უმეტესობა ქრება. RE:NODE-ზე Sons of the Forest-ის გეგმებს სამი პორტის გამოყოფა მოჰყვება და ისინი უკვე ღიაა ინტერნეტისთვის; მათ წინ არც როუტერია და არც Windows firewall. რაც შესამოწმებელია, ისაა, რომ dedicatedserver.cfg-ში სამი ნომერი ემთხვეოდეს Network ტაბზე ნაჩვენებ გამოყოფილ პორტებს, რადგან სახლის სერვერიდან გადმოტანილი კონფიგი სახლის პორტების ნომრებსაც თან მოიტანს.

გარედან შემოწმება: Steam საერთოდ ხედავს მას?#

თამაშის შიდა ბრაუზერი ნელა ახლდება და აგრესიულად ფილტრავს, ამიტომ თამაშში „სიაში არ არის“ ყოველთვის არ ნიშნავს „არ არის რეგისტრირებული“. Steam-ის public Web API კითხვას პირდაპირ პასუხობს. ჩასვი სერვერის public IPv4 მისამართი ამ URL-ში ნებისმიერ ბრაუზერში:

https://api.steampowered.com/ISteamApps/GetServersAtAddress/v1/?addr=203.0.113.25

ის აბრუნებს ამ მისამართიდან რეგისტრირებულ ყველა Steam თამაშის სერვერს იმ პორტებით, რომლებიც Steam-მა იცის. ცარიელი სია ნიშნავს, რომ სერვერი Steam-თან არ არის რეგისტრირებული: შეხედე LanOnly-ს, public IPv4-ის პრობლემას და სერვერის ლოგს. შედეგი, რომელშიც შენი სერვერი ჩანს, ნიშნავს, რომ Steam-ს აქვს, ხოლო მოთამაშეს, რომელსაც თამაშში მაინც არ ჩანს, ან ბრაუზერის ფილტრი აქვს დაყენებული, ან ქეშირებული სია, ან query პორტი დაბლოკილია Steam-სა და სერვერს შორის და ბრაუზერი მას ping-ს ვერ უგზავნის.

Steam-ის კლიენტის საკუთარი server browser მეორე აზრია. Steam-ში გახსენი View, შემდეგ Game Servers, გადადი Favourites-ზე და დაამატე სერვერი მისამართითა და query პორტით. თუ იქ სახელითა და ping-ით პასუხობს, query ტრაფიკი მას აღწევს. ეს სასარგებლოა თამაშის ბრაუზერის ქსელისგან გამოსაყოფად: თუ Steam-ის ბრაუზერი სერვერს ხედავს და თამაში - არა, პრობლემა თამაშის მხარესაა, ჩვეულებრივ ფილტრი ან ვერსიების სხვაობა.

ვერსიების შეუსაბამობა patch-ის შემდეგ#

კლიენტი და სერვერი ერთსა და იმავე build-ზე უნდა მუშაობდეს. Steam მოთამაშეების თამაშის ასლებს ავტომატურად ანახლებს, ჩვეულებრივ patch-ის გამოსვლის დღესვე. dedicated server ცალკე აპლიკაციაა (2465200) და მხოლოდ მაშინ ახლდება, როცა ვინმე მასზე SteamCMD-ს გაუშვებს. ამიტომ patch-ის მეორე დღეს სერვერი გუშინდელ build-ზეა და ყველა, ვინც განახლდა, უარყოფილია - ხშირად შეტყობინებით, რომელიც ვერსიებს არ ახსენებს, ან უბრალოდ შეწყვეტილი კავშირით.

გამოსწორება ისაა, რომ სერვერი განაახლო და გადატვირთო:

$ steamcmd +force_install_dir C:\sotf-server +login anonymous \    +app_update 2465200 validate +quit

გააკეთე ეს, სანამ ვინმე შეერთებას შეეცდება, და ჯერ save-ის ასლი აიღე, რადგან patch-ის დღე save-ის ფორმატის ცვლილების ყველაზე სავარაუდო დღეცაა. SteamCMD-ის განმარტება validate-სა და ინსტალაციებს ეხება, ხოლო SteamCMD-ის შეცდომები და გამოსწორებები - რა უნდა გააკეთო, როცა თვით განახლება ვარდება.

საპირისპირო შეუსაბამობაც ხდება. მოთამაშე, რომელმაც Steam-ის თვისებებში თამაშის beta branch-ზე გადაინაცვლა, სხვა build-ზეა, ვიდრე public branch-ზე მომუშავე სერვერი. თუ ყველა სხვა უკვე უერთდება და მხოლოდ ერთი ვერა, სთხოვე, Steam-ში თამაშის Betas ტაბი შეამოწმოს და ფაილები verify-ოს. პირიქით - სერვერი, რომელიც ძველ build-ზეა მიბმული, სანამ მოთამაშეები წინ მიდიან - სწორედ ისე ხდება, რომ სკრიპტს ძველი -beta არგუმენტით გაშვებული სერვერი ჩუმად აღარავის იღებს. SteamCMD-ის app id-ები და beta branch-ები ხსნის, როგორ ხდება ეს.

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

პაროლი, რომელიც არ მუშაობს#

JSON-ში Password უბრალო სტრიქონია, 40 სიმბოლომდე. ცარიელი ნიშნავს პაროლის გარეშე. სამი რამ ტყდება:

• რეგისტრი და ინტერვალები. შედარება ზუსტია. ჩატიდან ჩასმული ბოლო ინტერვალი პაროლის ნაწილია.
• JSON-ის escaping. პაროლი, რომელშიც ორმაგი ბრჭყალი ან backslash არის, უნდა იყოს გამოსახული როგორც \" ან \\, წინააღმდეგ შემთხვევაში ფაილი აღარ იკითხება. უფრო ადვილია პაროლი ამ ორის გარეშე აირჩიო.
• ბრძანების ხაზით გადაფარვა. ყველა კონფიგის გასაღები ბრძანების ხაზზე -dedicatedserver. პრეფიქსით შეიძლება დაყენდეს და ბრძანების ხაზი იმარჯვებს. თუ პანელი ან გაშვების სკრიპტი -dedicatedserver.Password-ს გადასცემს, ფაილის შეცვლა არაფერს აკეთებს. სანამ დაასკვნი, რომ სერვერი გაიგნორებს, შეამოწმე გაშვების ბრძანება.

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

სერვერის ლოგის კითხვა#

კონსოლის გამოტანა ისაა, სადაც ყველა ეს პრობლემა თავს აცხადებს და ღირს, ერთხელ ზემოდან ქვემოთ წაიკითხო სერვერზე, რომელიც მუშაობს, რომ იცოდე, როგორ გამოიყურება ნორმა. დიაგნოსტიკისას სერვერი გაუშვი -verboseLogging-ით; დამატებითი დეტალი განსხვავებაა ცოდნასა და ვარაუდს შორის. LogFilesEnabled დააყენე true-ზე, თუ გამოტანას ფაილებშიც გინდა user data საქაღალდეში, TimestampLogFilenames კი თითოეულ გაშვებას თავის ფაილში ინახავს.

რას უნდა დააკვირდე, თანმიმდევრობით:

1. კონფიგურაციის წაკითხვა. parse-ის შეცდომა ნიშნავს დაზიანებულ JSON-ს - ბოლო მძიმე, ჭკვიანი ბრჭყალი, პაროლში გაუექსეიპებელი სიმბოლო - და სერვერი იქვე ჩერდება. გაასწორე ფაილი და თავიდან გაუშვი.
2. პორტების გახსნა. „in use“ შეტყობინება ნიშნავს, რომ ნომერი სხვა პროცესს უჭირავს. გააჩერე ის, ან ეს სერვერი თავისუფალ პორტებზე გადაიტანე.
3. Steam-იდან public მისამართი. აქ ჩავარდნა ნიშნავს, რომ public IPv4 არ არის: მხოლოდ IPv6 კავშირი, CGNAT, ან Steam-ს ცუდი წუთები აქვს, რა დროსაც რამდენიმე წუთში გადატვირთვა ერთხელ ცდად ღირს.
4. ქსელის ხელმისაწვდომობის ტესტი. თითოეული პორტი მისაწვდომად ან არამისაწვდომად ფიქსირდება. ერთი დახურული პორტი შენს პრობლემას ასახელებს. სამივე დახურული ჩვეულებრივ ნიშნავს, რომ forward არასწორ მანქანაზე მიდის, firewall ყველაფერს აგდებს, ან hairpin NAT თვით ტესტს არღვევს.
5. მოთამაშეების შეერთება. მიმდინარე შეერთებისას ლოგი ჩვენებს, როგორ ჩამოდის კავშირი. თუ game პორტის კავშირი ჩნდება და მას არაფერი მოჰყვება, BlobSync გადაცემა არ აღწევს.

RE:NODE-ზე კონსოლი სერვერის ცოცხალ გამოტანას ფილტრის გარეშე აჩვენებს, ამიტომ ქსელის ტესტი და ყოველი შეერთება ხდება ისე, როგორც ხდება, ხოლო Startup ტაბზეა ბრძანების ხაზის ყველა გადაფარვა. ეს პირველი ადგილია, საითაც უნდა შეიხედო, როცა ფაილის მნიშვნელობა იგნორირებულად გეჩვენება.

კიდევ ერთი რამ, რასაც ლოგი ავლენს: განმეორებითი გადატვირთვები. სერვერი, რომელიც ჩატვირთვაზე ვარდება, შესაძლოა დაზიანებული save-ის გამო, თავიდან იწყება, ცოტა ხნით „ონლაინ“ ჩანს და კვლავ ქრება. მოთამაშეებისთვის ეს ქსელის პრობლემისგან არ განირჩევა. თუ კონსოლში uptime სულ ნულდება, პრობლემა სერვერშია და არა პორტებში - რატომ გადაიტვირთება შენი თამაშის სერვერი განუწყვეტლივ საწყისი ადგილია.

FAQ#

რატომ ჩანს ჩემი სერვერი მეგობრებს, მაგრამ მე - არა?

შენ სერვერის იმავე ქსელში ხარ და შენი როუტერი ტრაფიკს საკუთარ public მისამართზე უკან შიგნით არ აბრუნებს. შეუერთდი სერვერის კომპიუტერის LAN მისამართით. შენი ქსელის გარეთ ყველა public მისამართს ჩვეულებრივად იყენებს.

რომელი პორტები უნდა გადავამისამართო Sons of the Forest-ისთვის?

UDP 8766 თამაშისთვის, UDP 27016 Steam query-სთვის და UDP 9700 BlobSync-ისთვის, თუ dedicatedserver.cfg-ში არ შეგიცვლია. სამივე UDP უნდა იყოს. მესამის გამოტოვება ჩატვირთვის დაუსრულებელ ეკრანს იწვევს.

ჩავწერო თუ არა ჩემი public IP IpAddress-ში?

არა. IpAddress არის ლოკალური ინტერფეისი, რომელზეც უსმენს და 0.0.0.0 ყველა მათგანს ნიშნავს. კონკრეტული მისამართი მხოლოდ მაშინ დააყენე, როცა მანქანას რამდენიმე აქვს და სერვერი ერთზე გინდა, და მაშინაც გამოიყენე მისამართი, რომელიც თვით მანქანას უჭირავს.

თამაშის განახლების მერე მოთამაშეები მენიუში გადმოაგდო. რა მოხდა?

მათი თამაში განახლდა, სერვერი - არა. გააჩერე სერვერი, SteamCMD-ით გაუშვი app_update 2465200 და თავიდან ჩართე. ჯერ save-ის backup აიღე, რადგან patch-ის დღეებში ფორმატები იცვლება.

უსაფრთხოა SkipNetworkAccessibilityTest-ის ჩართვა?

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

შეიძლება ორი სერვერის გაშვება ერთ მანქანაზე?

კი, თუ თითოეულს თავისი სამი პორტი და თავისი user data საქაღალდე აქვს -userdatapath-ით. ორი სერვერი, რომელიც ერთ რომელიმე პორტს იზიარებს - BlobSync ადვილად დასავიწყებელია - შეერთებებს გააფუჭებს იმ სერვერზე, რომელიც მეორე გაიშვა.