|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Eugene B. Berdnikov 2:5020/400 29 Nov 2005 20:08:25
To : "Artem Nefedov"
Subject : Re: squid & 2 ISP
--------------------------------------------------------------------------------
net.ru>
From: berd@desert.ihep.su (Eugene B. Berdnikov)
Artem Nefedov <artem@camelotgroup.net> wrote:
AN>
AN> "Eugene B. Berdnikov" <berd@desert.ihep.su> сообщил/сообщила в новостях
AN> следующее: news:3rvt53-tuq.ln1@protva.ru...
>> Видно, что отвечает всё-таки Рамблер (это его типичное поведение), но
>> по пути кто-то навешивает левый tos/dscp по непонятно каким критериям.
>> Это даже хорошо, потому что может служить лишним поводом предъявить этот
>> дамп провайдеру и поставить вопрос ребром - какого чёрта? :)
AN> Т.е. возможно что сквид затыкается именно по причине левого tos? Hо тогда
AN> почему не затыкается telnet?
AN> Дамп во время telnet -b 212.y.y.40 www.rambler.ru www:
AN> [root@watcher home]# tcpdump -nl -i eth2 host www.rambler.ru
AN> tcpdump: listening on eth2
AN> 17:49:03.587081 212.y.y.40.53484 > 81.19.70.1.http: S
AN> 2213899674:2213899674(0) win 1024 <mss 256,sackOK,timestamp 63455411
AN> 0,nop,wscale 0> (DF) [tos 0x10]
Hе думаю, что дело в tos... Hо тот telnet, что сейчас идёт с линуксами,
ставит по умолчанию tos=0x10, чтобы совсем уж привести к ситуации со
сквидом, наверное, следует ему дать опцию -S 0x00.
Кстати, mtu можно вернуть в 1500. :)
AN> 17:49:03.656323 81.19.70.1.http > 212.y.y.40.53484: S
AN> 3505552091:3505552091(0) ack 2213899675 win 0 <mss 256> (DF) [tos 0x30]
AN> 17:49:03.656393 212.y.y.40.53484 > 81.19.70.1.http: . ack 1 win 1024 (DF)
AN> [tos 0x10]
AN> 17:49:03.727161 81.19.70.1.http > 212.y.y.40.53484: . ack 1 win 8192 (DF)
AN> [tos 0x30]
AN> 17:49:17.843363 212.y.y.40.53484 > 81.19.70.1.http: P 1:8(7) ack 1 win 1024
AN> (DF) [tos 0x10]
AN> 17:49:17.913029 81.19.70.1.http > 212.y.y.40.53484: P 1:174(173) ack 8 win
AN> 8192 (DF) [tos 0x20]
AN> 17:49:17.913126 212.y.y.40.53484 > 81.19.70.1.http: . ack 174 win 1211 (DF)
AN> [tos 0x10]
AN> 17:49:17.913037 81.19.70.1.http > 212.y.y.40.53484: F 174:174(0) ack 8 win
AN> 8192 (DF) [tos 0x20]
Любопытно. В принципе ответ должен дать провайдер, но можно предположить,
что у провайдера какой-нибудь statefull firewall, который настроен на
отсечение всех проксированных запросов (например, если договор позволяет
подключение только частного лица). Соответственно, провайдер вылавливает
в запросе пакеты с хедерами типа X-Forwarded-For:, Via: и им подобные.
Это может объяснить тот факт, что с почтой всё нормально (и потому mtu
здесь не при чём - но поковырять этот параметр тоже было полезно).
Можно попробовать дать подозрительные хедеры ручками в telnet'е, и
посмотреть что получится. Второй шаг - залить полностью запрос
со всеми хедерами сквида (выудить их можно по tcpdump -X).
--
Eugene Berdnikov
--- ifmail v.2.15dev5.3
* Origin: Institute for High Energy Physics, Protvino, Russia (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
