გლობალური ბანების სიები თამაშის სერვერებისთვის

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

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

ორი სხვადასხვა პრობლემა ერთი სახელით#

"გლობალურ ბანებს" ორ სრულიად განსხვავებულ მოწყობას უწოდებენ, და მათი გამიჯვნა გამოგადგება.

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

არსებობს მესამე სახეც, რომელსაც საერთოდ არ აკონტროლებ: ანტიჩიტის მწარმოებლისა და დეველოპერის გლობალური ბანები, რომლებიც ვრცელდება თამაშის ყველა სერვერზე. ისინი განხილულია BattlEye და Easy Anti-Cheat სერვერებზე-ში.

როგორ მუშაობს საერთო ბანების სისტემა#

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

არჩევისას სამ თვისებას აქვს მნიშვნელობა:

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

მთელ ქსელზე თუ თითო სერვერზე

ყველა ბანი არ უნდა მისდევდეს მოთამაშეს ყველგან. მოთამაშე, რომელიც შენს creative სერვერზე მშენებლობის წესებს გამუდმებით არღვევს, PvP სერვერზე შეიძლება სრულიად სასურველი იყოს, ხოლო deathmatch სერვერზე spawn-camping-ისთვის ბანი არაფერს ამბობს იმაზე, როგორ იქცევა ის თანამშრომლობით კამპანიაში. ქვემოთ მოცემული ინსტრუმენტებიდან რამდენიმეს შეუძლია ბანი ერთ სერვერზე ან სერვერების ჯგუფზე შეზღუდოს და არა მთელ ქსელზე; სადაც არ შეუძლია, შეინახე ცალკე ლოკალური ბანების სია წესებისთვის, რომლებსაც აზრი მხოლოდ ერთ სერვერზე აქვს.

გონივრული დაყოფა ქსელების უმეტესობისთვის:

• მთელ ქსელზე: ჩიტინგი, ბანის გვერდის ავლა, მუქარა, doxxing, სიძულვილის ენა, ყველაფერი, რის გამოც ვინმეს შენი საზოგადოების Discord-იდანაც მოაშორებდი.
• თითო სერვერზე: წესები, რომლებიც თამაშის რეჟიმს, რუკას ან სერვერის კულტურას უკავშირდება.

ჩაუწერე ეს დაყოფა სტაფს. მის გარეშე ნაგულისხმევი ხდება "დაბლოკე ყველგან", და წვრილმანი დარღვევა ერთ სერვერზე მუდმივ მოთამაშეს ყველაფრიდან კეტავს, რასაც უშვებ.

Source თამაშები: SourceBans++#

Source თამაშებზე, სადაც SourceMod მუშაობს - Team Fortress 2, Garry's Mod, Left 4 Dead 2, Counter-Strike: Source და სხვები - სტანდარტი SourceBans++-ია. ეს ორიგინალი SourceBans-ის მხარდაჭერილი გაგრძელებაა და სამი ნაწილი აქვს: PHP ვებ-პანელი, მონაცემთა ბაზა და SourceMod-ის პლაგინების ნაკრები. მთავარი პლაგინი ბანებს ამუშავებს; თანმხლები პლაგინები კომუნიკაციის ბლოკებს (gag-ები და mute-ები) და ადმინების სინქრონიზაციას ამუშავებს, ასევე არსებობს არასავალდებულო პლაგინი, რომელიც მონიშნავს მიერთებულ მოთამაშეებს, რომელთა IP დაბლოკილ ანგარიშს ემთხვევა.

თითოეული თამაშის სერვერი მონაცემთა ბაზას SourceMod-ის databases.cfg-ით უერთდება:

"Databases"{	"driver_default"	"mysql"	"sourcebans"	{		"driver"	"default"		"host"		"db-host-from-your-panel"		"database"	"sourcebans"		"user"		"generated-user"		"pass"		"generated-password"		"port"		"3306"	}}

თითოეულ სერვერს საკუთარი სერვერის ID-იც სჭირდება, მითითებული პლაგინის კონფიგ-ფაილში configs/sourcebans/-ის ქვეშ, რომელიც ვებ-პანელში დამატებულ სერვერს ემთხვევა. ამის შემდეგ sm_ban ნებისმიერ სერვერზე საერთო ბაზაში წერს, და ბანი ყველა სერვერზე მოქმედებს.

SourceBans++ ვებ-პანელისა და პლაგინებისთვის MySQL-თან თავსებად მონაცემთა ბაზას ელოდება, ამიტომ დაწყებამდე ეს მოთხოვნა შენს ბაზასთან გადაამოწმე.

SourceMod-ს საკუთარი, მონაცემთა ბაზაზე დაფუძნებული ადმინების სისტემაც აქვს, რაც უფრო მარტივი ვარიანტია, თუ გაზიარება ბანების ნაცვლად ადმინების გინდა: admin-sql-threaded პლაგინი ადმინებსა და ჯგუფებს კითხულობს ბაზიდან, რომელიც databases.cfg-ში "admins"-ად არის განსაზღვრული, ასე რომ სტაფის წევრის დაწინაურება ან მოშორება მთელი ქსელისთვის ერთი ცვლილებაა. SourceMod-ის ადმინ-ფლაგები და იმუნიტეტი ხსნის უფლებების მოდელს, რომელსაც ეს ადმინები იყენებს.

Minecraft: ერთი ბანის პლაგინი, ერთი მონაცემთა ბაზა#

Minecraft-ის ქსელს, როგორც წესი, რამდენიმე backend სერვერის წინ პროქსი აქვს (Velocity ან BungeeCord). ბანის პლაგინები ამას ორიდან ერთი გზით ამუშავებს: დაყენებული პროქსიზე, სადაც ბანი მოთამაშეს რომელიმე backend-მდე მისვლამდე აჩერებს; ან დაყენებული ყველა backend-ზე საერთო ბაზით. პროქსიზე დაყენება უფრო მარტივია და მისი გვერდის ავლა უფრო ძნელია, თუ backend-ებთან პირდაპირ დაკავშირება შეუძლებელია.

თითოეული დოკუმენტაციაში აღნიშნავს, რომელ ბაზის ძრავებს უჭერს მხარს; წაიკითხე ეს ბაზის შექმნამდე, რადგან ყველა პლაგინი ყველა ძრავს არ უჭერს მხარს. სამივე გაძლევს დროებით ბანებს ვადებით, mute-ებს, გაფრთხილებებს, მიზეზებს და ისტორიას, რაც vanilla banned-players.json-იდან გადასვლის მთავარი მიზეზია თუნდაც ერთ სერვერზე. უმეტესობას შეუძლია vanilla ფაილებიდან და ერთმანეთისგან იმპორტი, ასე რომ დაიწყე vanilla სიით და გადაიტანე.

ბანის პლაგინი იქ გაუშვი, სადაც შესვლა ხდება. ქსელზე ეს პროქსია, პლუს ბაზა, რომლის წაკითხვაც backend-ებსაც შეუძლიათ, თუ backend-ის პლაგინს ბანების ინფორმაცია სჭირდება. Minecraft-ის Velocity პროქსის ქსელი ქსელის განლაგებას ხსნის, ხოლო MySQL Minecraft-ის პლაგინებისთვის - პლაგინების ბაზასთან მიერთებას.

Rust, DayZ, Arma და სხვა RCON-ით მართული თამაშები#

ბევრი გადარჩენისა და სამხედრო თამაში თამაშის შიგნით პლაგინების ფრეიმვორკის ნაცვლად RCON-ით იმართება, და აქ ბანების გაზიარების გავრცელებული ინსტრუმენტი BattleMetrics-ია. მისი RCON სერვისი შენს სერვერებს უერთდება, მოთამაშეებსა და მათ იდენტიფიკატორებს იწერს და ბანებს ინახავს ბანების სიებში, რომლებსაც ერთ ან რამდენიმე სერვერზე იყენებ. ორგანიზაციას შეუძლია ბანების სია სხვა ორგანიზაციას გაუზიაროს ან სხვისი გამოიწეროს, და ასე ცვლის ბანებს Rust-ისა და DayZ-ის ბევრი საზოგადოება. სიაში არსებულ ბანებს სერვისი RCON-ით აღასრულებს, როცა შესაბამისი მოთამაშე შემოდის.

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

Rust-ზე პლაგინების ფრეიმვორკები ბაზაზე დაფუძნებულ ბანის პლაგინებსაც გთავაზობს, თუ მონაცემების საკუთარ ხელში შენახვა გირჩევნია. BattlEye-იან თამაშებზე ლოკალური bans.txt თითო სერვერზეა, ასე რომ გაზიარება ნიშნავს ინსტრუმენტს, რომელიც იმავე ბანებს თითოეულში წერს.

ზოგიერთ თამაშს URL-ზე დაფუძნებული სია აქვს ჩაშენებული. Palworld-ის პარამეტრები შეიცავს BanListURL-ს, სიას, რომელსაც სერვერი HTTP-ით იღებს; ნაგულისხმევად ის დეველოპერის სიაზე მიუთითებს. შეცვლამდე შეამოწმე, რა არის შენი ვერსიის ნაგულისხმევი მნიშვნელობა, და გაითვალისწინე, რომ საკუთარ ფაილზე მიმართვა ჩაანაცვლებს იმას, რასაც ნაგულისხმევი სია გაძლევდა.

გაზიარება სხვა საზოგადოებებთან#

სხვა სერვერის მფლობელებთან ბანების გაცვლა აშკარა კოლექტიურ თავდაცვად ჟღერს. პრაქტიკაში ის პროგნოზირებადი გზებით მარცხდება, და საზოგადოებები, რომლებიც ამას წარმატებით აკეთებენ, წესებზე პირველ რიგში თანხმდებიან.

წარუმატებლობის სახეები:

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

წესები, რომლებიც ამას ამუშავებს:

1. გააზიარე მხოლოდ ჩიტინგის ბანები. წესების დარღვევა, რომელიც სერვერის საკუთარ წესებზეა დამოკიდებული, ლოკალური რჩება.
2. მოითხოვე მტკიცებულება ყოველ გაზიარებულ ბანთან, შენახული იქ, სადაც სხვა მხარეებს მისი განხილვა შეუძლიათ: demo, ჩანაწერი, ლოგის ამონარიდი.
3. შეთანხმდით გასაჩივრების გზაზე, ჩვეულებრივ იმ საზოგადოებასთან, რომელმაც ბანი გასცა, და იმ ვალდებულებით, რომ ბანები, რომელთა დასაბუთებაც შეუძლებელია, მოიხსნება.
4. გამოიწერე მხოლოდ კითხვის რეჟიმში, სადაც შეგიძლია, და იმპორტირებული ბანები აღსრულებამდე გადახედე, თუ ინსტრუმენტი ამის საშუალებას იძლევა.
5. შეინარჩუნე გადაწყვეტის უფლება. უნდა შეგეძლოს მოთამაშეს შენს სერვერებზე ბანი მოუხსნა, საერთო სიის მიუხედავად.
6. ჯგუფი პატარა შეინახე. სამი საზოგადოება, რომელთა მფლობელებიც ერთმანეთს იცნობენ, ბანებს კარგად იზიარებს. ოცდაათი უცნობი - არა.

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

კონფიდენციალურობა და სამართლებრივი მხარე#

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

პრაქტიკული მინიმუმი:

• გააზიარე მინიმუმი, რაც გჭირდება. ანგარიშის ID და კატეგორია ("ჩიტინგი, დადასტურებული demo-თი"), როგორც წესი, საკმარისია. ჩატის ლოგებს, ნამდვილ სახელებსა და IP მისამართებს შენი სერვერების დატოვება იშვიათად სჭირდება.
• აღნიშნე შენი სერვერის წესებში ან კონფიდენციალურობის შეტყობინებაში, რომ ჩიტინგის ბანები შეიძლება პარტნიორ საზოგადოებებს გაუზიარდეს.
• მოაშორე ის, რასაც მნიშვნელობა აღარ აქვს. ძველი დროებითი ბანები და მოხსნილი ბანები განუსაზღვრელი ვადით გაზიარებას არ საჭიროებს.
• იყავი ზუსტი. ვინმეს ჩიტერად გამოცხადება, როცა ის ასეთი არ იყო, სულ სხვა სახის პრობლემაა, ვიდრე არასწორი ლოკალური ბანი.

თამაშის სერვერის კონფიდენციალურობა და მოთამაშეების მონაცემები საფუძვლებს უფრო სიღრმისეულად ხსნის.

მონაცემთა ბაზის ჰოსტინგი#

ბანების ბაზა ხელმისაწვდომი უნდა იყოს ყველა სერვერიდან, რომელიც მას ამოწმებს, საიმედო უნდა იყოს და backup უნდა ჰქონდეს. რამდენიმე ვარიანტი:

• მონაცემთა ბაზის სლოტი თამაშის გეგმაზე. RE:NODE-ის ყველა თამაშის გეგმა შეიცავს ერთ ბაზის სლოტს, რომელიც პანელში იქმნება გენერირებული ჰოსტით, მომხმარებლითა და პაროლით, და ღილაკით "Open in phpMyAdmin" სწრაფი დათვალიერებისთვის. პატარა ქსელისთვის ეს ხშირად ყველაფერია, რაც გჭირდება, თუ პლაგინი ამ ძრავს უჭერს მხარს.
• გამოყოფილი ბაზის სერვერი. RE:NODE-ის ბაზების ხაზებია PostgreSQL და MongoDB, რაც ერგება ბანის პლაგინებს, რომლებიც PostgreSQL-ს უჭერს მხარს. PostgreSQL-ის დისტანციური კავშირები ხსნის მასთან თამაშის სერვერიდან მიერთებას.
• მესამე მხარის სერვისი, როგორიცაა BattleMetrics, რომელიც მონაცემებს შენ ნაცვლად ინახავს.

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

FAQ#

მჭირდება გლობალური ბანების სისტემა ორი სერვერისთვის?

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

შემიძლია დიდი საჯარო ჩიტერების სია გამოვიწერო?

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

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

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

საერთო ბანები IP მისამართებს უნდა შეიცავდეს?

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

როგორ მოვექცე გასაჩივრებას ბანზე, რომელიც სხვა საზოგადოებამ გასცა?

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