Вопросы Теги

Сквид 3.1 не направляет трафик через ProxyChains

Большая поддержка файла (> 2 ГБ) для Linux должна быть обращена в трех отдельных местах, чтобы гарантировать, чтобы Вы не сталкивались с макс. пределом размера файла на 2 ГБ:

  1. Большая поддержка файла включена в ядре

  2. Файловая система, которая поддерживает большие размеры файла (много основанных на Linux файловых систем делают (ext3, reiserfs> = 3.6, и т.д.))

  3. Большая поддержка файла в библиотеках или приложениях используется

Поддержка ядра больших файлов была вокруг с тех пор 2.4.0-test7; если Вы используете пользовательское ядро, удостоверяетесь включение больших опций файла.

Большинство файловых систем Linux поддерживает большие файлы, но у Вас могут быть проблемы с помощью сетевой файловой системы.

Наконец, библиотеки (т.е. libpcap) и приложения должны быть скомпилированы с gcc опциями-D _LARGEFILE64_SOURCE-D _FILE_OFFSET_BITS=64. Проверьте для обеспечения пакетов, которые Вы используете или прибывший предварительно скомпилированный с этими опциями или самокруткой.

Посмотрите здесь для получения дополнительной информации.

1
задан 1 November 2009 в 20:11
2 ответа

Как возможное обходное решение Rube Goldberg, разве сквид не может быть настроен для использования самого прокси? Если так, и Вы хотите различные умные функции proxychains, Вы не могли выполнить некоторый другой никакой-op прокси, который работает под proxychains. Возможно, даже более ранняя версия сквида, установленного в обходном пути и настроенного, чтобы ничего не сделать:

squid-3.1 --> squid-3.0-noop --> proxychains

Т.е. вызовите proxychains /path/to/squid-3.0/bin/squid (со сквидом 3,0 настроенных, чтобы проксировать неизмененный запрос и послушать на, скажем, порте 12345), и затем вызывают сквид 3.1 обычно, но настраивают его для маршрутизации всех запросов через localhost:12345.

Это является замысловатым, но это получает Вас эти 3,1 функции плюс proxychains функции, по крайней мере, пока/если некоторая более мудрая душа не выясняет, как получить его работающий непосредственно.

2
ответ дан 3 December 2019 в 22:45
  • 1
    Совсем неплохо...! Я думал об использовании Squid' s собственное объединение в цепочку (cache_peer) опция, но на прямом Сквиде к Сквиду только основание. Вызов второго Сквида через ProxyChains является действительно допустимой опцией. Это действительно добавляет немного служебные, но это могло удаться, и я попытаюсь протестировать его позже сегодня. Я пытался проголосовать за Ваш ответ на данный момент, в то время как я ожидаю другого ответа, который решает эту загадку, но я потратил всю свою репутацию на щедрость. Я буду держать в курсе Вас, спасибо! –  mr-euro 27 October 2009 в 20:19
  • 2
    проголосовавший за то, что был очень hackish, но умное решение :) –  Sam Halicke 27 October 2009 в 20:32

Что-нибудь в журналах Сквида или отладочной информации? Если это ничего не раскрывает, захватите копию strace и вставьте начинающуюся часть (части) следующего где-нибудь:

strace -t -c -o strace.log proxychains squid -X -N

Это должно помочь нам получить немного больше понимания, что продолжается, учитывая ограниченную информацию.

0
ответ дан 3 December 2019 в 22:45
  • 1
    Журналы сквида не показывают ничего аварийного. Просто каждый хит/мисс отображен, но никакие ошибки или предупреждения. ProxyChains обычно производят к консоли, но ничто вообще не отображено. Журнал Strace нескольких Запросов HTTP браузера через Сквид присоединил: pastebin.com/m3f92f567 –  mr-euro 25 October 2009 в 11:33
  • 2
    @serverninja Вам нужны какие-либо другие журналы? –  mr-euro 26 October 2009 в 16:11
  • 3
    На самом деле, если Вы могли бы использовать strace без-c опции (моя ошибка). I' m пытающийся найти, где это зависает, возможно, длинный ряд опроса () без ответа, ошибок на чтении (), и т.д. –  Sam Halicke 26 October 2009 в 19:20
  • 4
    Спасибо serverninja. Я должен был удалить параметр отладки (-X) Сквида, поскольку strace.log был слишком большим для вставки в pastebin: pastebin.com/mb3ac15f –  mr-euro 27 October 2009 в 12:54

Теги

Похожие вопросы