Legi eraron SO_ORIGINAL_DST de Squid
Kontrolu, ĉu eksplicite agordita kliento atingis interkaptan aŭskultanton antaŭ ol diagnozi malsukceson de la serĉo de la origina celo en Squid.
NF getsockopt(SO_ORIGINAL_DST) indikas serĉon de la origina celo. En interkapta agordo, Squid devas retrovi, kien la alidirektita konekto origine iris.
Eksplicite agordita retumilo sendas siajn petojn al la prokura servilo intence. Tiu konekto ne akiras historion de NAT-interkaptado nur ĉar intercept estas skribita apud la pordo de la Squid-aŭskultanto.
Tial ĉi tiu miskongruo povas malsukcesi antaŭ ol la atestilo de la celo iĝas grava.
Komencu per tio, kiel alvenis la konekto
- Se la aplikaĵo havas agorditan prokuran adreson, identigu la kutiman antaŭenigan prokuran aŭskultanton, kiun ĝi uzu.
- Se kluzo alidirektas alie rektan trafikon, kontrolu, ĉu ĝi atingas la celitan interkaptan aŭskultanton kaj ĉu la subtenata NAT-aranĝo konservas la necesajn celinformojn.
- Se ambaŭ reĝimoj ekzistas, kontrolu, kiun adreson kaj pordon la malsukcesanta kliento fakte kontaktis.
La dokumentaro de Squid pri http_port klare montras la diferencon: forlasi reĝiman flagon elektas antaŭenigan prokuran reĝimon; intercept atendas NAT-interkaptadon ĉe la IP-tavolo.
Poste traktu transportsiguron aparte. HTTP-prokuro povas porti HTTPS per CONNECT. TLS-konekto al la prokuro postulas kongruan aŭskultanton kaj klientan agordon. Malĉifri celan trafikon estas denove alia laŭvola kapablo.
Ne kopiu malnovan “HTTPS-riparon”, kiu ŝaltas atestilan generadon nur ĉar la cela URL komenciĝas per HTTPS. Unue riparu la interkonsenton inter la kliento kaj la aŭskultanto. Se poste restas reala TLS-eraro, ĝi estos pli utila eraro por esplori.