Apache AllowCONNECT en HTTPS-bestemmingspoorte

Jou Apache-proxy luister op poort 3128. 'n Kliënt bereik dit suksesvol, maar 'n HTTPS-diens op poort 8443 misluk. Om die proxy se luisterpoort te verander sal waarskynlik nie daardie spesifieke onderskeid aanspreek nie.

Die kliënt verbind eers met die proxy-luisteraar. Sy CONNECT-versoek noem dan 'n aparte bestemmingshost en -poort. Apache kan die eerste verbinding aanvaar en die tweede bewerking verwerp.

Lees AllowCONNECT as 'n bestemmingsbeleid

Vir Apache 2.4 hanteer mod_proxy_connect inkomende CONNECT-versoeke. Sy AllowCONNECT-richtlijn beheer die bestemmingspoorte wat vir daardie versoeke beskikbaar is. Die gedokumenteerde verstek is 443 en 563.

AllowCONNECT 443 8443

Hierdie voorbeeld kies daardie twee bestemmingspoorte. Dit vervang die verstekkeuse; dit voeg nie 8443 by terwyl elke verstekpoort stilswyend behou word nie. Gebruik die richtlijn in die toepaslike bediener- of virtuele-gasheer-konfigurasie.

Hou die proxy se kliëntmagtigingsreëls in plek. 'n Toegelate bestemmingspoort sê niks oor watter kliënt die diens mag gebruik nie, en dit is nie 'n plaasvervanger vir 'n bestemmingshost-beperking wanneer een nodig is nie.

'n Tru-proxy-voorbeeld beantwoord 'n ander vraag

Soekresultate vir Apache en HTTPS wys dikwels 'n openbare webwerf wat na 'n vaste backend aanstuur. Daardie konfigurasie is nie hoe 'n blaaier 'n voorsieningsproxy vra om 'n CONNECT-tonnel na 'n gekose webwerf oop te maak nie. Om sy roeteringsrichtlyne te kopieer kan die oorspronklike proxyprobleem onaangeraak laat.

Wanneer jy 'n fout diagnoseer, teken die luisteraar wat die kliënt bereik het, die CONNECT-outoriteit wat dit aangevra het, en die proxy se antwoord aan. As CONNECT slaag en TLS daarna misluk, het die bestemmingspoorttoestemming reeds sy deel gedoen. Gaan voort met die TLS-fout eerder as om AllowCONNECT herhaaldelik te verbreed.