Squid-ում վերադաս պրոքսիի հայտարարումն ինքնին չի նշանակում, որ ամեն փոխանցվող հարցում պարտադիր այն օգտագործի։ Եթե ուղիղ ուղին խախտում է քաղաքականությունը, հստակ սահմանեք այդ պահանջը և ստուգեք վերադասի անհասանելիության դեպքը։

Squid 6.13-ի այս օրինակը մեկ վերադաս է անվանում և արգելում ուղիղ փոխանցումն սկզբնաղբյուրին մեկ հաճախորդային աղբյուրի համար․

cache_peer 192.0.2.20 parent 3128 0 no-query default name=upstream
acl routed_client src 198.51.100.27/32
never_direct allow routed_client

Երկու հասցեներն էլ տեղապահեր են։ Վերահսկվող upstream փորձի համար, որտեղ հանրային HTTP վերադասները թույլատրված են, հասցեն ընտրեք HTTP պրոքսիների ցանկից։ Պահեք առանձին http_access քաղաքականությունը, որն ընդունում է միայն նախատեսված հաճախորդներին։ Երթուղավորման կանոնը հաճախորդին պրոքսի օգտագործելու իրավունք չի տալիս։

Ստուգեք առկա երթուղավորման կանոնները

no-query-ը անջատում է այս հանգույցի ICP հարցումները։ Զրոն հանգույցի հարցման պորտն է, ոչ թե HTTP լսողը։ Հաճախորդներին ուղղված լսողն ու դրա մուտքի կանոնները մնում են առանձին։

Բաժինը ավելացնելուց առաջ ստուգեք առկա always_direct կարգավորումներն ու հանգույցների այլ ընտրությունները։ always_direct-ում համընկնման մերժումն ինքնին վերադաս չի պարտադրում։ Հստակ never-direct կանոնն ընտրված հաճախորդի համար արտահայտում է այդ պահանջը։

Սա կառավարում է փոխանցման կարիք ունեցող գործարքները։ Տեղային քեշի պիտանի գրառումը կարող է տրվել առանց վերադասի հետ կապվելու։ Ուստի վերադասի նոր կապի բացակայությունն ինքնաբերաբար երթուղավորման խախտում չէ։

Ստուգեք ուղին և ձախողման վարքը

Օգտագործեք վերահսկվող նպատակակետ և համեմատեք մուտքի մատյանի հիերարխիայի տեղեկությունները նպատակակետի դիտարկումների հետ։ Միայն վերջնական HTTP կարգավիճակը չի ասում՝ Squid-ը վերադասն է օգտագործել, թե ուղիղ ուղին։

Սպասարկման փորձի ժամանակ վերադասը դարձրեք անհասանելի և կրկնեք նույն չքեշավորված հարցումը։ Եթե քաղաքականությունն արգելում է ուղիղ փոխանցումը, գործարքը պետք է ձախողվի, ոչ թե ուրիշ ուղիով հասնի սկզբնաղբյուրին։ Կատարեք միայն ձեր վերահսկած ծառայություններում և հետո վերականգնեք նախատեսված կարգավորումը։

Առնչվող հոդվածներ