Ako čítať chybu SO_ORIGINAL_DST v Squide
Overte, či sa explicitne nakonfigurovaný klient dostal k odpočúvaciemu listeneru, skôr než začnete riešiť zlyhanie hľadania pôvodného cieľa v Squide.
NF getsockopt(SO_ORIGINAL_DST) ukazuje na hľadanie pôvodného cieľa. Pri zachytávaní musí Squid zistiť, kam presmerované spojenie pôvodne smerovalo.
Explicitne nastavený prehliadač posiela požiadavky na proxy úmyselne. Také spojenie nezíska históriu zachytávania NAT len preto, že pri porte Squid listenera je napísané intercept.
Tento nesúlad preto môže zlyhať skôr, než začne hrať úlohu certifikát cieľa.
Začnite tým, ako spojenie dorazilo
- Ak má aplikácia nastavenú adresu proxy, určte obvyklý listener dopredného proxy, ktorý má použiť.
- Ak brána presmerúva inak priamu prevádzku, overte, že dorazí k zamýšľanému zachytávajúcemu listeneru a že podporované usporiadanie NAT zachováva potrebné informácie o cieli.
- Ak existujú oba režimy, zistite, na ktorú adresu a port sa zlyhávajúci klient skutočne pripojil.
Dokumentácia Squidu k http_port to hovorí jasne: vynechanie prepínača režimu volí režim dopredného proxy; intercept očakáva zachytávanie NAT na IP vrstve.
Potom riešte bezpečnosť prenosu oddelene. HTTP proxy dokáže prenášať HTTPS cez CONNECT. Spojenie TLS k proxy vyžaduje kompatibilný listener a nastavenie klienta. Dešifrovanie prevádzky k cieľu je ďalšia voliteľná možnosť.
Nekopírujte staré “riešenie HTTPS”, ktoré zapína generovanie certifikátov len preto, že adresa cieľa začína na HTTPS. Najprv opravte súlad medzi klientom a listenerom. Ak potom zostane skutočná chyba TLS, bude to užitočnejšia chyba na vyšetrenie.