Squid PROXY-protokolo: fidu la sendanton antaŭ HTTP-aliro-kontroloj

Uzu proxy_protocol_access por fidi la relajson, kiu liveras la metadatenojn, ne por elekti permesitajn retejojn. En Squid 5–7 la kontrolo ruliĝas unufoje post la TCP-agordo ĉe require-proxy-header aŭskultanto, antaŭ ol la HTTP-petaj kapoj estas prilaboritaj:

acl trusted_relay src 192.0.2.20/32
http_port 3128 require-proxy-header
proxy_protocol_access allow trusted_relay
proxy_protocol_access deny all

Anstataŭigu la relajsan adreson de la ekzemplo kaj limigu retan aliron al ĉi tiu aŭskultanto. En ĉi tiu stadio Squid kontrolas la realan TCP-partneron antaŭ ol akcepti la liveritajn metadatenojn. Post akcepto, ĝi uzas la asertitan klientan adreson por la sekvaj ACL-kontroloj kaj protokolado. Fidi relajson surbaze de la klienta adreso, kiun ĝi asertas, inversigus tiun ordon.

Konservu http_access por la postaj permesoj pri klienta fonto kaj celo. Akcepti metadatenojn ne rajtigas aliron al retejoj, kaj ACL de celloka domajno ne povas respondi la pli fruan demandon pri fido al la sendanto.

La sendanto kaj la ricevanto devas interkonsenti pri subtenata versio de la PROXY-protokolo. Ordinara HTTP-kliento ne povas uzi ĉi tiun aŭskultanton kun deviga prefikso kiel ordinaran prokuran finpunkton. Se ambaŭ formoj necesas, uzu intence apartajn finpunktojn anstataŭ duobligi la saman aŭskultan adreson kaj pordon.

Fidinda relajso povas influi adres-bazitan rajtigon per la klienta identeco, kiun ĝi liveras. Donu tiun kapablon nur al la celata peranto.