Պահանջեք և՛ Squid մուտք, և՛ ճիշտ հաճախորդի IP

Ճիշտ գաղտնաբառը այս քաղաքականության միայն կեսն է. հաշիվը պետք է աշխատի նաև մեկ հաստատված հաճախորդի հասցեից։ Squid-ում երկու ստուգումները նույն մուտքի կանոնի վրա դնելը տարբերությունն է այդ պահանջի և երկու առանձին մուտքի ուղիների միջև։

Ենթադրելով, որ նույնականացումն արդեն կարգավորված է, օրինակ՝ Squid 6.13 NCSA կարգավորումը, հիմնական քաղաքականությունը հետևյալն է.

acl approved_login proxy_auth alex
acl approved_source src 192.0.2.40/32
http_access allow approved_source approved_login
http_access deny all

Օգտագործեք այն աղբյուրը, որը Squid-ը իրականում ստանում է; օրինակը փաստաթղթային հասցե է։ Պահպանեք նախկին պաշտպանությունները անապահով նպատակակետ պորտերի, տեղական ծառայությունների և CONNECT երթևեկության համար։ Այս հատվածը ցույց է տալիս համակցված պայմանը, ոչ թե ամբողջական լսողի կարգավորում։

Ստուգեք դրա վերևի կանոնները

Ավելի վաղ լայն թույլտվությունը կարող է ընդունել հարցումը մինչև նոր պայմանին հասնելը։ http_access տեղեկանքը նկարագրում է կարգավորված համապատասխանությունը։ Կարդացեք ամբողջ հաջորդականությունը՝ ներառյալ ներառված ֆայլերը։

Օգտանվան համար մեկ թույլտվություն և աղբյուրի համար մեկ այլ թույլտվություն չեն պահանջում երկուսն էլ։ Ցանկացած տող կարող է հաջողվել ինքնուրույն։ Դա այլ քաղաքականություն է։

proxy_auth ACL-ը կախված է նույնականացման օժանդակ ծրագրից։ Այն սահմանելը չէ, թե ինչպես ստեղծել օգտատիրոջը կամ վավերացնել գաղտնաբառը։ Այս օրինակը բացահայտ պրոքսիի համար է, որի հաճախորդները կարող են պատասխանել պրոքսի նույնականացման մարտահրավերներին։

Աղբյուրի ինքնությունը նույնպես սահմաններ ունի։ Մեկ NAT-ի հետևում գտնվող մարդիկ կարող են կիսել հասցեն, իսկ շարժվող նոթբուքը կարող է փոխել հասցեն։ Լրացուցիչ պայմանը նեղացնում է հաշվի օգտագործելի ցանցային դիրքը. այն հուսալիորեն չի նույնականացնում ֆիզիկական համակարգիչ։ Համոզվեք, որ այդ սահմանափակումը համապատասխանում է այն պատճառին, թե ինչու եք պայմանը սկզբում ավելացրել։