Client Squid IPv4 e destinazioni IPv6: politiche separate

È possibile accettare un client su IPv4 e raggiungere il sito web richiesto su IPv6. Si tratta di connessioni separate. Una politica sul lato sito web non dovrebbe rifiutare automaticamente i client IPv4.

Questa è la trappola negli esempi che combinano un rifiuto della famiglia di destinazione con src ipv4: l'ACL di origine cambia chi può connettersi, non solo quali connessioni ai siti web sono consentite.

Definire la restrizione prevista

Per le versioni di Squid che supportano le ACL IP pertinenti, una regola della famiglia di destinazione può usare dst ipv4 per identificare le destinazioni IPv4. Integra tali regole con l'autenticazione e le autorizzazioni di destinazione esistenti; non aggiungere un'ampia autorizzazione IPv6 che le aggiri.

Il riferimento ACL distingue i tipi di origine e destinazione. Questa è una restrizione, non un servizio di traduzione automatica. Un sito web solo IPv4 può diventare irraggiungibile anche se la macchina potrebbe raggiungerlo via IPv4.

Anche associare un indirizzo IPv6 in uscita non è l'intera politica di applicazione. La selezione dell'origine, le famiglie di destinazione consentite, le risposte DNS e la raggiungibilità reale della rete contribuiscono tutte. Decidi esplicitamente se il fallback IPv4 è accettabile.

Modificare forwarded_for non risolve questo problema. Influisce su un'intestazione HTTP, non sulla famiglia di indirizzi della connessione TCP del proxy. Allo stesso modo, un resolver DNS IPv6 non garantisce che ogni nome a cui risponde abbia una destinazione IPv6.

Verifica il comportamento specifico della versione prima di adottare una grande configurazione obsoleta. In particolare: dns_v4_first non è un interruttore di preferenza della famiglia supportato in Squid 5-7. Una politica che puoi descrivere con precisione è più facile da convalidare di un insieme di impostazioni IPv6 non correlate.