TLS გადამგზავნი პროქსის მსმენელი Squid 6.13-ში

დაამატეთ Squid 6.13-ს TLS გადამგზავნი პროქსის მსმენელი დანიშნულების HTTPS სესიაში ჩარევის გარეშე.

GnuTLS-ით ან OpenSSL-ით აგებულ Squid 6.13-ს TLS-ით გადამგზავნი პროქსის მოთხოვნების მიღება შეუძლია. ეს კლიენტ–პროქსის კავშირს იცავს HTTPS დანიშნულების ცალკე სესიაში ჩარევის გარეშე.

  1. მიიღეთ სერტიფიკატი იმ ჰოსტის სახელისთვის, რომლითაც კლიენტები Squid-ს მიაღწევენ. პირადი გასაღები მხოლოდ საჭირო სერვისის იდენტობებისთვის გახადეთ ხელმისაწვდომი.
  2. დაამატეთ TLS მსმენელი თქვენთვის გამოყოფილი მისამართითა და სერტიფიკატების რეალური გზებით:
https_port 192.0.2.10:3129 tls-cert=/etc/squid/proxy-chain.pem tls-key=/etc/squid/proxy-key.pem

შეინარჩუნეთ კლიენტების დაშვების სია და დანიშნულების შეზღუდვები და ავთენტიფიკაციის პოლიტიკა. მსმენელი წვდომას არ ანიჭებს. არსებული http_port ასევე აქტიური რჩება; წაშალეთ ან შეზღუდეთ ძველი მსმენელი, თუ კლიენტის ყველა კავშირი TLS-ს უნდა იყენებდეს. ამაჩქარებლის, ჩაჭრის ან სერტიფიკატის შექმნის რეჟიმი არ არის საჭირო.

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

curl --proxy https://proxy.example:3129 --proxy-cacert approved-proxy-ca.pem --connect-timeout 5 --max-time 15 https://example.com/

გამოიყენეთ რეალური პროქსის ჰოსტის სახელი და დამტკიცებული CA ფაილი. საჯაროდ სანდო პროქსის სერტიფიკატს შესაძლოა საკუთარი ნაკრები არ სჭირდებოდეს. --proxy-cacert პროქსის ნდობას ადგენს და დანიშნულების შემოწმებას ცალკე ტოვებს; შეინარჩუნეთ ორივე შემოწმება.

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

დაკავშირებული სტატიები