A myportname és a src összekapcsolása a Squidban külön ACL-ekkel

A konfiguráció első ránézésre hihetőnek tűnik:

acl team_a myportname 3128 src 198.51.100.0/24

De egy ACL-definíciónak egyetlen típusa van. Itt a myportname a típus; a src szó hozzáadása nem indít második vizsgálatot. A többi szó az első típus értéklistájához tartozik. Az a sor nem azt fejezi ki, hogy „ez a listener és ez a klienshálózat”.

Adjon nevet minden feltételnek

Használjon nevet a figyelő sockethez és külön forrás-ACL-t. Ez a részlet dokumentációs címeket használ, amelyeket a telepítéshez illő címekre kell cserélni:

http_port 192.0.2.10:3128 name=team_a_port
acl team_a_port myportname team_a_port
acl team_a_clients src 198.51.100.0/24

http_access allow team_a_port team_a_clients
http_access deny all

Az engedélyező szabályt a nem biztonságos célportok, a korlátozott CONNECT-célok és a felügyeleti hozzáférés meglévő védelmei után helyezze el. A részlet a kliens/listener feltételt szemlélteti; nem helyettesíti ezeket a védelmeket.

Az egy http_access sorban lévő feltételek AND-del kapcsolódnak össze. Két külön engedélyező sor bármelyik feltételt önállóan beengedné, ami jelentősen megváltoztatná a szabályzatot. Egy ACL-en belül több érték általában alternatívákat kínál arra az egyetlen vizsgálatra.

A kimenetet külön válassza ki

Egy illeszkedő listener a tcp_outgoing_address segítségével is használható helyi forráscím kiválasztására. Ez útvonalválasztás, nem a proxy használatának engedélye. A kimenő címre vonatkozó szabály nem tudja átengedni az elutasított kérést a http_access szabályon.

Ha egy többcímes konfiguráció frissítés után leáll, válassza szét a bizonyítékokat: az elemzési hiba a konfiguráció szintaxisára utal; a hozzáférés megtagadása a szabályok egyezésére; az engedélyezett kérés rossz kimenettel a kimenetválasztásra vagy egy későbbi NAT-ra. Mindhárom egyszerre történő módosítása sokkal nehezebbé teszi egy apró ACL-hiba megtalálását.