Leximi i një gabimi SO_ORIGINAL_DST të Squid
Kontrolloni nëse një klient i konfiguruar në mënyrë eksplicite ka arritur një dëgjues ndërprerjeje përpara se të diagnostikoni një dështim të kërkimit të destinacionit origjinal në Squid.
NF getsockopt(SO_ORIGINAL_DST) tregon një kërkim të destinacionit origjinal. Në një konfigurim ndërprerjeje, Squid duhet të rikuperojë ku po shkonte fillimisht lidhja e ridrejtuar.
Një shfletues i konfiguruar në mënyrë eksplicite i dërgon kërkesat te proxy-ja me qëllim. Ajo lidhje nuk fiton histori ndërprerjeje NAT vetëm sepse intercept është shkruar pranë portës së dëgjuesit të Squid.
Prandaj kjo mospërputhje mund të dështojë përpara se certifikata e destinacionit të bëhet e rëndësishme.
Filloni nga mënyra se si mbërriti lidhja
- Nëse aplikacioni ka një adresë proxy të konfiguruar, identifikoni dëgjuesin e zakonshëm të proxy-së përpara që duhet të përdorë.
- Nëse një portë ridrejton trafik që përndryshe do të ishte i drejtpërdrejtë, kontrolloni që ai arrin dëgjuesin e synuar të ndërprerjes dhe që dizajni NAT i mbështetur ruan informacionin e nevojshëm të destinacionit.
- Nëse ekzistojnë të dy modelet, kontrolloni cilën adresë dhe portë ka kontaktuar në të vërtetë klienti që dështon.
Dokumentacioni i Squid për http_port e bën dallimin të qartë: heqja e një flamuri modaliteti zgjedh modalitetin e proxy-së përpara; intercept pret ndërprerje NAT në shtresën IP.
Pastaj trajtoni sigurinë e transportit veçmas. Një proxy HTTP mund të mbajë HTTPS përmes CONNECT. Një lidhje TLS drejt proxy-së kërkon një dëgjues dhe një konfigurim klienti të përputhshëm. Deshifrimi i trafikut drejt destinacionit është edhe një aftësi tjetër opsionale.
Mos kopjoni një “zgjidhje HTTPS” të vjetër që aktivizon gjenerimin e certifikatave vetëm sepse URL-ja e destinacionit fillon me HTTPS. Rregulloni së pari përputhjen midis klientit dhe dëgjuesit. Nëse pas kësaj mbetet një gabim i vërtetë TLS, ai do të jetë një gabim më i dobishëm për t'u hetuar.