Squid IPv4 հաճախորդներ և IPv6 նպատակակետեր՝ առանձին քաղաքականություններ

Հնարավոր է հաճախորդ ընդունել IPv4-ով և նրա պահանջած կայքին հասնել IPv6-ով։ Դրանք առանձին միացումներ են։ Կայքի կողմի քաղաքականությունը չպետք է ինքնաբերաբար մերժի IPv4 հաճախորդներին։

Սա է այն թակարդը օրինակներում, որոնք նպատակակետի ընտանիքի արգելքը միավորում են src ipv4-ի հետ․ աղբյուրի ACL-ը փոխում է, թե ով կարող է միանալ, ոչ միայն այն, թե որ կայքի միացումներն են թույլատրվում։

Սահմանեք նախատեսված սահմանափակումը

Համապատասխան IP ACL-ներն աջակցող Squid թողարկումների համար նպատակակետի ընտանիքի կանոնը կարող է օգտագործել dst ipv4՝ IPv4 նպատակակետերը նույնականացնելու համար։ Նման կանոնները ինտեգրեք գոյություն ունեցող նույնականացման և նպատակակետի թույլտվությունների հետ․ չավելացնեք լայն IPv6 թույլտվություն, որը շրջանցում է դրանք։

ACL հղումը տարբերակում է աղբյուրի և նպատակակետի տեսակները։ Սա սահմանափակում է, ոչ թե ավտոմատ թարգմանության ծառայություն։ Միայն IPv4 կայքը կարող է անհասանելի դառնալ, թեև մեքենան կարող էր դրան հասնել IPv4-ով։

Ելքային IPv6 հասցեի կապումը նույնպես ամբողջ կատարման քաղաքականությունը չէ։ Աղբյուրի ընտրությունը, թույլատրված նպատակակետի ընտանիքները, DNS պատասխանները և ցանցի իրական հասանելիությունը բոլորն էլ նպաստում են։ Հստակ որոշեք՝ արդյոք IPv4-ի վերադարձը ընդունելի է։

forwarded_for-ը փոխելը չի լուծում այս խնդիրը։ Դա ազդում է HTTP վերնագրի վրա, ոչ պրոքսիի TCP միացման հասցեների ընտանիքի վրա։ Նույն կերպ, IPv6 DNS լուծիչը չի երաշխավորում, որ իր պատասխանած յուրաքանչյուր անուն ունի IPv6 նպատակակետ։

Նախքան մեծ հին կոնֆիգուրացիա ընդունելը ստուգեք թողարկմանը հատուկ վարքը։ Մասնավորապես․ dns_v4_first-ը Squid 5-ից 7-ում աջակցվող ընտանիքի նախընտրության անջատիչ չէ։ Քաղաքականությունը, որը կարող եք ճշգրիտ նկարագրել, ավելի հեշտ է վավերացնել, քան անկապ IPv6 կարգավորումների հավաքածուն։