Squid3: Пустой ответ (нулевой длины)

Выставлять debug_options и глядеть в логи сквида.

>Также, при указании вручную прокси сервера в браузере - тоже, все работает на ура. (очень странно)

Так может быть, проблема в Tproxy ?

Копая дальше в суть проблемы, на сервере с squid стоит запустить tcpdump в файл, и разбираться через wireshark (Analyze -> Follow TCP stream)

Спасибо за дельное предложение, запустил tcpdump, установил wireshark, разбираюсь. Обнаружил, что на проблемных сайтах tcpdump показывает такую ошибку..

24 6.025841 82.179.92.2 192.168.5.53 ICMP 590 Destination unreachable (Fragmentation needed)[Packet size limited during capture]

.

При этом, при посещении других, «нормальных» сайтов, такого сообщения нет.

Поясню про сервер со сквидом. Это тестовая машина, которая является виртуальным KVM сервером. Связь клиент- интернет осуществляется по следующей схеме: http://adygnet.ru/scheme.jpg

Tproxy - тестовая машина, которая вскоре должна заменить собой основной шлюз. На ней настроен фаервол и шейпер, фаервол натит на адрес 82.179.92.7. Поэтому я немножко недоумеваю, откуда в логах tcpdump адрес 192.168.5.53..

Пока я хочу попробовать запустить отладку в сквиде, и смотреть более подробно, но не думаю, что это сильно в чем-то поможет. ТАкже нужно будет подробнее посмотреть дорожку пакетов от клиента-в интернет и обратно. Если у кого-то появились какие-то соображения - подскажите. Проблема периодически всплывает, и хотелось бы ее разрешить для всех.

PS. Браузеры использую разные. IE, Firefox, Opera, Chromium. Все одно и тоже. При попытке писать здесь сообщения через прозрачный прокси движок сайта выдает следующее:

Required String parameter 'mode' is not present
Скрипту, генерирующему страничку были переданы некорректные параметры. Если на эту страничку вас привела одна из страниц нашего сайта, пожалуйста сообщите нам адреса текущей и ссылающейся страниц.

При этом, при непрозрачном прокси (ручками в браузере), все работает на ура. И! если потом опять отключить использование прокси сервера в браузере, то тоже все начинает работать. Во всех браузера. Аки сквид кеширует или проглатывает что-то там и потом все идет хорошо.
Не понимаю, в чем затык.

Что именно обновилось во время apt-get upgrade?

По поводу TPROXY, http://wiki.squid-cache.org/Features/Tproxy4#Minimum_Requirements_.28IPv4_only.29:

TPROXYv4 support reached a usable form in 2.6.28. However several Kernels have various known bugs:

• older than 2.6.28 are known to supply IPs wrongly to Squid and other client programs. Avoid!
• 2.6.28 to 2.6.36 are known to have ICMP and TIME_WAIT issues.
• 2.6.32 to 2.6.34 have bridging issues on some systems. Please use
• 2.6.30 or 2.6.31 for production machines, they seem to work properly.

Попробуй отказаться от TPROXY впользу обычного transparent proxy (через редирект). Или смени ядро (в updates есть 2.6.35, а в proposed - 2.6.38).

>590 Destination unreachable (Fragmentation needed)

которая вскоре должна заменить собой основной шлюз.

Про MSS? На шлюзе нужно обрабатывать это поле, т.к. у тебя tunnel и там MTU наверняка меньше.

iptables -t mangle -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Возможно, для eth1 / eth0 сделан workaround в виде уменьшения MTU, а для tproxy - нет

Поэтому я немножко недоумеваю, откуда в логах tcpdump адрес 192.168.5.53..

tcpdump захватывает трафик на определённом интерфейсе, скорее всего ты выбрал eth0

mironov_ivan:
Cтоит свежесобранное ядро 2.6.39 с убунтушными конфигами. Собирал и устанавливал через make-kpkg, конфиги взял родные, от ядра 2.6.32 и немножко допилил - включил IPSET и поотключал вещи, ненужные в вирутальной машине - wifi, звук и проч.

PS. Система - Ubuntu Server 10.04

router:

Телепаты снова в силе :) почти угадал. Немного головоломно-геморройная ситуация. Есть два провайдера, один местный, а другой федеральный - федеральная универская сеть RUNNET. Так вот, местный провайдер обеспечивает последнюю милю для этого самого RUNNETa. Для реализации тунеля через местного прова пришлось мту увеличивать до значения 1570, на свитчах пришлось включать JumboFrame.

Я пробовал пинговать эти проблемный сайты большими пингами - все нормально, проходят.

Сейчас попробую пустить трафик через другого прова, и посмотреть, как это отразится на глюкающих сайтах. Если что получится - сразу отпишусь.

По поводу недоумок с ip адресом 5.53. Да, ты все правильно сказал, я слушаю на eth0, но 82.179.92.2 - внешний сервер для этого компа, каким образом он знает о существовании соединения между 5.53 и интернет сайтом, куда тот соединяется, ведь клиент находится за NAT. По идее должен быть IP 82.179.92.7, но такого не происходит.
===================================================================
Вот, что говорят разработчики по поводу моей проблемы http://wiki.squid-cache.org/SquidFaq/TroubleShooting#Why_do_I_sometimes_get_.22Zero_Sized_Reply.22.3F

Извиняйте за многобуквие.

По поводу отказа от TPROXY. Tproxy необходим для того, чтобы можно было делить трафик не сквидом, а ядром.
А сквид нужен для того, чтобы можно было фильтровать порнуху и рекламу. Как кеширующий прокси, он наверное себя уже не будет оправдывать. Безлимитка и боле-мене нормальные скоростя анулируют плюсы от кеша. Или я не прав?

Cтоит свежесобранное ядро 2.6.39 с убунтушными конфигами. Собирал и устанавливал через make-kpkg, конфиги взял родные, от ядра 2.6.32 и немножко допилил - включил IPSET и поотключал вещи, ненужные в вирутальной машине - wifi, звук и проч. PS. Система - Ubuntu Server 10.04

В таких случаях лучше бы брать официальное ядро от более свежих релизов (кстати они официально портируются в репы LTS), либо из Ubuntu Kernel PPA. Оно как-то надёжнее ИМХО.

Как кеширующий прокси, он наверное себя уже не будет оправдывать. Безлимитка и боле-мене нормальные скоростя анулируют плюсы от кеша. Или я не прав?

Частично не прав. Кеш позволяет почти мгновенно доставлять клиентам разнообразную статику (скрипты, картинки, css и т.п.). При просмотре сайтов на тормозных серверах разница с кешем и без обычно заметна невооружённым глазом =).

Да, согласен, тоже было стремно все это затевать. Главная причина - стабилизированный IPSET.

И вот сейчас пустил трафик через другой канал - все работает вроде бы.. По крайней мере и здесь, на форуме сообщения нормально отправляются, и еще один сайт - yahoo.ru раньше не открывался, а сейчас вроде прет... Посмотрим, что будет дальше.
И буду ковыряться, что же там такого происходит с mtu.

>Для реализации тунеля через местного прова пришлось мту увеличивать до значения 1570,

Увеличивать? Не уменьшать? Подозреваю, что проблема как раз в неправильной настройке.

На туннелирование трафика получается некий overhead в пакетах, поэтому реальный MTU туннеля получается меньше, чем MTU интерфейса. Для того, чтобы это не создавало проблем, граничное оборудование должно менять поля MSS при установке соединения - уменьшать их на значение overhead'а

Я пробовал пинговать эти проблемный сайты большими пингами - все нормально, проходят.

С какой стратегией?

       -M hint
              Select Path MTU Discovery strategy.  hint may be either do (pro‐
              hibit  fragmentation,  even local one), want (do PMTU discovery,
              fragment locally when packet size is large), or dont (do not set
              DF flag).

Может сейчас будет глупость, но все же скажу. Насколько я понимаю, создавался GRE туннель, и на линии - наш интерфейс - интерфейс местного провайдера пришлось увеличить максимальный размер пакета на размер заголовков GRE туннеля, поскольку, как я уже говорил, местный провайдер обеспечивает последнюю милю для этой самой федеральной сети RUNNET. Таким образом, связь этим самым RUNNET уже происходит c обычным размером Ethernet кадра.

PS.Если бред наговорил - сильно не пинай, я не присутствовал при этой кухне..