Intercepció legal

lippycat implementa interfícies d’intercepció legal (LI) segons els estàndards ETSI, que permeten interceptar comunicacions amb autorització quan es desplega dins d’una infraestructura d’intercepció legal. Aquest capítol tracta l’arquitectura, el desplegament i el funcionament de les capacitats LI per als operadors que necessiten integrar lippycat amb sistemes ADMF (Administration Function) i MDF (Mediation/Delivery Function).

Important. La intercepció legal està subjecta a requisits legals estrictes en totes les jurisdiccions. Desplegar capacitats LI sense l’autorització legal adequada és il·legal. Assegureu-vos que la vostra organització disposi del marc legal, els processos de supervisió i els controls d’auditoria necessaris abans d’activar funcions LI.

Visió general de les interfícies ETSI

lippycat implementa tres interfícies ETSI definides a TS 103 221-1 i TS 103 221-2:

La interfície X1 transporta comandaments administratius: l’ADMF envia peticions d’activació, modificació i desactivació de tasques al processador (que actua com a Network Element). La interfície X2 lliura Intercept Related Information (IRI), inclosos els esdeveniments de senyalització SIP. La interfície X3 lliura Content of Communication (CC): les dades útils reals dels mitjans, com l’àudio RTP.

Arquitectura

El diagrama següent mostra com interactuen l’ADMF, el processador lippycat i el MDF:

flowchart TB
    ADMF["ADMF<br/>(Administration)"]

    subgraph NE["lippycat Processor"]
        X1["X1 Server :8443"]
        LIM["LI Manager"]
        ENC["X2/X3 Encoder"]
        DC["Delivery Client"]
        X1 <--> LIM
        LIM --> ENC --> DC
    end

    subgraph Hunters["Hunter Nodes"]
        H1["Hunter 1"]
        H2["Hunter 2"]
    end

    MDF["MDF<br/>(Mediation/Delivery)"]

    ADMF <-->|"X1 (HTTPS/mTLS)"| X1
    LIM -->|"filters"| Hunters
    H1 -->|"matched packets"| LIM
    H2 -->|"matched packets"| LIM
    DC -->|"X2 IRI (TLS)"| MDF
    DC -->|"X3 CC (TLS)"| MDF

El flux funciona de la manera següent:

1. L’ADMF envia una tasca d’intercepció al processador mitjançant la interfície X1 (o el processador consulta les tasques existents a l’ADMF en iniciar-se: vegeu Sincronització de l’estat ADMF).
2. El gestor LI tradueix els identificadors d’objectiu de la tasca a filtres de captura i els transmet als Hunters connectats.
3. Els Hunters comparen els paquets amb aquells filtres a la vora de la xarxa i transmeten el trànsit coincident al processador.
4. El processador codifica la senyalització SIP coincident i les metadades de protocol activades i autoritzades com a PDU X2 IRI i els mitjans RTP com a PDU X3 CC.
5. El client de lliurament envia les PDU codificades als extrems MDF designats mitjançant TLS.

Requisits de compilació

El suport LI es controla amb l’etiqueta de compilació li. Les compilacions estàndard exclouen tot el codi LI mitjançant eliminació de codi mort: els binaris sense LI no contenen tipus, gestors ni vies de configuració LI.

Compileu el processador amb suport LI:

make processor-li

Compileu el conjunt complet amb suport LI:

make build-li

Compileu Tap amb suport LI per a captura independent i lliurament LI:

make tap-li

Verifiqueu que les compilacions sense LI no continguin codi LI:

make verify-no-li

Els Hunters no necessiten suport LI. Fan filtratge a la vora de la xarxa amb la mateixa infraestructura de filtres tant si els filtres provenen de tasques LI com de configuració manual. Només el processador (o Tap en mode independent) necessita l’etiqueta de compilació li perquè allotja el servidor X1 i el client de lliurament X2/X3.

Configuració i desplegament

Activació de LI

LI s’activa amb l’opció --li-enabled al processador o Tap. L’adreça d’escolta X1, el certificat del servidor, la clau del servidor i la CA de client ADMF són obligatoris; una configuració TLS X1 incompleta fa fallar l’inici. També calen certificats de lliurament per a la comunicació MDF.

Inicialitzeu o migreu un magatzem xifrat de filtres gestionats abans d’activar LI. La persistència administrativa, quan està configurada, també requereix una instantània xifrada inicialitzada amb la seva pròpia clau independent de 32 bytes en brut. L’estat en text pla no es carrega mai en execució. Seguiu la guia de configuració i migració d’emmagatzematge amb el node aturat. L’exemple següent pressuposa que aquestes instantànies ja existeixen. --li-state-file buit desactiva la persistència administrativa quan la reproducció no la requereix.

lc process --listen :55555 \
  --tls-cert server.crt --tls-key server.key \
  --li-enabled \
  --filter-file /var/lib/lippycat/filters.enc \
  --filter-store-key-id filters-1 --filter-store-key-file /etc/lippycat/keys/filters.key \
  --li-state-file /var/lib/lippycat/li-state.enc \
  --li-state-key-id state-1 --li-state-key-file /etc/lippycat/keys/li-state.key \
  --li-x1-listen :8443 \
  --li-x1-tls-cert /etc/lippycat/li/x1-server.crt \
  --li-x1-tls-key /etc/lippycat/li/x1-server.key \
  --li-x1-tls-ca /etc/lippycat/li/admf-ca.crt \
  --li-admf-endpoint https://admf.example.com:8443 \
  --li-admf-tls-cert /etc/lippycat/li/x1-client.crt \
  --li-admf-tls-key /etc/lippycat/li/x1-client.key \
  --li-admf-tls-ca /etc/lippycat/li/admf-ca.crt \
  --li-delivery-tls-cert /etc/lippycat/li/delivery.crt \
  --li-delivery-tls-key /etc/lippycat/li/delivery.key \
  --li-delivery-tls-ca /etc/lippycat/li/mdf-ca.crt

La mateixa configuració es pot expressar en YAML. Aquest és l’enfocament recomanat per a desplegaments de producció:

# /etc/lippycat/config.yaml
processor:
  listen_addr: ":55555"
  tls:
    enabled: true
    cert_file: "/etc/lippycat/certs/server.crt"
    key_file: "/etc/lippycat/certs/server.key"

  filter_file: "/var/lib/lippycat/filters.enc"
  filter_store:
    mode: auto
    key_id: "filters-1"
    key_file: "/etc/lippycat/keys/filters.key"

  li:
    enabled: true
    state_file: "/var/lib/lippycat/li-state.enc"
    state_key_id: "state-1"
    state_key_file: "/etc/lippycat/keys/li-state.key"

    # X1 server — receives task requests from ADMF
    x1_listen_addr: ":8443"
    x1_tls_cert: "/etc/lippycat/li/x1-server.crt"
    x1_tls_key: "/etc/lippycat/li/x1-server.key"
    x1_tls_ca: "/etc/lippycat/li/admf-ca.crt"

    # X1 client — sends notifications to ADMF and queries state
    admf_endpoint: "https://admf.example.com:8443"
    admf_tls_cert: "/etc/lippycat/li/x1-client.crt"
    admf_tls_key: "/etc/lippycat/li/x1-client.key"
    admf_tls_ca: "/etc/lippycat/li/admf-ca.crt"
    admf_keepalive: "30s"

    # ADMF state synchronization
    admf_sync_on_startup: true # Query ADMF for state on startup
    admf_sync_timeout: "30s" # Timeout for startup sync
    admf_reconcile_interval: "5m" # Periodic reconciliation (0 = disabled)

    # X2/X3 delivery — sends intercept data to MDF
    delivery_tls_cert: "/etc/lippycat/li/delivery.crt"
    delivery_tls_key: "/etc/lippycat/li/delivery.key"
    delivery_tls_ca: "/etc/lippycat/li/mdf-ca.crt"
    delivery_tls_pinned_cert:
      - "sha256:A1B2C3D4E5F6..." # Optional: pin MDF certificates

Configuració de certificats LI

Les interfícies LI requereixen TLS mutu (mTLS) en totes les connexions. Això significa que el processador ha de presentar un certificat de client en connectar-se a l’ADMF i el MDF i ha de verificar els certificats presentats per aquells sistemes. Hi intervenen tres cadenes de certificats separades:

flowchart TB
    subgraph chains["Certificate Chains"]
        direction TB

        subgraph admf_chain["ADMF Chain"]
            ADMF_CA["ADMF CA"]
            ADMF_Cert["ADMF Client Cert"]
            ADMF_CA --> ADMF_Cert
        end

        subgraph li_chain["LI CA Chain (your organization)"]
            LI_CA["LI CA"]
            X1Srv["X1 Server Cert<br/>(processor)"]
            X1Cli["X1 Client Cert<br/>(notifications → ADMF)"]
            Deliv["Delivery Cert<br/>(X2/X3 → MDF)"]
            LI_CA --> X1Srv
            LI_CA --> X1Cli
            LI_CA --> Deliv
        end

        subgraph mdf_chain["MDF Chain"]
            MDF_CA["MDF CA"]
            MDF_Cert["MDF Server Cert"]
            MDF_CA --> MDF_Cert
        end
    end

Els certificats necessaris al costat del processador són:

Tots els certificats han d’utilitzar claus RSA 2048+ o ECDSA P-256+ amb hash SHA-256 o més fort. El servidor X1 requereix TLS 1.3 i una CA de client ADMF de confiança; no s’inicia si falta l’adreça d’escolta, el certificat, la clau o la CA de client. Les interfícies sortints X1 i X2/X3 requereixen TLS 1.2 o posterior.

Per als conceptes generals TLS i la generació de certificats, consulteu el Capítol 13: seguretat. La diferència principal per a LI és mantenir cadenes CA separades per a l’ADMF, els certificats LI de la vostra organització i el MDF: habitualment els operen entitats diferents.

Permisos de fitxer. Només el propietari del procés ha de poder llegir les claus privades:

chmod 600 /etc/lippycat/li/*.key

chmod 644 /etc/lippycat/li/*.crt

chmod 700 /etc/lippycat/li/

chown root:root /etc/lippycat/li/*

Fixació de certificats. Per a més garanties en la via de lliurament X2/X3, podeu fixar el certificat del servidor MDF mitjançant la seva empremta SHA-256:

Obteniu l’empremta:

openssl x509 -in mdf-server.crt -noout -fingerprint -sha256 | \
  sed 's/://g' | cut -d= -f2

Configureu la fixació amb l’empremta obtinguda:

--li-delivery-tls-pinned-cert sha256:A1B2C3D4E5F6...

Quan la fixació està configurada, el client de lliurament rebutja qualsevol certificat MDF que no coincideixi amb una empremta fixada, encara que el certificat sigui altrament vàlid sota la CA configurada.

Interfície d’administració X1

La interfície X1 és el pla de control entre l’ADMF i el processador. L’ADMF la utilitza per gestionar tasques d’intercepció i destinacions de lliurament; el processador la utilitza per retornar notificacions d’estat a l’ADMF.

Operacions admeses

Totes les peticions utilitzen codificació XML segons ETSI TS 103 221-1. Per exemple, una petició ActivateTask inclou l’identificador de tasca (XID), els identificadors d’objectiu, els ID de destinació i el tipus de lliurament:

<activateTaskRequest>
  <x1RequestMessage>
    <admfIdentifier>ADMF-001</admfIdentifier>
    <x1TransactionId>550e8400-e29b-41d4-a716-446655440000</x1TransactionId>
    <messageTimestamp>2025-12-27T10:30:00Z</messageTimestamp>
    <version>v1.13.1</version>
  </x1RequestMessage>
  <taskDetails>
    <xId>a1b2c3d4-e5f6-7890-abcd-ef1234567890</xId>
    <targetIdentifiers>
      <targetIdentifier>
        <sipUri>sip:alicent@example.com</sipUri>
      </targetIdentifier>
    </targetIdentifiers>
    <listOfDIDs>
      <dId>d1e2f3g4-h5i6-7890-jklm-nop123456789</dId>
    </listOfDIDs>
    <deliveryType>X2andX3</deliveryType>
    <implicitDeactivationAllowed>true</implicitDeactivationAllowed>
  </taskDetails>
</activateTaskRequest>

Cicle de vida de les tasques

Les tasques passen pels estats següents:

GetTaskDetails informa del valor de provisió definit per l’esquema awaitingProvisioning per a tasques pendents, failed per a tasques fallides i complete per a tasques actives, suspeses i desactivades. X1 no emet cap extensió d’estat de tasca específica de fabricant.

Quan implicitDeactivationAllowed està establert a true, el processador desactiva automàticament la tasca quan arriba a EndTime i notifica l’ADMF. Quan està establert a false, només una petició explícita DeactivateTask o un error fatal pot acabar la tasca.

Les tasques es poden modificar mentre estan actives. Els camps següents es poden modificar amb ModifyTask:

• Identificadors d’objectiu (afegeix o elimina criteris de filtre)
• ID de destinació (canvia els extrems de lliurament)
• Tipus de lliurament (canvia entre X2Only, X3Only, X2andX3)
• Hora d’acabament
• Paràmetre de desactivació implícita

XID i StartTime no es poden modificar després de l’activació.

Reintent idempotent i reactivació explícita

Repetir un ActivateTask equivalent mentre una tasca està activa o pendent és un reintent idempotent. No reinstal·la filtres, no avança la generació d’activació ni canvia el límit d’inici programat.

Una tasca desactivada es conserva temporalment com a marca de baixa i no es pot reprendre automàticament. Un ActivateTask explícit i autenticat només la pot reactivar quan la identitat d’intercepció protegida no ha canviat: han de coincidir l’XID, el tipus de lliurament i el conjunt canònic de parelles tipus/valor d’objectiu. L’ordre dels objectius i els duplicats exactes són irrellevants. La nova petició pot substituir els ID de destinació, les hores d’inici i acabament de mediació i les opcions de cicle de vida, subjecta a la validació actual normal. Les tasques suspeses i fallides continuen sense poder utilitzar aquesta operació.

Configureu totes les destinacions de substitució abans de reactivar i verifiqueu que cadascuna admeti el tipus de lliurament demanat. En cas d’èxit, el processador conserva l’antiga desactivació a l’historial d’auditoria, avança la generació d’activació i instal·la només els filtres nous. En cas de fallada de validació o instal·lació, la marca de baixa continua sense aplicar filtres i sense canvis. Si es perd la resposta, utilitzeu GetTaskDetails abans de reintentar: una petició idèntica activa/pendent es pot repetir amb seguretat; un resultat deactivated requereix una altra activació explícita després de corregir l’error subjacent.

Tipus de lliurament

Cada tasca especifica quina informació s’ha de lliurar:

Notificacions ADMF

El processador envia notificacions a l’ADMF per informar de l’estat operatiu:

Configureu l’interval keepalive amb --li-admf-keepalive:

Envieu un keepalive cada 30 segons:

--li-admf-keepalive 30s

Desactiveu els keepalive:

--li-admf-keepalive 0

Sincronització de l’estat ADMF

Quan lippycat es reinicia, es perd tot l’estat de tasques i destinacions en memòria. Per recuperar-lo sense esperar que l’ADMF torni a enviar cada tasca individualment, el processador consulta l’estat actual a l’ADMF en iniciar-se amb l’operació estàndard GetAllDetails definida a ETSI TS 103 221-1.

La sincronització d’inici està activada per defecte. Després d’enviar la notificació d’inici, el processador crida GetAllDetails a l’ADMF, que retorna totes les tasques i destinacions assignades a aquest element de xarxa. El processador registra cada destinació i activa cada tasca, recreant automàticament tot l’estat de filtres i lliurament.

sequenceDiagram
    participant P as Processor
    participant A as ADMF
    P->>A: ReportNEIssue (Startup)
    P->>A: GetAllDetailsRequest
    A-->>P: GetAllDetailsResponse<br/>(tasks + destinations + NE status)
    Note over P: Register destinations
    Note over P: Activate tasks & push filters
    P->>P: Normal operation resumes

La sincronització està dissenyada per gestionar les limitacions de manera controlada:

• ADMF inaccessible: la sincronització esgota el temps d’espera (30 segons per defecte) i el processador continua l’inici. L’ADMF pot enviar tasques més tard amb ActivateTask.
• L’ADMF no admet GetAllDetails: algunes implementacions mínimes d’ADMF només admeten enviar estat. Quan l’ADMF retorna un error UnsupportedOperation, el processador registra un avís i continua normalment.
• Fallades de tasques individuals: si una tasca o destinació concreta no s’activa (per exemple, per un tipus d’objectiu no admès), s’omet amb un avís i es processen els elements restants.

Opcions de configuració:

Per desactivar la sincronització d’inici (per exemple, en entorns on l’ADMF sempre envia l’estat):

--li-admf-sync-on-startup=false

La conciliació periòdica protegeix contra desviacions de configuració durant execucions llargues i està activada per defecte (5m). El processador consulta periòdicament l’ADMF i concilia el seu estat local amb la resposta:

• S’activen les tasques presents a l’ADMF però absents localment.
• Es desactiven les tasques presents localment però absents a l’ADMF i se n’eliminen els filtres. Un DeactivateTask que no arribés mai deixaria una intercepció en execució sense autorització ni caducitat.

El desmantellament és deliberadament conservador, perquè eliminar erròniament una ordre vigent és tan greu com recollir massa dades. No s’elimina res quan:

• la petició ADMF falla (una interrupció no arriba mai a la via de desmantellament);
• alguna tasca de la resposta no es pot analitzar, perquè llavors la visió és incompleta;
• la resposta conté zero tasques mentre hi ha tasques actives localment: el procediment de recuperació ADMF respon així mentre reconstrueix les seves taules, de manera que eliminar l’última tasca requereix un DeactivateTask explícit.

Una tasca també ha de ser absent en dues consultes consecutives abans d’eliminar-la (ReconcileOrphanPolls), cosa que comporta un interval de recollida excessiva i evita anomalies d’una sola consulta. Cada desactivació automàtica es registra a nivell WARN amb l’XID.

La mateixa conciliació s’executa durant la sincronització d’inici, on actua sobre la primera resposta: els filtres es persisteixen al disc i es recarreguen abans que existeixi el registre, de manera que un filtre obsolet es reactivaria a cada reinici. Els filtres que no pertanyen a LI no es modifiquen mai.

Concilieu cada cinc minuts (valor per defecte):

--li-admf-reconcile-interval 5m

Desactiveu la conciliació perquè les desviacions no es corregeixin mai:

--li-admf-reconcile-interval 0

Configuració YAML:

processor:
  li:
    admf_sync_on_startup: true
    admf_sync_timeout: "30s"
    admf_reconcile_interval: "5m" # 0 disables; drift is then never corrected

Codis d’error X1

Quan el processador no pot satisfer una petició X1, retorna un error estructurat:

Quan la reactivació canvia un objectiu protegit o el tipus de lliurament, el codi 100 té la descripció estable retained task's interception identity differs seguida de l’XID. Això és intencionadament diferent del codi 300: el codi 300 continua significant una definició contradictòria per a un XID actiu o pendent. Els operadors han d’investigar una diferència d’identitat amb codi 100 en lloc de canviar l’objectiu d’intercepció sota l’XID conservat.

Lliurament X2/X3

Les dades interceptades es lliuren als extrems MDF amb codificació TLV binària (Type-Length-Value) segons ETSI TS 103 221-2.

Lliurament X2 IRI

X2 lliura esdeveniments IRI derivats de SIP, metadades de protocol activades i missatges RADIUS en brut. El lliurament requereix una tasca autoritzadora vigent i una destinació X2 activada; s’apliquen requisits d’autorització específics del protocol.

Esdeveniments IRI derivats de SIP

Les PDU X2 transporten metadades de senyalització derivades de missatges SIP:

Cada PDU X2 derivada de SIP inclou atributs estructurats: marca temporal, IP i port d’origen/destinació, Call-ID SIP, capçaleres From/To i un número de correlació que enllaça esdeveniments relacionats dins de la mateixa sessió.

Missatges RADIUS (format 11)

La captura ordinària sniff radius, hunt radius i tap radius no requereix una compilació LI ni una tasca X1. En una compilació LI, el lliurament X2 en brut amb format 11 és una sortida autoritzada separada i requereix una tasca X2Only vigent amb un àmbit que coincideixi amb el desplegament de captura. Vegeu Captura RADIUS i POI per a assignacions NatParas, aïllament d’àmbit, estat de correlació i configuració MDF.

RADIUS utilitza un codificador dedicat de format 11. Les seves dades útils contenen el missatge RADIUS original validat sense encapsulació Ethernet/IP/UDP ni farciment final. Payload Direction és Unknown i el Correlation ID de vuit bytes identifica un intercanvi observat, no una sessió d’abonat. Aquesta sortida en brut és separada de l’IRI derivat de SIP i de les metadades normalitzades de protocol.

S’admeten desplegaments Tap independents i Hunt/Process directes. En transmetre paquets RADIUS directament del Hunter al processador, utilitzeu TLS mutu i actualitzeu tots dos per admetre identitat autoritativa de l’origen de captura i instantànies de filtres. No s’admet autorització X2 d’origen de relé. Abans del desplegament en producció, verifiqueu les assignacions d’objectiu amb una línia d’abonat coneguda a la xarxa de l’operador i acordeu les convencions de format 11, direcció, correlació, duplicats i tractament d’orfes amb el MDF receptor.

Contingut X3 CC

Les PDU X3 transporten contingut de comunicació; X3 no és un transport de logs estructurats:

Les PDU X3 inclouen atributs específics d’RTP (SSRC, número de seqüència, marca temporal, tipus de dades útils) i un ID de flux que es correlaciona amb els esdeveniments de sessió X2.

Atribució de trucades amb tancament segur

La selecció X3 basada en identitat només s’hereta després que la resolució exacta dels extrems RTP demostri una única trucada activa. Els extrems compartits o desconeguts no escullen un guanyador per recència ni combinen filtres de totes les trucades candidates. La coincidència d’identitat se suprimeix. Els objectius directes d’adreça IP i CIDR encara coincideixen amb els extrems dels paquets, de manera que continuen sent vàlids encara que la pertinença de la trucada sigui ambigua.

La finalització tanca tant la via X3 com la sortida per trucada. Les entrades en buffer de la generació de trucada finalitzada es descarten i la codificació o el lliurament posteriors es rebutgen. Els Call-ID tancats es conserven una hora per defecte en un registre limitat de 100.000 marques de baixa. La reutilització després de la caducitat crea una generació nova; el contingut antic en buffer no hi pot passar.

Rendiment del lliurament

El subsistema de lliurament utilitza cues asíncrones amb control de contrapressió per gestionar una alta capacitat de transmissió:

El lliurament utilitza un conjunt de connexions reutilitzables, un distribuïdor ordenat per destinació MDF, lots (per defecte: 100 PDU per lot) i una cua limitada per destinació (per defecte: 10.000 elements). Les PDU continuen en cua mentre una destinació es reconnecta i s’envien en ordre FIFO després de la recuperació. Si una interrupció sostinguda omple una cua, es descarta la PDU més antiga i es registra a les estadístiques de lliurament de la destinació. Els reintents proporcionen lliurament almenys una vegada; per tant, una escriptura TCP amb resultat incert pot produir un duplicat al MDF.

La distribució a diverses destinacions MDF segueix el principi de tancament segur però no és atòmica entre destinacions. La primera destinació accepta amb les admissions existents de tasca i trucada del paquet; cada destinació posterior les torna a comprovar. Si la tasca o trucada es finalitza durant la distribució, un MDF anterior pot rebre la PDU mentre els posteriors la rebutgen. El rebuig es compta a la telemetria aplicable de supressió o descart del buffer. Els desplegaments que requereixen lliurament atòmic entre MDF han de coordinar-lo fora de lippycat i conciliar les estadístiques de seqüència i descart de cada destinació.

Integració de filtres

Quan l’ADMF activa una tasca, el gestor LI tradueix els identificadors d’objectiu al sistema intern de filtres de lippycat. S’utilitza la mateixa infraestructura de filtres optimitzada descrita als capítols anteriors sobre Hunters (Capítol 7) i processadors (Capítol 8).

Assignació d’objectius a filtres

Flux de filtres

La via completa des de l’activació de la tasca fins al lliurament de PDU és:

flowchart TD
    A["ADMF activates task via X1"] --> B["LI Manager creates filters<br/>for each target identifier"]
    B --> C["Filters pushed to hunters<br/>via gRPC management stream"]
    C --> D["Hunters match packets<br/>using optimized filter engines"]
    D --> E["Matched packets forwarded<br/>to processor with filter IDs"]
    E --> F["LI Manager correlates<br/>filter ID → XID"]
    F --> G{"Authorized output?"}
    G -->|SIP signaling| H["X2 Encoder<br/>(IRI PDU)"]
    G -->|Normalized protocol metadata| H
    G -->|RTP media| I["X3 Encoder<br/>(CC PDU)"]
    H --> J["Delivery Client → MDF"]
    I --> J

Cada filtre creat pel gestor LI rep un ID intern amb el format li-{xid_prefix}-{index} (per exemple, li-a1b2c3d4-0). Quan arriben al processador paquets coincidents amb aquests filtres, el gestor LI busca l’XID corresponent i encamina l’IRI SIP, les metadades normalitzades de protocol activades i el contingut de comunicació per les vies de lliurament adequades.

Quan es desactiva una tasca, els filtres associats s’eliminen de tots els Hunters i la coincidència s’atura immediatament.

Consideracions de configuració i manteniment

Aïllament de xarxa

La infraestructura LI s’ha de desplegar en una xarxa de gestió dedicada, separada del trànsit de producció i de la supervisió habitual. L’extrem X1 (port 8443 per defecte) i les connexions de lliurament X2/X3 no han de ser accessibles des de segments generals de xarxa. Utilitzeu regles de tallafoc per restringir l’accés només a adreces ADMF i MDF autoritzades.

Rotació de certificats

Els certificats LI han de tenir períodes de validesa curts (un any o menys) i s’han de rotar abans de caducar. Superviseu la caducitat dels certificats com a part de les operacions habituals:

Comproveu si un certificat caduca en els pròxims 30 dies:

openssl x509 -in /etc/lippycat/li/x1-server.crt -noout -checkend 2592000

Per rotar els certificats:

1. Genereu certificats nous (o obteniu-los de la PKI de la vostra organització).
2. Actualitzeu la configuració del processador per referenciar els fitxers de certificat nous.
3. Reinicieu el processador de manera controlada. Les tasques actives es restauren automàticament: el processador envia una notificació d’aturada i, en reiniciar-se, consulta l’ADMF amb GetAllDetails per restaurar tot l’estat de tasques i destinacions (vegeu Sincronització de l’estat ADMF).
4. Verifiqueu la connectivitat amb l’ADMF i el MDF després de reiniciar.

Per als entorns de producció, considereu utilitzar un mòdul de seguretat de maquinari (HSM) per emmagatzemar claus privades i un sistema automatitzat de gestió del cicle de vida dels certificats.

Registre d’auditoria

Totes les operacions LI es registren als logs estructurats del processador. Els camps principals dels logs d’esdeveniments LI inclouen:

Aquests logs s’han de transmetre a un sistema segur de gestió de logs que evidenciï manipulacions, com a part dels requisits d’auditoria LI de la vostra organització.

Mode independent amb Tap

Per als desplegaments que no necessiten una topologia separada de Hunter i processador, el node tap es pot compilar amb suport LI:

make tap-li

En aquesta configuració, el node Tap captura paquets localment i lliura PDU X2/X3 directament al MDF sense sobrecàrrega gRPC. Això és útil per a desplegaments d’una sola interfície o entorns de laboratori. Totes les opcions de configuració LI funcionen de la mateixa manera al node Tap.

Resolució de problemes

El servidor X1 no s’inicia

Si el servidor HTTPS X1 no s’inicia:

1. Verifiqueu que el processador s’hagi compilat amb -tags li (utilitzeu make processor-li o make build-li).
2. Comproveu que els certificats TLS siguin vàlids i no hagin caducat.
3. Confirmeu que el certificat de CA coincideixi amb els certificats de client ADMF.
4. Assegureu-vos que el port d’escolta (8443 per defecte) no estigui ja en ús.

Fallades de lliurament X2/X3

Si les PDU no arriben al MDF:

1. Confirmeu que la destinació MDF s’hagi registrat mitjançant una petició CreateDestination a X1.
2. Verifiqueu la connectivitat de xarxa amb l’extrem MDF.
3. Comproveu que el certificat de client de lliurament estigui signat per una CA de confiança per al MDF.
4. Superviseu la profunditat de la cua de lliurament: una cua plena indica que el MDF no pot seguir el ritme o és inaccessible.

Atribució RTP i senyals del cicle de vida

Tracteu l’augment dels comptadors de mitjans ambiguous/unknown, identity_inheritance_suppressed, inherited_provenance_rejected, x3_finalized_or_stale_suppressed, x3_buffered_discarded i d’expulsió per capacitat de marques de baixa de cicle de vida com a senyals de seguretat. L’ambigüitat sol indicar extrems de mitjans compartits o visibilitat SDP incompleta. Els rebutjos de generacions finalitzades/obsoletes solen indicar lots tardans, retard de reordenació o reutilització de Call-ID. Els avisos estructurats tenen freqüència limitada i només exposen identificadors depurats o amb hash; compareu diferències de comptadors per mesurar el volum.

Les tasques no coincideixen amb el trànsit

Si una tasca activa no genera dades d’intercepció:

1. Verifiqueu que l’estat de la tasca sigui Active (utilitzeu GetTaskDetails amb X1).
2. Comproveu que el format de l’objectiu coincideixi exactament amb el trànsit (per exemple, una URI SIP completa sip:user@domain en lloc de només la part d’usuari).
3. Confirmeu que s’hagin transmès els filtres als Hunters (comproveu els logs del processador per als esdeveniments de transmissió de filtres).
4. Verifiqueu que els Hunters rebin trànsit coincident amb els identificadors d’objectiu.

Registre de depuració

Activeu logs de nivell debug per a diagnòstics LI detallats:

LOG_LEVEL=debug lc process --li-enabled ...

Per verificar manualment la connectivitat TLS amb els extrems X1 o de lliurament:

Proveu el servidor X1:

openssl s_client -connect localhost:8443 \
  -cert x1-client.crt -key x1-client.key \
  -CAfile li-ca.crt

Proveu el lliurament al MDF:

openssl s_client -connect mdf.example.com:443 \
  -cert delivery.crt -key delivery.key \
  -CAfile mdf-ca.crt

Lliurament limitat i recuperació després d’un reinici

El processador i Tap admeten límits independents de bytes codificats X2/X3 amb --li-delivery-x2-queue-bytes i --li-delivery-x3-queue-bytes. Tant els límits de bytes com de PDU s’apliquen per destinació i interfície, incloses les escriptures reservades. L’opció --li-delivery-memory-budget-bytes reserva capacitat entre destinacions i requereix límits explícits de bytes. Dimensioneu els pressupostos com els bytes codificats màxims per segon multiplicats per la durada de la interrupció, amb marge i capacitat de PDU suficient. L’amplada de banda de recuperació ha de superar el trànsit en directe. Les altres necessitats de memòria del processador requereixen dimensionament separat.

--li-delivery-x3-max-age=5m fa caducar X3 cinc minuts després de l’admissió local, incloses la reordenació i els reintents, fins i tot sense connexió. Per defecte no hi ha caducitat. X2 no hereta l’edat X3. Completar una escriptura local no demostra la recepció remota.

La persistència X2 xifrada s’activa explícitament amb --li-delivery-x2-spool-dir, un --li-delivery-x2-spool-max-bytes positiu i --li-delivery-x2-spool-key-file amb una clau AES privada de 32 bytes en brut. X3 només resideix en memòria si no es configura el seu diari independent. L’èxit d’inserció en cua és admissió, no una confirmació de durabilitat; una caiguda pot perdre registres encara no sincronitzats. Els diaris plens rebutgen productes nous tot conservant els registres persistits.

X2 recuperat es reté per defecte i requereix conciliació explícita d’identitat i autorització mitjançant l’API del pla de control que l’integra abans de reproduir-lo. Reutilitzar un XID o un UUID de destinació no autoritza registres antics. La CLI accepta un manifest de reproducció privat explícit després de la conciliació d’inici ADMF. --li-delivery-x2-spool-replay-policy=purge elimina explícitament els registres recuperats; manteniu el valor per defecte hold si no teniu intenció de descartar-los. lc show status informa de pressupostos de bytes, bytes en cua i en curs, productes caducats, bytes descartats etiquetats per motiu i comptadors de diari pendents, persistits i retinguts. Els desplegaments existents conserven els límits anteriors fins que es configuren opcions noves.

X3 persistent requereix --li-delivery-x3-spool-dir, un --li-delivery-x3-spool-max-bytes explícit positiu, una clau privada independent de 32 bytes en brut seleccionada amb --li-delivery-x3-spool-key-id i --li-delivery-x3-spool-key-file i un --li-delivery-x3-max-age positiu. També calen estat administratiu xifrat i conciliació d’inici ADMF. Cada magatzem utilitza la seva pròpia capacitat limitada; configureu els pressupostos de memòria i disc per a tots dos magatzems i les entrades contínues.

L’acabament normal d’una trucada tanca la captura nova per a aquella instància de trucada i conserva els pendents durables elegibles. La retirada de la tasca, la substitució de destinació i la revocació explícita bloquegen el lliurament històric. Les dates límit d’admissió originals no es reinicien mai en acabar la trucada ni en reiniciar el procés. Un procés aturat no pot eliminar fitxers caducats; l’inici comprova la caducitat abans de l’elegibilitat de reproducció.

X3 recuperat utilitza per defecte --li-delivery-x3-spool-replay-policy=hold; purge el descarta de manera durable. Exporteu les identitats retingudes amb --li-delivery-x3-spool-export-manifest, reviseu-les i proporcioneu una aprovació exacta de versió 2 amb --li-delivery-x3-spool-replay-manifest. L’aprovació requereix una activació de tasca i una destinació actualment conciliades i sense canvis, instàncies coincidents d’estat i diari, la data límit original i la identitat del contingut. La reproducció envia els bytes codificats i els números de seqüència originals. Una escriptura local reeixida no demostra la recepció pel MDF, de manera que una escriptura interrompuda pot provocar un lliurament duplicat. Vegeu el procediment de lliurament històric per a detalls de conciliació, aprovació i recuperació.

lc show status exposa comptadors independents de diaris X2 i X3, bytes assignats, límits, comptadors de caducitat/revocació i codis fixos d’error d’emmagatzematge. La incertesa de confirmació d’emmagatzematge i la incertesa d’escriptura de transport són resultats diferents.

Hi ha límits independents de PDU amb --li-delivery-x2-queue-size i --li-delivery-x3-queue-size; cadascun té zero per defecte i hereta el límit antic --li-delivery-queue-size. physical_queue_bytes compta una vegada les dades útils codificades compartides, mentre que queue_bytes compta cada còpia de destinació.