NF getsockopt(SO_ORIGINAL_DST) upućuje na traženje izvornog odredišta. U postavci presretanja Squid mora obnoviti kamo je preusmjerena veza prvotno išla.

Izričito konfiguriran preglednik namjerno šalje zahtjeve proxyju. Ta veza ne dobiva povijest NAT presretanja samo zato što uz port Squidova slušatelja piše intercept.

Zato ovaj nesklad može propasti prije nego što certifikat odredišta postane relevantan.

Počnite od toga kako je veza stigla

  • Ako aplikacija ima konfiguriranu adresu proxyja, odredite uobičajenog slušatelja prosljeđujućeg proxyja koji treba koristiti.
  • Ako gateway preusmjerava inače izravan promet, provjerite stiže li do predviđenog presretačkog slušatelja i čuva li podržani NAT dizajn potrebne podatke o odredištu.
  • Ako postoje oba načina, provjerite koju je adresu i port klijent koji ne uspijeva stvarno kontaktirao.

Squidova dokumentacija za http_port jasno razlikuje: izostavljanje oznake načina odabire način prosljeđujućeg proxyja; intercept očekuje NAT presretanje na IP sloju.

Zatim sigurnost prijenosa obradite odvojeno. HTTP proxy može prenositi HTTPS putem CONNECT. TLS veza prema proxyju zahtijeva kompatibilan slušatelj i konfiguraciju klijenta. Dešifriranje prometa prema odredištu opet je zasebna neobavezna mogućnost.

Ne kopirajte staro “HTTPS rješenje” koje uključuje generiranje certifikata samo zato što URL odredišta počinje s HTTPS. Najprije popravite usklađenost klijenta i slušatelja. Ako nakon toga ostane stvarna TLS pogreška, bit će korisnija za istraživanje.

Povezani članci