Enviar peticións de Squid por un proxy pai

Declarar un pai en Squid non significa por si só que cada petición reenviada deba usalo. Se unha ruta directa vulnera a política, configura ese requisito explicitamente e proba que ocorre cando o pai non está dispoñible.

Para Squid 6.13, este exemplo nomea un pai e prohibe o reenvío directo á orixe para unha orixe de cliente:

cache_peer 192.0.2.20 parent 3128 0 no-query default name=upstream
acl routed_client src 198.51.100.27/32
never_direct allow routed_client

Ambos os enderezos son marcadores. Para unha proba upstream controlada onde se permitan pais HTTP públicos, escolle un enderezo da lista de proxies HTTP. Mantén a política http_access separada que só admite os clientes previstos. A regra de encamiñamento non autoriza un cliente a usar o proxy.

Comproba as regras de encamiñamento existentes

no-query desactiva as consultas ICP a este par. O cero é o porto de consulta do par, non o seu punto de escoita HTTP. O punto de escoita dos clientes e as súas regras de acceso seguen separados.

Revisa os axustes always_direct existentes e outras seleccións de pares antes de engadir o bloque. Denegar unha coincidencia en always_direct non obriga por si só a usar un pai. A regra explícita never-direct expresa ese requisito para o cliente elixido.

Isto rexe transaccións que necesitan reenvío. Unha entrada utilizable da caché local pode servirse sen contactar co pai, polo que a ausencia dunha nova conexión ao pai non é automaticamente unha infracción da ruta.

Comproba a ruta e o comportamento ante fallos

Usa un destino controlado e compara a información de xerarquía do rexistro de acceso coas observacións do destino. O estado HTTP final só non di se Squid usou o pai ou unha ruta directa.

Nunha proba de mantemento, deixa o pai indispoñible e repite a mesma petición sen caché. Se a política prohibe o reenvío directo, a transacción debe fallar en lugar de chegar á orixe por outra ruta. Faino só en servizos que controles e restaura despois a configuración prevista.