Seguire un pacchetto TPROXY fino al socket
Verificate il socket ricevente, il mark del pacchetto e la rotta di policy locale come un unico percorso di consegna del proxy trasparente.
Un contatore TPROXY può aumentare mentre l'applicazione non riceve nulla. La regola ha corrisposto, ma la consegna locale dipende ancora dall'instradamento policy e da un socket ricevente compatibile.
TPROXY su Linux può intercettare il traffico senza riscrivere la destinazione come fa DNAT. I pacchetti indirizzati a una destinazione non locale devono quindi raggiungere un socket locale idoneo.
Seguite il percorso di consegna
- Il traffico raggiunge l'host di intercettazione sull'interfaccia e sulla famiglia di indirizzi previste.
- La regola di intercettazione e il mark del pacchetto identificano la policy di consegna locale.
- Una regola di policy corrispondente sceglie una rotta che consegna i pacchetti localmente.
- Il proxy usa un listener trasparente supportato con l'opzione socket richiesta.
L'esempio IPv4 del kernel richiede il supporto dell'applicazione per IP_TRANSPARENT. Un listener normale sulla stessa porta, o un'impostazione globale di binding non locale, non dimostra quel supporto.
| Osservazione | Controllo successivo |
|---|---|
| Nessun pacchetto in ingresso pertinente | Percorso del traffico e interfaccia di ingresso |
| I pacchetti arrivano; il contatore di intercettazione resta fermo | Famiglia di indirizzi, catena e condizioni di corrispondenza |
| La regola corrisponde; la consegna locale fallisce | Mark e scelta della rotta di policy |
| Il socket ascolta; l'applicazione non vede nulla | Capacità del socket trasparente e proprietario del listener |
| La richiesta inizia; le risposte successive falliscono | Corrispondenza del socket stabilito e rotte di ritorno |
Conservate la configurazione caricata e il namespace di rete con ogni osservazione. Una regola successiva può sovrascrivere un mark o scegliere un'altra rotta. Se l'intercettazione avviene sull'host mentre il listener gira in un container, una rotta locale valida dell'host non consegna automaticamente in quel container.
Tenete conto dei pacchetti successivi
L'esempio del kernel include la corrispondenza del socket e un percorso DIVERT che marca i pacchetti dei socket trasparenti. Ometterlo può lasciare il traffico successivo su un altro percorso anche quando l'intercettazione iniziale riesce.
Usate la modalità trasparente supportata dall'applicazione e la documentazione del kernel corrispondente per ogni famiglia di indirizzi. Un comando di rotta locale IPv4 non configura IPv6, e il supporto in una famiglia non dimostra il comportamento del socket dell'altra.
TPROXY non genera nemmeno la negoziazione SOCKS. Un componente da trasparente a SOCKS deve comunque scoprire la destinazione e negoziare con il proprio upstream.
Passare da REDIRECT
Annotate come l'applicazione esistente ottiene la destinazione originale. REDIRECT cambia la destinazione e si affida al meccanismo di recupero adatto; TPROXY ha bisogno del suo socket trasparente e della disposizione di instradamento. Scegliete in base all'applicazione e alla policy dell'indirizzo di origine.
Abbinate i contatori alla rotta scelta, alla capacità del socket e al log dell'applicazione prima di cambiare modalità di intercettazione. Su una distribuzione che fornisce i mezzi necessari, un passo di consegna mancante è un punto di partenza migliore di una ricompilazione del kernel.