Radius Alternative pour les petits réseaux

Il est connu que l'autorisation des abonnés utilisant le protocole RADIUS dans le réseau de l'opérateur offre de nombreuses opportunités - ce sont les tarifs prenant en compte le trafic, la possibilité d'organiser l'autorisation lors de l'accès au réseau, Hotspot dans les réseaux Wi-Fi et un grand nombre d'autres choses qui sont difficiles à mettre en œuvre sans RADIUS.

Souvent, les opérateurs utilisent RADIUS uniquement parce qu'ils ne connaissent tout simplement pas d'autres méthodes d'autorisation ou ne risquent pas d'utiliser autre chose que le protocole commun. Dans de tels cas, tous les avantages de RADIUS sont vains en raison des méthodes complexes de réservation du serveur ou de leur absence. Une déconnexion inattendue de la facturation entraîne la déconnexion d'Internet des abonnés lors du bon fonctionnement des équipements réseau.

Par conséquent, je voudrais parler de la façon dont l'opérateur de télécommunications peut éviter l'autorisation via le protocole RADIUS sur les routeurs avec le système d'exploitation RouterOS (MikroTik). Nous utiliserons LanBilling 2.0 comme système de facturation, où la prise en charge des événements d'activation, de désactivation, de modification, de création et de suppression d'abonnés est mise en œuvre. Tout système avec un mécanisme d'événement similaire convient à ce rôle avec des améliorations.

L'interaction avec RouterOS se produit via l'API. Tout d'abord, vous devez créer un utilisateur dédié sur le routeur, qui effectuera le contrôle à distance.

Les détails d'accès seront les suivants:
Connexion: api
Mot de passe: api
Accès uniquement depuis le serveur de facturation: 192.0.2.2


L'étape suivante consiste à configurer le pare-feu, qui effectuera une partie importante du travail de blocage des abonnés et de transfert. Pour cela, il est nécessaire de permettre à tous les abonnés d'utiliser les ressources sélectionnées (serveur DNS externe, site Web de l'entreprise).

# Accès complet aux ressources sélectionnées
/ ip firewall filter add chain = forward \
dst-address-list = destinations-autorisées \
out-interface = ether-wan
En outre, nous utilisons des destinations autorisées de liste d'adresses. Si nécessaire, des adresses y seront ajoutées et les règles du pare-feu resteront les mêmes.
Ensuite, vous devez autoriser les abonnés à visiter les ressources pour payer les services. Le mécanisme décrit ci-dessous permettra aux abonnés d'accéder à toutes les ressources nécessaires au paiement.
# Blocage des ressources populaires inutiles pour le paiement
/ ip firewall layer7-protocol add name = réseaux-sociaux \
regexp = vk.com | mail.ru | ok.ru
# Nous sautons les abonnés en cours de paiement sur https-resources
/ ip firewall filter add chain = forward \
dst-port = 443 \
layer7-protocol =! réseaux-sociaux \
out-interface = ether-wan \
protocole = tcp \
src-address-list = liste des payeurs
Ensuite, nous bloquons l'accès à Internet pour ceux qui n'ont pas payé le service. Au moment du blocage, la facturation ajoute l'IP de l'abonné à la liste d'adresses bloquée.
# Blocage des défaillants
/ filtre pare-feu ip ajouter une action = rejeter la chaîne = transmettre \
out-interface = ether-wan \
rejette-avec = icmp-admin-prohibé \
src-address-list = bloqué

Ensuite, configurez NAT. Cela est nécessaire pour rediriger les abonnés vers une page avec une notification sur les adresses de blocage et de diffusion des abonnés pour accéder à Internet.

# Nous diffusons toutes les adresses grises
/ ip firewall nat add action = même chaîne = srcnat \
out-interface = ether-wan same-not-by-dst = yes \
src-address-list = nat-all-abonents \
adresses = 203.0.113.0 / 26
# Ne redirigez pas vers la mendicité de ceux qui sont en train de payer
/ ip firewall nat add action = accept chain = dstnat \
src-address-list = liste des payeurs
# Transmettre au mendiant (192.0.2.3) tous les autres
# non-payeurs, sans oublier les ressources sélectionnées
/ ip firewall nat add action = dst-nat chain = dstnat \
dst-address-list =! destinations-autorisées \
protocol = tcp src-address-list = bloqué \
to-addresses = 192.0.2.3 to-ports = 80

Les règles énumérées ci-dessus dans la chaîne de transfert sont suffisantes pour fournir un accès Internet. Pour limiter l'accès au routeur et fournir une sécurité supplémentaire, vous pouvez ajouter plusieurs règles à la chaîne d'entrée

Après ces manipulations, le routeur peut exécuter les fonctions de base d'accès aux abonnés du réseau sans l'aide de RADIUS. La vitesse tarifaire est limitée dans / les files d'attente de facturation simple avec cela. Les non-payeurs sont automatiquement bloqués et leurs demandes sont redirigées vers le site de rappel. Dans le même temps, les débiteurs ont toujours accès à des ressources externes sélectionnées (services de paiement).

Nous préparons la facturation

La préparation de la facturation implique l'écriture de scripts de traitement des événements pour activer, désactiver, créer, supprimer et modifier le compte de l'abonné. Nous utiliserons Lanbilling comme exemple.



En outre, vous devez vous assurer que c'est l'agent LBarcd qui est responsable des comptes.



Tout d'abord, nous montrons la facturation quels scripts et pour quels événements nous utiliserons. Cela se fait en modifiant les paramètres dans le fichier /etc/billing.conf.LBarcd.

Chaque script est appelé avec un ensemble spécifique de paramètres, pour chaque script l'ensemble est le même:

connexion (nom d'utilisateur dans le compte)
mot de passe (mot de passe utilisateur dans le compte)
segment (adresse IP du compte)
masque de réseau (masque pour l'adresse IP en notation décimale. Par exemple, 255.255.255.255)
limite de taux (taux de ce compte en kilobits. Par exemple, 10240)

Le fichier de configuration des événements d'agent peut être téléchargé à partir du référentiel sur github.
Chaque script de traitement d'événements comprend une bibliothèque de fonctions, qui à son tour utilise une classe PHP pour travailler avec RouterOS via l'API. Le code source de chaque script, bibliothèque de fonctions et classe d'API est disponible dans le référentiel github.
Après avoir apporté des modifications au système «config», il est prêt à fonctionner. Les abonnés qui ont un solde positif sur le compte utilisent calmement le service et les non-payeurs ne peuvent utiliser que le réseau local et les sites autorisés.
Il arrive souvent que l'opérateur doive être en mesure de fournir à l'abonné une inclusion temporaire d'accès automatisée, ou de remplir la liste des ressources autorisées avec les IP de tous les systèmes de paiement connus.

Pour cela, une petite modification est effectuée dans le code source du compte personnel de l'abonné. D'autres fonctions sont déjà configurées - liste d'adresses payeurs-liste sur MikroTik et une fonction supplémentaire allow_payment dans la bibliothèque functions.php.

Dans notre cas, les paiements sont acceptés via Yandex.Checkout, ce qui signifie que nous allons modifier le fichier
/usr/local/billing/phpclient/client2/client/components/payment/yandex/Payment_Yandex_Pay.php à la méthode de traitement pour cliquer sur le bouton "Payer" dans le compte personnel de l'utilisateur.



Vous devez insérer une ligne

file_get_contents (" billing.example.com/tmp_access.php?ip= ". $ _SERVER ["REMOTE_ADDR"]);
avant la ligne
$ this-> post ($ params, $ this-> conf ("operatorURL"));
où billing.example.com est l'adresse de l'interface Web d'administration de Lanbilling .

Ainsi, nous envoyons une demande GET à notre script sur la facturation, et en tant que paramètre nous transférons l'adresse IP du client, qui est dans son compte personnel et clique sur le bouton "Payer". Le contenu du script tmp_access.php peut être consulté et téléchargé sur github. Le script distant ajoute l'adresse IP de l'abonné à la liste des payeurs avec un délai d'attente de 20 minutes, après quoi l'abonné se rend sans problème sur n'importe quelle page pour le paiement.

Si l'abonné entre via Internet mobile, alors l'adresse «gauche» du réseau mobile tombe dans la liste, qui sera supprimée automatiquement après 20 minutes. Si l'abonné provient de l'adresse du réseau local de l'opérateur, le système fonctionnera comme prévu. En fait, le même script peut être inséré sur la page d'avertissement de paiement, où le champ pour entrer le numéro de contrat, le montant du paiement et le bouton "Payer" sont placés.

On peut contester ce qui précède, mais il convient de prendre en compte le fait que cette solution n'est pas pour les grands réseaux. En fait, comme MikroTik avec RouterOS. Si votre réseau ne compte pas plus de 3 000 abonnés, cette méthode sera la plus appropriée.

Préparé par Artyom Deulin