Proxychains prin Squid: restricții CONNECT pe portul 80
Distingeți cererile HTTP proxy obișnuite de tunelele HTTP CONNECT ale proxychains când portul 80 de destinație este refuzat.
Browserul încarcă o pagină HTTP prin Squid. Aceeași destinație eșuează sub proxychains. Asta nu înseamnă neapărat că unul dintre cele două programe a ales un IP de proxy greșit.
Un client obișnuit care înțelege HTTP poate trimite cererea web către proxy-ul direct în forma unui proxy HTTP. Un înveliș generic de socket are nevoie în schimb de un tunel de octeți pentru conexiunea pe care aplicația voia să o deschidă. Pentru un proxy HTTP din lanțul său, proxychains folosește CONNECT.
Asta înseamnă că un site text simplu pe portul 80 poate genera o cerere CONNECT pentru portul 80. O politică Squid care permite CONNECT doar către lista aprobată de porturi TLS poate respinge acel tunel chiar dacă cererile HTTP obișnuite către portul 80 sunt permise.
Comparați cererile, nu doar numele gazdă
Documentația proxychains-ng descrie suportul său pentru HTTP CONNECT. Regulile de acces ale Squid pot distinge metoda și portul de destinație. Sunt căi de cerere diferite către același site.
Citiți respingerea și politica vizată înainte de a o schimba. Extinderea accesului CONNECT la fiecare port este o schimbare substanțială; nu ar trebui să fie răspunsul implicit la o nepotrivire de înveliș.
Dacă aplicația are suport nativ de proxy HTTP, folosirea lui poate evita un tunel generic inutil pentru HTTP text simplu. Dacă are într-adevăr nevoie de un tunel TCP brut, alegeți un protocol de proxy și o politică de porturi aprobate care să ofere unul.
O cerere reușită a browserului este o dovadă utilă despre accesibilitatea proxy-ului și despre un mod de cerere acceptat. Nu demonstrează că fiecare metodă de tunelare, port de destinație sau protocol de aplicație este permis prin acel proxy.