Permesu unu plian HTTPS-pordon tra Squid

Ĝisdatigu ambaŭ pordajn ACL-ojn en Squid 6.13 kaj tenu la celregulon limigita kiam aprobita HTTPS-servo uzas pordon 8443.

HTTPS-servo ĉe pordo 8443 povas malsukcesi tra ĝuste agordita Squid-prokurilo, eĉ kiam ordinara HTTPS ĉe 443 funkcias. Ekzamenu la rifuzon de CONNECT kaj la politikon pri celpordoj antaŭ ol ŝanĝi la prokurilan protokolon de la kliento.

En tipa alirpolitiko de Squid 6.13 gravas du kontroloj: la celo devas trapasi Safe_ports, kaj CONNECT devas trapasi SSL_ports. Aldoni la pordon al nur unu ACL povas lasi la alian rifuzon valida.

Etendu la ekzistantajn difinojn pripensite

Por politiko permesanta ordinarajn retajn pordojn kaj unu plian HTTPS-pordon:

acl Safe_ports port 80 443 8443
acl SSL_ports port 443 8443

Anstataŭigu aŭ redaktu la koncernajn difinojn por ne lasi neatenditan malnovan aron da valoroj. Konservu la kutimajn regulojn pri rifuzo de nesekuraj pordoj kaj CONNECT, kaj ankaŭ la celitajn klientajn limigojn.

Tenu la escepton limigita

Se la plia pordo estas bezonata nur por unu regata celo, aldonu celitan rifuzon antaŭ la regulo permesanta la klienton:

acl extra_tls_port port 8443
acl approved_tls_target dst 203.0.113.20/32
http_access deny CONNECT extra_tls_port !approved_tls_target

La adreso estas ekzempla valoro por dokumentado. Uzu la celon, kiun vi administras aŭ kiun vi rajtas aliri, kaj konsideru efektivajn ŝanĝojn de ĝia adreso. Tio limigas la escepton por la plia pordo anstataŭ permesi ĉiun celon ĉe 8443.

Analizigu la tutan aktivan agordon kaj reviziu la ordon de la reguloj. Ĝuste skribita rifuzo metita post kongrua regulo permesanta la klienton ne donos la celitan limigon.

Testu la aprobitan gastignomon kun ĝiaj efektivaj atestilo kaj pordo, poste testu regatan celon, kiu devas resti rifuzita. Lasi TLS-kontroladon ŝaltita ebligas distingi erarojn pri la identeco de la celo de eraroj en la prokurila politiko. Ne forigu la tutan CONNECT-protekton por funkciigi unu peton al propra pordo.

Rilataj artikoloj