Un servizio è in ascolto su 127.0.0.1:1080. Una regola DNAT indirizza il traffico in ingresso a quell'indirizzo, eppure la connessione fallisce. Il servizio può essere sano e la regola NAT può corrispondere: gli indirizzi di loopback IPv4 ricevono un trattamento di routing speciale.

Il parametro route_localnet di Linux stabilisce se gli indirizzi 127/8 sono trattati come indirizzi marziani durante il routing. Il valore predefinito conserva il consueto confine del loopback. Un'eccezione specifica per un'interfaccia può essere rilevante per una progettazione deliberata di reindirizzamento locale.

Questo spiega perché una regola funzionante su un'altra macchina può dipendere da un sysctl che non avete copiato. Non giustifica però l'abilitazione dell'opzione ovunque.

L'assunzione di sicurezza cambia con la rotta

Il binding sul loopback è spesso usato perché un ausiliario non ha un'autenticazione client indipendente. Se il traffico proveniente da un'altra interfaccia può essere instradato lì, il solo indirizzo di binding non descrive più il pubblico raggiungibile. Limitate le sorgenti in ingresso, la destinazione e la porta nel set di regole effettivo, incluso il traffico che dichiara indirizzi di origine o destinazione di loopback dove pertinente.

Esaminate il namespace di rete che contiene il servizio. Il loopback di un container non è quello dell'host, e modificare un'impostazione dell'interfaccia dell'host non crea automaticamente un listener nel container.

rp_filter risponde a una domanda diversa sulla validazione del percorso di origine. Disattivarlo globalmente non è un sostituto generale della comprensione del routing di loopback. Allo stesso modo, ip_nonlocal_bind riguarda il binding dei socket a indirizzi non locali, non il rendere corretto questo percorso DNAT.

Infine, il protocollo reindirizzato deve adattarsi al listener. Inviare traffico HTTP o TLS grezzo a una porta SOCKS richiede comunque un traduttore; un'eccezione di routing non può fornire la negoziazione mancante.

Articoli correlati