Via aplikaĵo montras al prokseo B, sed ĝi estis lanĉita tra envolvaĵo agordita por prokseo A. Kiun eliron vidas la retejo? La respondo dependas de tio, kiun konekton la envolvaĵo interkaptas.

En simpla nestita aranĝo, la aplikaĵo unue provas konektiĝi al B. La envolvaĵo interkaptas tiun konekton kaj portas ĝin tra A. Poste la aplikaĵo parolas la proksean protokolon de B super la rezulta fluo, kaj B faras la finan konekton al la retejo.

application → wrapper proxy A → application proxy B → website

La retejo vidas la finan eksteren konekton de B. B vidas konekton alvenantan tra A. Tio diferencas de tio, ke la envolvaĵo silente anstataŭigas la propran proksean agordon de la aplikaĵo.

La simpla diagramo havas kondiĉojn

Preterpasantaj reguloj, nesubtenataj soketaj alvokoj, ekzistantaj procezoj kaj la interkapta modelo de ĉiu produkto povas ŝanĝi la vojon. Iuj envolvaĵoj povas ekskludi sian propran prokseon aŭ elektitajn celojn. Ne supozu, ke ĉiu paro da iloj kunmetiĝas same.

La priskribo de proxychains-ng klarigas ĝian interkaptan aliron kaj limigojn. Programo uzanta denaskan proksean subtenon ankoraŭ faras retan konekton al tiu prokseo, kio estas unu kandidato por interkapto.

Por intenca ĉeno de neaŭtentikitaj publikaj finpunktoj, la senpaga proksea listo proponas kandidatojn kies protokoloj devas kongrui kun ĉiu ilo. Por neatendita eliro, registru tri adresojn aparte: la finpunkton, kiun elektis la aplikaĵo, la finpunkton, kiun elektis la envolvaĵo, kaj la retej-alrigardan rezulton. Rigardi nur la agordojn de la retumilo maltrafas la mezan tavolon.

Uzu unu vojon dum vi establas la celatan konduton, poste aldonu la alian nur se la ĉeno necesas. Pliaj saltoj povas aldoni fiaskpunktojn kaj malsamajn fido-rilatojn. Ili ne aŭtomate forviŝas identigajn kuketojn nek igas ĉiun konekton en la aplikaĵo sekvi la saman vojon.

Rilataj artikoloj