Guide d'Opérations et de Déploiement d'OmniTWAG

Créé par Omnitouch

Ce guide est destiné aux opérateurs de réseau, aux administrateurs système et aux clients déployant OmniTWAG.

Table des Matières

1. Introduction
2. Qu'est-ce que le WiFi Offload ?
3. Architecture de Déploiement
4. Flux de Facturation
5. Flux d'Authentification
6. Guide de Configuration
7. Configuration des Points d'Accès
8. Intégration Hotspot 2.0
9. Surveillance et Gestion
10. Dépannage
11. Conformité aux Normes

---

Introduction

OmniTWAG (Trusted WiFi Access Gateway) est une implémentation conforme aux normes d'un TWAG 3GPP qui permet aux opérateurs de réseaux mobiles de décharger en toute sécurité le trafic des abonnés des réseaux cellulaires vers des points d'accès WiFi tout en maintenant une authentification sécuris��e basée sur la SIM.

Le TWAG authentifie les abonnés WiFi en utilisant leurs identifiants SIM via EAP-AKA (Extensible Authentication Protocol - Authentication and Key Agreement), le même mécanisme d'authentification utilisé dans les réseaux cellulaires. Cela fournit un accès WiFi sécurisé et sans couture pour les abonnés mobiles sans nécessiter de mots de passe WiFi séparés.

Avantages Clés

Pour les Utilisateurs Finaux :

• Zero Configuration : Fonctionne immédiatement avec une SIM compatible
• Expérience Sans Couture : Connexion automatique comme sur le réseau cellulaire
• Sécurisé : Utilise toujours un WiFi crypté (WPA2)
• Pas de Mots de Passe : Authentification basée sur la SIM

Pour les Opérateurs Mobiles :

• Soulagement de la Capacité Réseau : Réduit la charge sur les stations de base cellulaires
• Décharge Contrôlée : Seuls les abonnés autorisés peuvent se connecter
• Amélioration de l'Expérience Utilisateur : Le WiFi offre généralement une bande passante plus élevée
• Efficacité Coût : L'infrastructure WiFi est moins coûteuse que celle des réseaux cellulaires
• Identité Cohérente : Même IMSI utilisé pour le WiFi et le cellulaire
• Intégration de Facturation : Peut facturer l'utilisation du WiFi si désiré

Pour les Lieux/Entreprises :

• Sécurité de Niveau Opérateur : Aucun risque de partage de mots de passe
• Scalabilité : Supporte des milliers d'utilisateurs sans provisionnement manuel
• Gestion Simplifiée : Pas besoin de distribuer des mots de passe WiFi

---

Qu'est-ce que le WiFi Offload ?

Le WiFi offload permet aux opérateurs de réseaux mobiles de rediriger le trafic de données des abonnés des réseaux cellulaires congestionnés vers des réseaux WiFi.

Comment le TWAG Permet la Décharge

Le TWAG agit comme la passerelle d'authentification entre :

• Points d'Accès WiFi (via le protocole RADIUS)
• Réseau Central Mobile HSS/HLR (via l'interface Diameter SWx)

Lorsque le dispositif d'un abonné se connecte à un point d'accès WiFi configuré pour la décharge :

1. Le dispositif s'identifie en utilisant son IMSI (de la carte SIM)
2. Le point d'accès WiFi transmet les demandes d'authentification au TWAG via RADIUS
3. Le TWAG communique avec le HSS de l'opérateur pour récupérer les vecteurs d'authentification
4. L'authentification par défi-réponse EAP-AKA se produit entre le dispositif et le TWAG
5. Après une authentification réussie, l'accès WiFi est accordé au dispositif
6. En option, le trafic peut être tunnelé vers le cœur mobile ou sortir localement

---

Architecture de D��ploiement

Topologie du Réseau

Légende des Interfaces :

• STa* : Interface RADIUS/Diameter entre le point d'accès WiFi et le TWAG (non-3GPP vers AAA)
• SWx : Interface Diameter entre le TWAG (Serveur AAA 3GPP) et le HSS
• S2a/S2b : Interface de tunnel GTP pour le retour vers le réseau domicile (optionnel)
• SGi : Interface vers des réseaux de données de paquets externes (Internet)
• 802.11 : Interface radio WiFi
• EAPOL : EAP sur LAN (authentification 802.1X)

Scénarios de Déploiement

Scénario 1 : Sortie Locale (Recommandé pour la Performance)

Avantages :

• Latence plus faible (pas de retour vers le cœur)
• Charge réduite sur le réseau central
• Meilleure expérience utilisateur pour les applications à forte bande passante
• Économies sur la capacité de retour

Scénario 2 : Routage vers le Réseau Domiciliaire (Tunnel GTP)

Avantages :

• Application cohérente des politiques
• Facturation/chargement centralisé
• Politiques de sécurité/VPN d'entreprise appliquées
• Mobilité sans couture entre WiFi et cellulaire

Options de Connexion SWx

Option 1 : Connexion Directe au HSS

Cas d'Utilisation : Déploiements simples, environnements de laboratoire, HSS unique

Avantages :

• Latence plus faible (pas de saut via DRA)
• Configuration simplifiée
• Dépannage plus facile

Option 2 : Via DRA (Agent de Routage Diameter)

Cas d'Utilisation : Déploiements multi-HSS, scénarios de roaming, réseaux à grande échelle

Avantages :

• Logique de routage centralisée
• Équilibrage de charge entre plusieurs HSS
• Support de roaming (routes vers le HSS domicile)
• Redondance et basculement
• Collage de session

---

Flux de Facturation

Le TWAG peut être entièrement intégré pour envoyer des demandes de facturation en ligne basées sur Diameter Gy à un Système de Facturation en Ligne (OCS).

Cela permet de comptabiliser toutes les données consommées sur WiFi, contre le solde du client, et est délivré via le point d'accès sur RADIUS et converti en Gy par le TWAG et transmis au DRA/OCS.

Dans tous les modes, l'utilisation est suivie par les métriques du TWAG.

Modes de Facturation

Le TWAG prend en charge trois modes de facturation en ligne :

1. Facturation Désactivée

Aucune demande de contrôle de crédit n'est envoyée. Aucune autorisation de solde n'est effectuée.

Cas d'Utilisation :

• Réseaux WiFi ouverts/gratuits
• Environnements de laboratoire/test
• Réseaux avec facturation hors ligne uniquement (comptabilité RADIUS à la facturation)

Flux :

2. Autorisation Seulement

Une CCR-Initial (Demande de Contrôle de Crédit) est envoyée à l'OCS au début de la session WiFi pour valider que l'abonné a un solde, mais le solde n'est pas diminué pendant la session.

Cas d'Utilisation :

• Valider que l'abonné a un compte/solde actif
• Prévenir l'accès WiFi pour les comptes suspendus
• Vérifier l'éligibilité au service sans suivi de quota
• Autoriser le WiFi comme service bonus/illimité pour les clients payants

Flux :

Configuration :

• L'OCS est interrogé au début de la session (CCR-I) et à la fin (CCR-T)
• Aucun message CCR-Update envoyé pendant la session
• Abonné autorisé en fonction de l'état du compte, pas du quota
• Utilisation rapportée à la fin de la session à des fins d'information uniquement

3. Facturation en Ligne Complète Gy (Implémentation Complète)

Le flux de facturation en ligne standard 3GPP est suivi. Toute utilisation sur WiFi est transmise à l'OCS pour facturation, avec l'abonné coupé une fois qu'il a dépassé son quota.

Cas d'Utilisation :

• Services de données prépayés
• WiFi payant à l'utilisation
• Plans basés sur un quota (par exemple, 10 Go d'allocation mensuelle)
• Facturation et coupure en temps réel

Flux :

Configuration :

• OCS interrogé au début de la session (CCR-I), pendant la session (CCR-U), et à la fin (CCR-T)
• Quota demandé en morceaux configurables (par exemple, 10 Mo, 50 Mo, 100 Mo)
• CCR-Update déclenché à un seuil configurable (par exemple, 80 % du quota accordé)
• Le minuteur de validité déclenche une ré-authentification si le quota n'est pas épuisé
• Déconnexion forcée lorsque le quota est épuisé
• Déduction de solde en temps réel

Flux d'Authentification

Séquence Complète d'Authentification EAP-AKA

Points Clés dans le Flux d'Authentification

1. MAR/MAA est la fin de la communication avec le HSS : Après avoir reçu le MAA (Réponse d'Auth Multimédia) avec XRES, le TWAG gère toutes les vérifications ultérieures localement.

2. Le TWAG effectue la vérification de RES : Le HSS fournit la réponse attendue (XRES), mais le TWAG la compare à la RES réelle de l'UE. Le HSS n'est PAS impliqué dans cette comparaison.

3. L'authentification se fait au TWAG : Cela diffère de certains diagrammes qui montrent le HSS effectuant la vérification - dans l'architecture 3GPP réelle, le serveur AAA (TWAG) effectue la comparaison.

Format d'Identité

Le dispositif répond avec son identité permanente (IMSI) au format NAI :

5055700000000000001@wlan.mnc057.mcc505.3gppnetwork.org

Format : 0<IMSI>@wlan.mnc<MNC>.mcc<MCC>.3gppnetwork.org

Note - Le premier chiffre, avant l'IMSI, est l'identité, cela est généralement 0 mais peut être un autre chiffre unique pour les SIMs / appareils multi-IMSI.

Clé de Session Maîtresse (MSK)

La Clé de Session Maîtresse (MSK) est une clé cryptographique de 512 bits (64 octets) dérivée lors de l'authentification EAP-AKA. Elle sert de matériel de clé racine pour sécuriser la connexion WiFi.

Dérivation de MSK :

1. L'UE et le TWAG dérivent indépendamment la même MSK
2. L'UE dérive à partir de CK/IK calculé par la SIM
3. Le TWAG dérive à partir de CK/IK reçu du HSS
4. MSK = PRF'(CK || IK, "Full Authentication", IMSI, ...)

Utilisation de MSK :

1. Dérivation de PMK : PMK = les premiers 256 bits (32 octets) de MSK
2. Échange WPA2 4-Way : L'UE et l'AP utilisent PMK pour dériver PTK
3. Cryptage des Données : Tous les trames de données WiFi sont cryptées avec la Clé Temporelle (TK) dérivée de PTK

Pourquoi MSK est Critique :

• Confidentialité : Sans MSK, le trafic WiFi serait non crypté
• Intégrité : Empêche la falsification des trames WiFi
• Liaison d'Authentification : Lien entre l'authentification EAP et le cryptage WiFi
• Protection contre la Répétition : Une nouvelle MSK empêche les attaques par répétition
• Confidentialité de Forward Parfaite : La compromission d'une MSK n'affecte pas les autres

Récupération de Resynchronisation

Si le dispositif détecte un décalage de numéro de séquence (SQN hors synchronisation), il initie une resynchronisation :

1. Le dispositif calcule AUTS (Jeton d'Authentification - Synchronisation)
2. Envoie EAP-AKA Synchronization-Failure avec AT-AUTS
3. Le TWAG transmet AUTS au HSS
4. Le HSS resynchronise le numéro de séquence et génère de nouveaux vecteurs
5. L'authentification est réessayée avec de nouveaux vecteurs

Cela est transparent pour l'utilisateur final et ne nécessite aucune intervention de l'opérateur.

---

Guide de Configuration

Le TWAG est configuré via des fichiers de configuration Elixir dans le répertoire config/. La configuration principale à l'exécution se trouve dans config/runtime.exs.

Pour les déploiements en production, la configuration est gérée de manière centralisée. Ce qui suit est une référence uniquement, toute valeur modifiée sur un nœud de production sera perdue la prochaine fois que l'orchestration automatisée sera exécutée.

Configuration Diameter

Située dans config :diameter_ex :

config :diameter_ex,
  diameter: %{
    # Nom de service pour la pile Diameter
    service_name: :omnitouch_twag,

    # Adresse IP locale pour lier le service Diameter
    listen_ip: "10.5.198.200",

    # Port local pour les connexions Diameter (standard est 3868)
    listen_port: 3868,

    # Diameter Origin-Host
    host: "omnitwag",

    # Diameter Origin-Realm (correspond à votre domaine réseau)
    realm: "epc.mnc057.mcc505.3gppnetwork.org",

    # Pairs Diameter (HSS, DRA, serveurs AAA)
    peers: [
      %{
        # Pair Diameter Origin-Host
        host: "omni-hss01.epc.mnc057.mcc505.3gppnetwork.org",

        # Pair Diameter Origin-Realm
        realm: "epc.mnc057.mcc505.3gppnetwork.org",

        # Adresse IP du pair (peut être HSS directement ou DRA)
        ip: "10.179.2.140",

        # Port du pair (standard est 3868)
        port: 3868,

        # Utiliser TLS pour la sécurité du transport
        tls: false,

        # Protocole de transport (:diameter_tcp ou :diameter_sctp)
        transport: :diameter_tcp,

        # Initier la connexion au pair (true) ou attendre que le pair se connecte (false)
        initiate_connection: true
      }
    ]
  }

Format de Domaine suit la norme 3GPP TS 23.003 :

epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org

Où :

• MNC = Code de Réseau Mobile (par exemple, 057)
• MCC = Code de Pays Mobile (par exemple, 505 pour l'Australie)

Note sur l'Utilisation de DRA : Pour utiliser OmniDRA, configurez l'adresse IP du pair pour pointer vers le DRA au lieu de directement vers le HSS. Le DRA acheminera ensuite les messages vers le HSS approprié en fonction des règles de routage (Destination-Realm, plage IMSI, etc.).

Configuration RADIUS

Située dans config :omnitwag :

config :omnitwag,
  radius_config: %{
    # Liste des sous-réseaux IP sources autorisées pour les clients RADIUS
    # Liste vide = autoriser tout (non recommandé pour la production)
    allowed_source_subnets: ["10.7.15.0/24", "192.168.1.0/24"],

    # Secret partagé pour les clients RADIUS
    # Tous les AP doivent utiliser ce secret
    secret: "YOUR_STRONG_SECRET_HERE"
  }

Meilleures Pratiques de Sécurité :

• Utilisez des secrets partagés RADIUS forts (20+ caractères)
• Configurez allowed_source_subnets pour restreindre l'accès des AP
• Utilisez des règles de pare-feu pour restreindre l'accès aux ports 1812/1813

Exemple de configuration de sous-réseau :

allowed_source_subnets: ["10.7.15.0/24", "192.168.1.0/24"]

Si vide, toutes les sources sont autorisées (uniquement adapté pour le laboratoire/test).

Configuration de Surveillance Prometheus

Située dans config :omnitwag :

config :omnitwag,
  prometheus: %{
    # Port pour le point de terminaison des métriques Prometheus
    port: 9568
  }

Accédez aux métriques à : http://<twag-ip>:9568/metrics

Résumé des Ports

Port	Protocole	But
1812	UDP	Authentification RADIUS
1813	UDP	Comptabilité RADIUS
3868	TCP	Diameter (SWx vers HSS/DRA)
443	TCP	Tableau de Bord Web HTTPS
8444	TCP	API REST HTTPS
9568	TCP	Métriques Prometheus

---

Configuration des Points d'Accès

Points d'Accès Supportés

OmniTWAG fonctionne avec tout AP WiFi qui supporte :

• WPA2-Enterprise (authentification 802.1X)
• Fonctionnalité client RADIUS
• Méthode d'authentification EAP-AKA

Plateformes testées : Cisco Aironet, Aruba, Ubiquiti UniFi, Ruckus, APs basés sur hostapd

Exigences Générales de Configuration des AP

1. Mode de sécurité WPA2-Enterprise (802.1X)
2. Serveur RADIUS pointant vers l'adresse IP du TWAG
3. Port d'authentification RADIUS : 1812
4. Port de comptabilité RADIUS : 1813 (optionnel mais recommandé)
5. Secret partagé RADIUS : Doit correspondre à la configuration du TWAG
6. Méthode EAP : EAP-AKA (ou "Tous")

Exemple de Configuration AP Cisco

Configuration CLI :

! Configurer le serveur RADIUS
radius-server host 10.5.198.200 auth-port 1812 acct-port 1813 key YOUR_SHARED_SECRET

! Configurer SSID avec 802.1X
dot11 ssid OPERATOR-WIFI
   vlan 10
   authentication open eap eap_methods
   authentication network-eap eap_methods
   authentication key-management wpa version 2

! Associer SSID avec l'interface radio
interface Dot11Radio0
   encryption mode ciphers aes-ccm
   ssid OPERATOR-WIFI

Interface Web :

1. Accédez à Sécurité → AAA → Serveur RADIUS
2. Ajoutez le serveur RADIUS : 10.5.198.200:1812 avec le secret partagé
3. Accédez à la configuration WLAN
4. Définissez la Sécurité sur WPA2-Enterprise
5. Définissez la méthode EAP sur EAP-AKA ou Tous
6. Assignez le groupe de serveurs RADIUS

Exemple de Configuration hostapd

Pour les AP basés sur Linux (OpenWrt, systèmes embarqués) :

# /etc/hostapd/hostapd.conf

interface=wlan0
driver=nl80211
ssid=OPERATOR-WIFI

# WPA2-Enterprise
wpa=2
wpa_key_mgmt=WPA-EAP
wpa_pairwise=CCMP
ieee8021x=1

# Configuration RADIUS
auth_server_addr=10.5.198.200
auth_server_port=1812
auth_server_shared_secret=YOUR_SHARED_SECRET

acct_server_addr=10.5.198.200
acct_server_port=1813
acct_server_shared_secret=YOUR_SHARED_SECRET

# Configuration EAP
eap_server=0

# Hotspot 2.0 (Optionnel - pour décharge automatique)
interworking=1
internet=1
anqp_3gpp_cell_net=505,057
domain_name=wlan.mnc057.mcc505.3gppnetwork.org
nai_realm=0,wlan.mnc057.mcc505.3gppnetwork.org,0,21[2:1][5:7]
roaming_consortium=505057
hs20=1

Meilleures Pratiques d'Architecture Réseau

Important : Placez les AP et le TWAG sur des segments de réseau de confiance. Utilisez des règles de pare-feu pour :

• Autoriser uniquement les AP à atteindre les ports 1812/1813 du TWAG
• Autoriser le TWAG à atteindre le port 3868 du HSS
• Restreindre l'accès de gestion au tableau de bord du TWAG (port 443)

---

Intégration Hotspot 2.0

Vue d'Ensemble de Hotspot 2.0 (Passpoint)

Hotspot 2.0 (également appelé Passpoint ou 802.11u) est une norme de la WiFi Alliance qui permet la découverte et la connexion automatique et sécurisée aux réseaux WiFi sans interaction de l'utilisateur. C'est la technologie clé pour le déchargement WiFi sans couture.

Caractéristiques Clés :

• Découverte Automatique de Réseau : L'appareil trouve des réseaux compatibles en fonction de critères
• Authentification Automatique : Utilise les identifiants SIM (EAP-AKA) sans saisie de l'utilisateur
• Association Initiale Cryptée : OSEN (Authentification uniquement par Serveur OSU) pour un provisionnement sécurisé
• Accords de Roaming : Supporte les réseaux visités (comme le roaming cellulaire)
• Priorisation : L'appareil préfère les réseaux appartenant à l'opérateur

Configuration AP Hotspot 2.0

Exigences pour l'AP :

1. Support 802.11u : Capacité de requête/réponse ANQP
2. WPA2-Enterprise : Authentification 802.1X
3. Support EAP-AKA : Doit supporter la méthode EAP-AKA
4. Configuration ANQP : Annoncez les bonnes informations de l'opérateur

Exemple de Configuration (AP basé sur hostapd) :

# Configuration Hotspot 2.0 / Passpoint
interworking=1
internet=1
asra=0
esr=0
uesa=0

# Configuration ANQP
anqp_3gpp_cell_net=505,057
domain_name=omnitouchns.com,wlan.mnc057.mcc505.3gppnetwork.org

# Configuration du Domaine NAI
nai_realm=0,wlan.mnc057.mcc505.3gppnetwork.org,0,21[2:1][5:7]
# Format : <encoding>,<realm>,<eap-method>[auth-id:auth-val]
# 21 = EAP-AKA
# 2:1 = Type de Credential : SIM
# 5:7 = Méthode EAP Tunelée : Aucune (EAP-AKA direct)

# Consortium de Roaming
roaming_consortium=505057
# MCC=505 (USA), MNC=057 (spécifique à l'opérateur)

# Informations sur le Lieu (optionnel)
venue_group=1
venue_type=8
venue_name=eng:Operator Public WiFi

# Configuration WPA2-Enterprise
wpa=2
wpa_key_mgmt=WPA-EAP
rsn_pairwise=CCMP
ieee8021x=1

# Configuration RADIUS (pointe vers OmniTWAG)
auth_server_addr=10.5.198.200
auth_server_port=1812
auth_server_shared_secret=YOUR_SHARED_SECRET

acct_server_addr=10.5.198.200
acct_server_port=1813
acct_server_shared_secret=YOUR_SHARED_SECRET

# Configuration SSID
ssid=OperatorWiFi
utf8_ssid=1

# Indication Hotspot 2.0
hs20=1
hs20_oper_friendly_name=eng:Operator WiFi Network

Comportement de Décharge Automatique

Comment Fonctionne la Décharge Automatique :

1. L'appareil avec le profil Passpoint effectue une analyse WiFi périodique
2. Envoie une requête ANQP aux AP détectés
3. Si la réponse ANQP correspond au profil (MCC/MNC, consortium de roaming) :
   • La priorité est ÉLEVÉE (réseau domicile) ou MOYENNE (partenaire de roaming)
4. Si la priorité ≥ seuil et le signal > minimum :
   • Authentification automatique EAP-AKA
5. Si l'authentification réussie et la priorité > connexion actuelle :
   • Passer au WiFi, déconnecter les données cellulaires
6. Surveiller la qualité du signal et maintenir la connectivité

Facteurs de Priorité :

1. Domicile vs. Roaming : Le réseau domicile (correspondance MCC/MNC) est préféré au roaming
2. Force du Signal : Un signal plus fort est préféré
3. Sécurité : WPA2-Enterprise est préféré au WiFi ouvert/WPA2-PSK
4. Politique : L'opérateur peut configurer les réseaux préférés
5. Surcharge Utilisateur : L'utilisateur peut désactiver manuellement le WiFi ou préférer le cellulaire

---

Surveillance et Gestion

Tableau de Bord Web

Accédez au tableau de bord de surveillance en temps réel à : https://<twag-ip>/

Fonctionnalités :

• Vue des Clients RADIUS : Abonnés actifs, état d'authentification, détails de session
• Vue des Points d'Accès : AP connectés, comptes clients, informations SSID
• Vue d'Utilisation des Clients : Données de comptabilité, temps de session, utilisation des données
• Vue des Pairs Diameter : État de connexion HSS/DRA

Intégration Prometheus

Configurez Prometheus pour extraire les métriques du TWAG :

# prometheus.yml
scrape_configs:
  - job_name: 'omnitwag'
    static_configs:
      - targets: ['10.5.198.200:9568']
    metrics_path: '/metrics'
    scrape_interval: 15s

Métriques Disponibles :

Métriques du Serveur RADIUS :

• radius_access_request_count - Total des paquets RADIUS Access-Request reçus
• radius_access_accept_count - Total des paquets Access-Accept envoyés
• radius_access_reject_count - Total des paquets Access-Reject envoyés
• radius_access_challenge_count - Total des paquets Access-Challenge envoyés
• radius_accounting_request_count{status_type} - Total des paquets Accounting-Request (étiquetés par statut : start, stop, interim_update, accounting_on, accounting_off)
• radius_active_clients_count - Clients actuellement authentifiés (poll chaque 5 secondes)
• radius_access_points_count - Points d'accès enregistrés (poll chaque 5 secondes)

Métriques d'Authentification EAP-AKA :

• eap_aka_identity_count - Échanges d'identité EAP-AKA
• eap_aka_challenge_count - Échanges de défi EAP-AKA
• eap_aka_sync_failure_count - Échecs de synchronisation (événements de resynchronisation SQN)
• eap_aka_auth_success_count - Authentifications réussies
• eap_aka_auth_reject_count - Authentifications rejetées

Métriques du Protocole Diameter :

• diameter_message_count{application, command, direction} - Total des messages Diameter (étiquetés par application, type de commande et direction)

Métriques de Mémoire de la VM Erlang :

• vm_memory_total - Total de mémoire allouée (octets)
• vm_memory_processes - Mémoire utilisée par les processus Erlang (octets)
• vm_memory_processes_used - Mémoire utilisée par les processus Erlang excluant la mémoire allouée inutilisée (octets)
• vm_memory_system - Mémoire utilisée par le système d'exécution Erlang (octets)
• vm_memory_atom - Mémoire utilisée par les atomes (octets)
• vm_memory_atom_used - Mémoire utilisée par les atomes excluant la mémoire allouée inutilisée (octets)
• vm_memory_binary - Mémoire utilisée par les binaires (octets)
• vm_memory_code - Mémoire utilisée par le code chargé (octets)
• vm_memory_ets - Mémoire utilisée par les tables ETS (octets)

Métriques Système de la VM Erlang :

• vm_system_info_process_count - Nombre actuel de processus Erlang
• vm_system_info_port_count - Nombre actuel de ports
• vm_system_info_atom_count - Nombre actuel d'atomes
• vm_system_info_schedulers - Nombre de threads de planificateur
• vm_system_info_schedulers_online - Nombre de planificateurs actuellement en ligne

Métriques de Planificateur de la VM Erlang :

• vm_statistics_run_queue - Longueur totale de toutes les files d'attente d'exécution
• vm_total_run_queue_lengths_total - Longueur totale de toutes les files d'attente d'exécution (tous les planificateurs)
• vm_total_run_queue_lengths_cpu - Longueur totale des files d'attente d'exécution du planificateur CPU
• vm_total_run_queue_lengths_io - Longueur totale des files d'attente d'exécution du planificateur IO

Collecte de Métriques :

• Les métriques RADIUS et EAP-AKA sont émises en temps réel à mesure que les événements se produisent
• Les comptes de clients actifs et de points d'accès sont pollés toutes les 5 secondes
• Les métriques de la VM sont pollées toutes les 5 secondes depuis l'exécution Erlang
• Toutes les métriques sont exposées au format Prometheus à http://<twag-ip>:9568/metrics

Journalisation

Le TWAG utilise le Logger d'Elixir pour la journalisation structurée.

Afficher les Journaux (systemd) :

# Journal en temps réel
journalctl -u twag -f

# Dernières 100 lignes
journalctl -u twag -n 100

# Journaux depuis le dernier démarrage
journalctl -u twag -b

# Journaux pour une plage horaire spécifique
journalctl -u twag --since "2025-10-12 10:00:00" --until "2025-10-12 11:00:00"

Messages de Journal Clés :

• Serveur RADIUS écoutant sur le port 1812 - Serveur démarré
• De {IP} : Demande d'Accès reçue - Demande RADIUS de l'AP
• Phase 1 : Réponse d'Identité - Identité EAP initiale
• Phase 2 : Défi AKA - Défi envoyé au dispositif
• Authentification ACCEPTÉE - Authentification réussie
• Authentification REJETÉE - Authentification échouée
• AP Enregistré : {IP} - Nouvel AP détecté

---

Dépannage

Échecs d'Authentification

Symptôme : Le client ne peut pas se connecter au WiFi

Étapes de Diagnostic :

1. Vérifiez les journaux du TWAG : journalctl -u twag -f
2. Vérifiez que le secret partagé RADIUS correspond entre l'AP et le TWAG
3. Confirmez que les paquets RADIUS atteignent le TWAG : tcpdump -i eth0 port 1812
4. Vérifiez le provisionnement de l'abonné dans le HSS/configuration

Causes Courantes :

• Secret partagé RADIUS incorrect
• Pare-feu bloquant UDP 1812/1813
• Mismatch RES/XRES (mauvais Ki SIM ou configuration HSS)
• Numéro de séquence (SQN) hors synchronisation (devrait se rétablir automatiquement via resync)
• Problèmes de connectivité réseau entre l'AP et le TWAG

Problèmes de Connexion Diameter

Symptôme : Pair Diameter ne se connecte pas au HSS/DRA

Étapes de Diagnostic :

1. Vérifiez la connectivité réseau : telnet <hss-ip> 3868
2. Vérifiez la configuration Diameter (Origin-Host, Origin-Realm, IP du pair)
3. Consultez les journaux HSS/DRA pour les tentatives de connexion
4. Vérifiez que le pare-feu permet TCP 3868

Causes Courantes :

• IP/port de pair incorrect dans la configuration
• Pare-feu bloquant TCP 3868
• Mismatch Origin-Host/Realm
• HSS/DRA n'acceptant pas la connexion du TWAG

Problèmes de Performance

Symptôme : Authentification lente (>5 secondes)

Étapes de Diagnostic :

1. Vérifiez le temps de réponse du HSS
2. Mesurez la latence réseau : ping <hss-ip>, mtr <hss-ip>
3. Surveillez l'utilisation des ressources du TWAG : top, htop
4. Consultez les paramètres de délai d'attente des requêtes Diameter

Causes Courantes :

• Délai d'expiration de la requête HSS ou réponse lente
• Latence réseau élevée
• Épuisement des ressources du TWAG (CPU/mémoire)
• Trop d'authentifications concurrentes

Outils de Débogage

Capture de Paquet

# Capturer le trafic RADIUS
tcpdump -i eth0 -n port 1812 or port 1813 -w radius.pcap

# Capturer le trafic Diameter
tcpdump -i eth0 -n port 3868 -w diameter.pcap

# Capturer depuis un AP spécifique
tcpdump -i eth0 -n host 10.7.15.72 and port 1812 -w radius-ap1.pcap

Analysez avec Wireshark (supporte les dissectors RADIUS et Diameter).

Console Interactive

Attachez-vous au TWAG en cours d'exécution pour un débogage en direct :

# Shell distant vers le TWAG en cours d'exécution
iex --sname debug --remsh twag@hostname --cookie <cookie>

Depuis la console IEx :

# Lister tous les clients authentifiés
CryptoState.keys()

# Obtenir l'état d'un client spécifique
CryptoState.get("0505338057900001867@wlan.mnc057.mcc505.3gppnetwork.org")

# Lister tous les AP
APState.list()

# Lister les sessions de comptabilité
ClientUsage.list()

Messages d'Erreur Courants

Message d'Erreur	Signification	Solution
Validation de Message-Authenticator échouée	Mismatch de secret partagé	Vérifiez que le secret RADIUS correspond sur l'AP et le TWAG
Échec de vérification RES : attendu <XRES>, obtenu <RES>	Réponse d'authentification incorrecte	Vérifiez Ki SIM, vérifiez le provisionnement HSS
Délai de connexion du pair Diameter	Impossible d'atteindre le HSS	Vérifiez le réseau, le pare-feu, la configuration HSS
Échec de décodage du message EAP	Paquet EAP mal formé	Vérifiez le firmware de l'AP, peut nécessiter une mise à jour de l'AP
Sous-type EAP-AKA inconnu	Message EAP-AKA non pris en charge	Dispositif utilisant une variante EAP-AKA non standard
Synchronisation du numéro de séquence requise	SQN hors synchronisation	Normal, le dispositif se resynchronisera automatiquement

---

Conformité aux Normes

OmniTWAG implémente les spécifications suivantes de 3GPP et IETF :

• 3GPP TS 23.402 : Améliorations de l'architecture pour les accès non-3GPP
• 3GPP TS 24.302 : Accès à l'EPC via des réseaux d'accès non-3GPP
• 3GPP TS 29.273 : Interfaces SWx/SWm basées sur Diameter
• 3GPP TS 33.402 : Aspects de sécurité des accès non-3GPP
• 3GPP TS 35.206 : Spécification de l'algorithme Milenage
• RFC 2865 : Authentification RADIUS
• RFC 2866 : Comptabilité RADIUS
• RFC 3579 : Support RADIUS pour EAP
• RFC 4187 : Protocole d'authentification EAP-AKA
• RFC 5448 : EAP-AKA' (version améliorée)

---

Résumé

OmniTWAG, créé par Omnitouch, fournit une solution complète et conforme aux normes pour le déchargement WiFi 3GPP :

1. Déploiement Flexible : Supporte la sortie locale ou le trafic routé vers le domicile
2. Basé sur des Normes : Implémente les protocoles 3GPP SWx, EAP-AKA, RADIUS
3. Authentification Sécurisée : Authentification mutuelle basée sur la SIM avec resync automatique
4. Cryptage Fort : Clés dérivées de MSK fournissent le cryptage WPA2
5. Prêt pour Hotspot 2.0 : Permet un déchargement entièrement automatique et sans intervention
6. Contrôle de l'Opérateur : Maintient l'identité, la politique, et optionnellement la facturation
7. Connectivité Flexible : Connexion directe au HSS ou via OmniDRA pour le routage/l'équilibrage de charge

---

Version du Document : 2.0 Dernière Mise à Jour : 2025 OmniTWAG - Passerelle d'Accès WiFi de Confiance Copyright © 2025 Omnitouch. Tous droits réservés.