Egy Squid allow szabály AND-et jelent; kettő OR-t is jelenthet
Olvassa el a Squid ACL-kombinációkat és a sorrendbe állított hozzáférési szabályokat, hogy a privát proxy csak a szándékolt hozzáférést adja.
Olvassa fel ezt a szabályzatot: engedje, hogy az irodai hálózat a proxyt a jóváhagyott célra használja. Ha ezek a feltételek összetartoznak, tartsa őket együtt a szabályban.
http_access allow office_clients approved_destination
Mindkét ACL-nek egyeznie kell ahhoz, hogy az a sor engedélyezze a kérést. A kettéválasztása megváltoztatja a szabályzatot:
http_access allow office_clients
http_access allow approved_destination
Az irodai kliensek most a célkorlátozás nélkül engedélyezhetők, a cél felé irányuló kérések pedig az irodai korlátozás nélkül, kivéve ha egy korábbi szabály elutasította őket. Két sor nem egy sor olvashatóbb írásmódja.
A sorrend a szabályzat része
A Squid sorban értékeli a hozzáférési szabályokat. Az első egyező döntés irányítja a kérést. Egy korábbi allow all hatástalanít egy későbbi gondos korlátozást; egy korábbi egyező elutasítás megakadályozza egy későbbi engedély elérését.
A http_access dokumentációja magyarázza ezt a sorrendet. Tartson szándékos záró elutasítást ahelyett, hogy arra számítana, az olvasó emlékszik az implicit alapértelmezett viselkedésre.
Sok ACL-definíciónak más az OR-kapcsolata: egy nevesített forrás-ACL több engedélyezett tartományt is felsorolhat. Ez nem teszi a forrás és a cél azonosságát ugyanazzá az ACL-típussá. Külön definiálja őket, majd kombinálja a neveket egy hozzáférési döntésben.
Privát kijáratnál ez befolyásolja, ki használhatja a kifelé irányuló IP-címet. Vegyen négy esetet: jóváhagyott kliens a jóváhagyott célra, jóváhagyott kliens máshová, másik kliens a jóváhagyott célra, és másik kliens máshová. Ha a szabályok több esetet engedélyeznek, mint a szabályzat szándékozik, javítsa a logikát, mielőtt kiszélesíti a figyelőt. Egy szintaktikailag érvényes konfiguráció még mindig rossz jogosultságokat fejezhet ki.