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

Eksplicitno konfigurisan preglednik namjerno šalje zahtjeve na proxy. Ta veza ne dobija historiju NAT presretanja samo zato što uz port Squidovog prijemnika 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 konfigurisanu adresu proxyja, odredite uobičajeni prijemnik za prosljeđujući proxy koji treba koristiti.
  • Ako gateway preusmjerava inače direktan saobraćaj, provjerite da li stiže do predviđenog presretačkog prijemnika i da li podržani NAT dizajn čuva potrebne podatke o odredištu.
  • Ako postoje oba načina, provjerite koju adresu i port je klijent koji ne uspijeva zaista kontaktirao.

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

Zatim sigurnost prijenosa tretirajte odvojeno. HTTP proxy može prenositi HTTPS putem CONNECT. TLS veza prema proxyju zahtijeva kompatibilan prijemnik i konfiguraciju klijenta. Dešifriranje saobraćaja prema odredištu je opet zasebna opciona mogućnost.

Ne kopirajte staro “HTTPS rješenje” koje uključuje generisanje certifikata samo zato što URL odredišta počinje s HTTPS. Prvo popravite usklađenost klijenta i prijemnika. Ako nakon toga ostane stvarna TLS greška, ona će biti korisnija za istraživanje.

Povezani članci