Nabigatzaileak HTTP orri bat kargatzen du Squid bidez. Helmuga bera huts egiten du proxychains-en pean. Horrek ez du nahitaez esan nahi bi programetako batek proxy IP okerra aukeratu duenik.

HTTP ulertzen duen bezero arrunt batek web eskaera aurreranzko proxyari bidal diezaioke HTTP proxy forman. Socket bilgarri generiko batek, ordea, byte tunel bat behar du aplikazioak ireki nahi zuen konexiorako. Bere kateko HTTP proxy baterako, proxychains-ek CONNECT erabiltzen du.

Horrek esan nahi du 80. portuan dagoen testu laueko webgune batek CONNECT eskaera sor dezakeela 80. porturako. CONNECT bere TLS portu onartuen zerrendara soilik uzten duen Squid politikak tunel hori ukatu dezake, 80. porturako HTTP eskaera arruntak onartuta egon arren.

Konparatu eskaerak, ez soilik ostalari-izenak

proxychains-ng-ren dokumentazioak bere HTTP CONNECT laguntza deskribatzen du. Squid-en sarbide arauek metodoa eta helmuga portua bereiz ditzakete. Webgune berbererako eskaera bide desberdinak dira.

Irakurri ukapena eta asmo den politika aldatu aurretik. CONNECT sarbidea portu guztietara hedatzea aldaketa handia da; ez litzateke bilgarriaren desadostasunerako erantzun lehenetsia izan behar.

Aplikazioak HTTP proxy euskarri natiboa badu, hura erabiltzeak testu laueko HTTP-rako beharrezkoa ez den tunel generiko bat saihestu dezake. Benetan TCP tunel gordin bat behar badu, aukeratu hura ematen duen proxy protokolo eta portu politika onartuak.

Nabigatzailearen eskaera arrakastatsu bat proxyaren irisgarritasunari eta onartutako eskaera modu bati buruzko froga baliagarria da. Ez du frogatzen tunel metodo, helmuga portu edo aplikazio protokolo guztiak proxy horren bidez onartuta daudenik.

Erlazionatutako artikuluak