Squid 6.13 kan ta imot forwardproxyførespurnader over TLS når det er bygd med GnuTLS eller OpenSSL. Dette vernar klient–proxy-lenka utan å avskjere den separate økta til HTTPS-målet.

  1. Skaff eit sertifikat for vertsnamnet klientane skal bruke for å nå Squid. Avgrens den private nøkkelen til tenesteidentitetane som treng han.
  2. Legg til ein TLS-lyttar med den tildelte adressa og dei verkelege sertifikatstiane:
https_port 192.0.2.10:3129 tls-cert=/etc/squid/proxy-chain.pem tls-key=/etc/squid/proxy-key.pem

Hald på tillatingslista for klientar og målavgrensingane og autentiseringspolicyen. Lyttaren gjev ikkje tilgang. Ein eksisterande http_port er òg framleis aktiv; fjern eller avgrens den eldre lyttaren dersom alle klientsamband må bruke TLS. Ingen akselerator-, avskjerings- eller sertifikatgenereringsmodus er naudsynt.

Pars konfigurasjonen før du lastar den tiltenkte tenesta på nytt. Parserkontrollen validerer struktur og sertifikatinnlasting, ikkje nettverkstilgjenge. Send etter vellukka omlasting ein førespurnad gjennom TLS-endepunktet frå ein tillaten klient:

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

Bruk det verkelege vertsnamnet til proxyen og den godkjende CA-fila. Eit offentleg tiltrudd proxysertifikat treng kanskje ingen eigen pakke. --proxy-cacert konfigurerer proxytillit og held målverifiseringa åtskild; hald på begge kontrollane.

Undersøk den faktiske lyttaren og sertifikatnamnet, og test òg ei kontrollert kjelde som skal avvisast. Vellukka parsing åleine slår ikkje fast klienttillit eller tilgangsgrensa.

Relaterte artiklar