გაგზავნეთ Squid მოთხოვნები ზედა პროქსით

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-მა ზედა პროქსი გამოიყენა თუ პირდაპირი გზა.

მომსახურების ტესტში ზედა პროქსი მიუწვდომელი გახადეთ და იგივე უქეშო მოთხოვნა გაიმეორეთ. თუ პოლიტიკა პირდაპირ გადაცემას კრძალავს, ტრანზაქცია უნდა ჩავარდეს და არა სხვა გზით მიაღწიოს საწყის სერვერს. გააკეთეთ მხოლოდ თქვენს კონტროლქვეშ მყოფ სერვისებზე და შემდეგ სასურველი კონფიგურაცია აღადგინეთ.