Listen, Bind e BindSame in Tinyproxy: quale indirizzo vince

Il proxy risponde, la richiesta si completa e, ciò nonostante, la destinazione registra ancora l’indirizzo della LAN. Nulla nel registro del proxy sembra sbagliato, e la riga che avete modificato è proprio quella che la documentazione vi ha detto di cambiare. Su un host con indirizzo LAN e indirizzo del tunnel, tre direttive decidono quale indirizzo compare dove, e solo una riguarda il lato in uscita. Leggerle nell’ordine sbagliato vi porta nella tabella di routing senza motivo.

Il sintomo: la destinazione vede l’indirizzo della LAN

Un client si connette al proxy sull’indirizzo della LAN, e il proxy apre la propria connessione verso la destinazione. Questa seconda connessione sceglie un indirizzo sorgente secondo le regole del kernel e, per impostazione predefinita, è quello selezionato dalla ricerca di rotta. La destinazione registra quindi l’indirizzo primario dell’host anche se ogni byte è passato dal proxy. Sul piano dell’inoltro non c’è nulla di rotto, ed è per questo che il registro del proxy non ha nulla da dire.

L’immagine speculare di questo guasto è più facile da notare: fissate la sorgente in uscita sull’indirizzo del tunnel e i client della LAN smettono del tutto di raggiungere l’ascoltatore. Quella versione si annuncia da sola, mentre la prima si nasconde dietro una richiesta che funziona. Entrambe nascono dal trattare una direttiva come se rispondesse alle due domande.

Tre direttive, tre indirizzi diversi

Listen nomina l’indirizzo locale che accetta i client del proxy. Bind fornisce un indirizzo sorgente per le connessioni che il proxy apre verso l’esterno, e BindSame gli dice di riutilizzare l’indirizzo locale della connessione appena accettata. Sono tre domande separate, e una sola riga ne risolve una. Confonderle è la ragione abituale per cui una modifica sembra non fare nulla.

Leggete la configurazione commentata fornita con la versione installata, perché i valori predefiniti e la sintassi accettata cambiano tra le release. La configurazione di esempio del progetto documenta ogni direttiva accanto alle altre. Confrontate quel file con quello sul disco, non con una guida scritta per un’altra distribuzione.

Impostate l’ascoltatore e la sorgente in uscita separatamente

Prendete un host con indirizzo LAN 192.168.50.10 e indirizzo del tunnel 10.90.0.3. Se i client della LAN devono raggiungere il proxy mentre le loro richieste escono dal tunnel, sono due decisioni indipendenti e vanno scritte entrambe. Il frammento seguente esprime esattamente questo e nulla di più.

Listen 192.168.50.10
Bind 10.90.0.3
BindSame no

Non è una configurazione completa, quindi conservate la porta approvata, l’autenticazione, i controlli di accesso dei client e le restrizioni di destinazione. Entrambi gli indirizzi devono appartenere a questo host nello spazio dei nomi di rete di Tinyproxy, perché un valore Bind che il processo non può possedere fallisce alla connessione, non all’avvio. BindSame yes descrive un’altra politica, in cui l’indirizzo locale della connessione accettata diventa la sorgente in uscita. Nelle release attuali quel ramo ha la precedenza sull’elenco Bind, ed è così che una sorgente configurata sparisce senza errori.

Verificate la rotta che la sorgente implica

Scegliere un indirizzo sorgente non crea un percorso, quindi chiedete al kernel cosa farebbe con quella sorgente e quella destinazione. Una ricerca che nomina l’interfaccia del tunnel è la prova minima, e una che nomina l’interfaccia della LAN significa che la sorgente non può funzionare come scritto. La ricerca è contestuale: valuta le regole di policy e la tabella in vigore per quello spazio dei nomi. Non è una connessione e non dice nulla su ciò che un NAT più avanti presenterà al servizio.

ip -4 route get 203.0.113.25 from 10.90.0.3

Usate un indirizzo di documentazione nell’esempio e sostituite il servizio che siete autorizzati a provare. Eseguite la ricerca dentro lo spazio dei nomi del proxy quando il proxy gira in un container, perché le regole dell’host non sono quelle che vede il processo. Se la rotta del tunnel prevista manca, fate correggere dal proprietario della rete invece di aggiungere regole specifiche di destinazione sull’host del proxy. Non svuotate le rotte dell’host e non disattivate le rotte spinte dal server per far riuscire una ricerca, anche se una guida più vecchia lo faceva, perché tali modifiche spostano l’intero comportamento VPN approvato dell’host per riparare un solo percorso del proxy.

Confermate la sorgente alla destinazione

Leggete la sorgente dove arriva la richiesta, non dove parte. Il registro applicativo della destinazione, o il dispositivo di bordo davanti a essa, annota l’indirizzo che ha realmente visto, mentre il proxy può solo dirvi cosa intendeva fare. Fate una nuova richiesta attraverso l’ascoltatore previsto dopo la modifica, perché una connessione in cache non dimostra nulla sul nuovo incollaggio. Poi confrontate quell’indirizzo registrato con quello configurato.

ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sS

curl è solo il generatore di traffico; l’indirizzo che vale la pena verificare è quello registrato dal lato remoto, non il peer a cui curl si è collegato per caso. Se i due non coincidono, stabilite se la differenza viene dalla scelta della sorgente o da una traduzione più avanti, perché si correggono in punti diversi. Pianificate insieme i cambi di indirizzo e i riavvii del proxy, perché incollare un indirizzo che il tunnel non possiede più fallisce in silenzio dopo una riconnessione. Definite separatamente anche il comportamento di DNS e IPv6, perché il frammento IPv4 qui sopra non dimostra nulla su nessuno dei due.