Squids cachning av externa ACL: varför hjälparen inte anropas varje gång
Designa Squids externa ACL-hjälpare kring beständiga processer, cachenycklar för beslut och ett uttryckligt krav på auktoriseringens färskhet.
En hjälpare som loggar en förfrågan och sedan tystnar kan vara normalt. Squid kan utvärdera en regel med ett cachat externt ACL-resultat utan att skicka hjälparen ännu en fråga.
Definiera först det återanvändbara beslutet. ”Får det här kontot använda proxyn?” kräver andra indata än ”Kan det här kontot nå den här destinationen?” Det utökade externa ACL-formatet bildar cachenyckeln. Om hjälparen beslutar efter användarnamn och destination men nyckeln bara innehåller användarnamnet, kan ett cachat godkännande gälla bredare än avsett. Ta med varje indata som ändrar svaret och undvik detaljer som bara splittrar likvärdiga beslut.
Välj sedan färskhet. Positiva ttl och negative_ttl styr matchande och icke-matchande resultat; grace kan starta en uppdatering innan en post löper ut. Bestäm hur länge ett återkallat kontos cachade godkännande får påverka senare beslut. Ingen av dessa inställningar auktoriserar en etablerad CONNECT-tunnel på nytt för varje byte eller intern HTTPS-förfrågan. Om hjälparen tillämpar en trafikkvot kan tillåtna överföringar fortsätta efter att saldot ändras.
Hjälparen är en beständig protokolldeltagare, inte nödvändigtvis en ny skriptprocess för varje förfrågan. Håll den redo för på varandra följande frågerader och skicka varje svar snabbt. Lägg diagnostik på en annan kanal. När samtidighet är aktiverad, returnera motsvarande angivna kanalidentifierare.
Definiera slutligen långsamma, otillgängliga och interna felutfall, och låt den omgivande ACL-ordningen producera dem. Designen är komplett när både specificiteten och den tillåtna åldern för ett återanvändbart svar matchar åtkomstkravet.