การกำหนดค่าเมื่อมองแวบแรกดูสมเหตุสมผล:

acl team_a myportname 3128 src 198.51.100.0/24

แต่นิยาม ACL มีได้เพียงประเภทเดียว ที่นี่ myportname คือประเภท การเพิ่มคำว่า src ไม่ได้เริ่มการทดสอบที่สอง คำที่เหลืออยู่ในรายการค่าของประเภทแรก บรรทัดนั้นไม่ได้สื่อถึง “listener นี้และเครือข่ายไคลเอนต์นี้”

ตั้งชื่อให้แต่ละเงื่อนไข

ใช้ชื่อสำหรับ socket ที่รอรับ และใช้ ACL ต้นทางแยกต่างหาก ตัวอย่างนี้ใช้ที่อยู่สำหรับเอกสาร ซึ่งต้องแทนที่ด้วยที่อยู่ที่เหมาะกับการปรับใช้:

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

วางกฎอนุญาตหลังการป้องกันที่มีอยู่สำหรับพอร์ตปลายทางที่ไม่ปลอดภัย เป้าหมาย CONNECT ที่จำกัด และการเข้าถึงเพื่อบริหารจัดการ ตัวอย่างนี้แสดงเงื่อนไขไคลเอนต์/listener ไม่ได้แทนที่การป้องกันเหล่านั้น

เงื่อนไขในบรรทัด http_access เดียวกันรวมกันด้วย AND หากแยกเป็นสองบรรทัดอนุญาต แต่ละเงื่อนไขจะผ่านได้อย่างอิสระ ซึ่งจะเปลี่ยนนโยบายอย่างมาก ค่าหลายค่าใน ACL เดียวมักจะให้ทางเลือกสำหรับการทดสอบครั้งเดียวนั้น

เลือกทางออกแยกต่างหาก

listener ที่ตรงกันยังใช้โดย tcp_outgoing_address เพื่อ เลือกที่อยู่ต้นทางภายใน ได้ด้วย นั่นคือการเลือกเส้นทาง ไม่ใช่การอนุญาตให้ใช้พร็อกซี กฎที่อยู่ขาออกไม่สามารถทำให้คำขอที่ถูกปฏิเสธผ่าน http_access ได้

หากการกำหนดค่าที่มีหลายที่อยู่หยุดทำงานหลังการอัปเกรด ให้แยกหลักฐาน: ข้อผิดพลาดในการแยกวิเคราะห์ชี้ไปที่ไวยากรณ์ของการกำหนดค่า การปฏิเสธการเข้าถึงชี้ไปที่การจับคู่กฎ คำขอที่ได้รับอนุญาตแต่ทางออกผิดชี้ไปที่การเลือกทางออกหรือ NAT ภายหลัง การเปลี่ยนทั้งสามอย่างพร้อมกันทำให้ข้อผิดพลาด ACL เล็ก ๆ หาได้ยากขึ้นมาก

บทความที่เกี่ยวข้อง