Limiter le nombre de comptes actifs par IP

Bonjour a tous,

Mon serveur autorise au maximum une dual box. Cependant actuellement aucun system de check n'est actif. Seul l'action d'un GM peut faire régner l'ordre a ce niveau là.

Je me suis penché sur la question d'un script automatique(en algo encore..), qui irait vérifier le nombre de compte par IP, et qui kickerait le dernier compte connecté en cas de triple box.

Pour l'action de "kick" j'ai vu que la DB michelle DropCalc proposait cette action. En regardant de plus près ca se base sur une action via le telnet, cependant en testant je m'apercoit que cette action ne fait rien

Voici le code :

Code:

if ($kick)
      {
         // Look up the user and see if they are on line.
         $sql = "select online from characters where char_name = '$touser'";
         $result_i = mysql_query($sql,$con);
         $is_online = mysql_result($result_i,0,"online");
         if (!$is_online)
         {   echo "<p class=\\"popup\\">$touser is not currently on-line</p>";   }
         else
         {
            $usetelnet = fsockopen($telnet_host, $telnet_port, $errno, $errstr, $telnet_timeout);
            if($usetelnet)
            {
               $give_string = 'kick ' . $touser ;
               $give_string2 = 'msg ' . $touser . ' ADMIN HAS KICKED YOUR CHARACTER.';
               $give_string3 = 'msg ' . $touser . ' PLEASE TALK WITH YOUR ADMIN TEAM.';
               fputs($usetelnet, $telnet_password);
               fputs($usetelnet, "\\r\\n");
               fputs($usetelnet, $give_string2);
               fputs($usetelnet, "\\r\\n");
               fputs($usetelnet, $give_string3);
               fputs($usetelnet, "\\r\\n");
               fputs($usetelnet, $give_string);
               fputs($usetelnet, "\\r\\n");
               fputs($usetelnet, "exit\\r\\n");
               fclose($usetelnet);
               echo "<p class=\\"popup\\">Kick command sent</p>";
            }
            else
            {   echo "<p class=\\"popup\\">Couldn't connect to telnet</p>";   }
         }

      }

Je pense que ce code est valable pour du L2j et non L2jFree comme mon serveur.

Mon port telnet est bien ouvert en local, pas de soucis a ce niveau la.
Je pense que le problème vient de ces lignes plus précisement:

Code:

$give_string = 'kick ' . $touser ;
               $give_string2 = 'msg ' . $touser . ' ADMIN HAS KICKED YOUR CHARACTER.';
               $give_string3 = 'msg ' . $touser . ' PLEASE TALK WITH YOUR ADMIN TEAM.';

Si quelqu'un a une idée, ca m'arrangerait énormément

Ca mon cher, ça passe par le MMOCore qui gère toutes les connections UDP.

Tu ne fera jamais aucun contrôle d'IP par SQL à moins que tu ne tienne pas à dépasser 20 joueurs.

Pour ma part, je serais plus vicieux, je passerais par l'adresse MAC qui différencie les PC entre eux et ne change jamais (sauf si le mec à une montagne de cartes réseau derrière lui..

Il n'existe aucune commande de 'kick' externe par le telnet??

Il dois en exister une surement mais comment vas tu identifier si deux personnages utilisent la même IP ? Là est tout le problème ! Si tu passe par le SQL, tu fais confiance à ta machine ! Car ce n'est pas le genre de chose qui va laisser ses performances intacts.

Je vais essayer plusieurs techniques , je voulais commencer par le SQL avant d'attaquer le system ( ex: regles dynamiques de firewall )

Problèmes de logique.

Admettons que dualbox = 2 comptes lancés sur le même PC.

Si 2 joueurs bien différents jouent sur 2 PC bien différents reliés au même modem-routeur, ils auront la même IP, ne feront pas de dualbox. Le premier des deux qui lancera une dualbox se fera automatiquement kicker parce que ça fera trois comptes pour la même IP. Objectif raté.

Encore pire avec l'adresse MAC. La dernière adresse MAC connue du serveur est celle du routeur le plus proche du serveur (entendez "le dernier utilisé" par les paquets). Si par malheurs ton serveur est hébergé à 2 pas d'un DSLAM A, et que des joueurs (beaucoups de joueurs) se connectent via un DSLAM B, puis passent par un routeur C, pour se connecter au serveur à travers le DSLAM A, ben tu ne pourras autoriser QUE 2 joueurs de CE DSLAM en même temps. Objectif encore raté.

Et peut-être même un seul, puisque ton serveur aura une adresse MAC "distante" identique à celle des joueurs... Objectif re-re-raté.

Une solution pour filtrer par adresse MAC serait de la demander au login, donc de faire transiter cette adresse du client au serveur. Objectif presque atteint.

Respawner, Dieu du monde des réseaux, y'a moyen d'ajouter cette identification envoyée du PC (et pas du routeur) client vers le serveur au moment du login ?

WeeD, si oui, tu as ta solution; si non, tu ne pourras jamais filtrer ça.

Théoriquement c'est possible tout est possible on peut mettre ce que l'on veut dans un paquet en réseau. Il suffit d'écrire l'adresse MAC (source première) en tant que donner dans un autre paquet. Mais je ne vois pas comment faire sans modifier le client ou sans ajouter un outil externe. Je donne une idée. Il faudrait coder un outils externe très simple et modifier le système d'authentification. En gros l'outils envoie au login les identifiants et mot de passe du client avec l'adresse MAC de ce dernier. Niveau loginserver quand on reçoit le premier paquet on vérifie que le login et mot de passe sont correctes si oui on écrit dans la base de données l'adresse MAC et on envoie une réponse sinon on envoie une réponse pour dire qu'il y a un soucis niveau identification. Si tout est ok, l'outil lance le client L2 le mec n'a plus qu'à se logger et joue. Quand il se déconnecte on vide la case correspondant à l'adresse MAC. Si un type essaie de se connecter en dualbox il va lancer le client malheureusement le champ MAC de la BDD est déjà remplis conclusion on jette le nouveau client.

Code:

Algo client
   Envoi paquet avec login, mot de passe et @MAC
   Attente réponse du serveur
   Si réponse == OK
      Lancement du client
   Sinon
      Message d'erreur
   Fin si
Fin algo

Algo login
   Faire toujours
      Attente paquet
      Si le champ MAC est vide
         On entre la valeur de la MAC
         On autorise la connexion
      Sinon
         On envoie une réponse pour erreur
      Fin si
   Fin faire
Fin algo

Suffit d'adapter un système comme ça.

Respawner à trouvé par ou je voulais passer, mais j'y vais encore plus radical. Parce que là, n'importe qui pourra quand même passer par le L2.exe une deuxième fois, l'IP sera le même, l'adresse MAC déjà existante. Bref, ça se casse facilement.

Je vous laisse poireauter tout ça ! Je préfère rester muet encore un peu.

il reste une solution simple sans modifier le client. il suiffi de faire un script Php d'inscription. il fera la meme chose sité en haut.

// on définis le nombre de fois qu'on veux voir l'adress mac dans la table

$mac = 2 ou 3

lors de l'injection il verifie l'adress mac s'il existe ou pas, si oui combien de fois.
//s'il y a qu'un on injecte
echo' vous ete bien inscrit bienvenue sur.............
//s'il y a n'a plus de 2
echo' vous ete deja inscrit... contacter un adminitrateur

ce n'est qu'une idée......

Bah c'est du potasser en 5 minutes chrono.
C'est pas très beau de garder des traces de la première adresse MAC mais c'est la seule adresse unique (théorie ... ça se change). Mais si le mec vient à changer sa MAC bail bail ses autres paquets (en remontant la pile réseau [modèle OSI les mecs ] le paquet va être jeté).
Il faut absolument n'autorisé la connexion que si et seulement si le champ MAC du compte est vide s'il contient déjà une adresse il faut jeter le nouveau client tentant de se connecter.

Bon aller je balance !

Le truc, c'est d'utiliser le login server, se connecter dessus, avant même d'avoir ouvert le jeu, dans un programme externe. Ensuite, on permet un état de session intermédiaire et où le joueur as le temps de se connecter au jeu, si la session expire, l'adresse mac est libéré, sinon elle est bloquée.
Bien sur, il faut aussi rajouter un certain paquet

Là les choses se corsent ! J'ai remarqué à la dernière minute que malgrès le fait que L2 fonctionne avec des packets, il les envoie via le protocole TCP ! Beaucoup plus difficile à mettre en place car le MMOCore est prévu pour un serveur, pas un client. Donc difficulté point de vue client.

De plus, le port de sortie n'est pas forcément le même (c'est ce qui fait que l'on peux jouer en dual box) d'une connexion à l'autre ... Là c'est la catastrophe, j'ai toujours pas encore trouvé comment éviter ce problème, et on peux tomber sur un deadlock entre deux joueurs, dont un le fait un dual box, qui se connectent en même temps à partir du même réseau. Certes cas extrême (au final il y aura autant de fenêtres de jeu que d'ordinateurs tout au plus ...)
Cependant, c'est tout aussi génant pour le serveur, on identifie un client par son IP et port ... Si le port n'est pas le même, adieu la session qui attends !



Pour faire simple, c'est un bordel sans nom qui mène à remplacer le MMOCore. J'ai bossé pendant 1 semaine dessus déjà et je commence à peine à me lancer dans la réécriture (car il faut bien voir toutes les possibilités avec avantages et inconvénients)


PS : A la rigueur je lancerais bien un débat sur "UPD ou TCP ?". Parce qu'un système de packets en TCP ... C'est pas des plus simples à faire et rapide à executer !

Grimly a écrit:

PS : A la rigueur je lancerais bien un débat sur "UPD ou TCP ?". Parce qu'un système de packets en TCP ... C'est pas des plus simples à faire et rapide à executer !

Certes mais TCP est beaucoup plus sûr que UDP. En UDP si le client ou le serveur rate le paquet c'est mort pour établir la connexion va falloir que tu codes un truc pour rectifier ça... Inutile c'est déjà fait avec TCP. Pas la peine de réinventer la roue. Tu veux une connexion sûre et sécurisée choisis TCP bien que ce ne soit pas fiable à 100% (un simple changement de bit ou une perte de paquet peut vite arriver).