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.

Kapcsolódó cikkek