не дружит у меня почему-то, иду через прокси - Connection refused, иду мимо прокси - все работает, пробую другую свою проксю через другого провайдера на другом серваке - тоже самое! У вас работает этот сайт через прокси? http://bank.gov.ua/ Или он отбивает зачем-то проксевые соединения...
ройся в локальной машине
-
работает, Серега, и всегда работал, это все ваши мульки с секретностью
попробуй по прямому АйПи зайти: 217.76.198.68 Удачи
Дык панимашь - ответ меня сильно смущает - Connection refused т.е. как бы и не мы виноваты... причем на разных каналах, на разных прокси-серверах и через разные фаерволы... блин... хотя фаерволы не причем, мимо прокси через НАТ все работает, шо то с проксями что-ли, попробую написать вебмастеру сайт может он подскажет что, если захочет...
Connection refused редко бывает из-за кривого резолвинга
так отож, с ресолвингом там все в порядке, и к тому-же это единственный сайт на котором появляется такой глючек... все остальное работает отлично - видать все таки конфигурация веб-сервера не совместима с моими проксями...
1. почему это озадачивает тебя, а не твоих админов? 2. "конфигурация веб-сервера не совместима с моими проксями..." как дежурный веб-мастер и системный администратор я не могу себе представить такую конфигурацию, которая была бы не совместима аж до "Connectio refused".
anyway, там хорошему админу - разбираться минут 10. если tail -f /var/log/squid/access.log и tcpdump - его друзья.
не вижу проблем- Code:
1118394614.647 260 10.10.1.11 TCP_MISS/200 9222 GET http://bank.gov.ua/ - DIRECT/217.76.198.68 text/html 1118394614.770 234 10.10.1.11 TCP_MISS/200 11613 GET http://bank.gov.ua/style.css - DIRECT/217.76.198.68 text/css 1118394614.889 108 10.10.1.11 TCP_MISS/200 2860 GET http://bank.gov.ua/Images/grif.gif - DIRECT/217.76.198.68 image/gif 1118394614.925 130 10.10.1.11 TCP_MISS/200 4333 GET http://bank.gov.ua/Images/nbu_u.GIF - DIRECT/217.76.198.68 image/gif 1118394614.932 126 10.10.1.11 TCP_MISS/200 1240 GET http://bank.gov.ua/JSC/Index/return.js - DIRECT/217.76.198.68 application/x-javascript 1118394615.027 54 10.10.1.11 TCP_MISS/200 549 GET http://bank.gov.ua/images/home.gif - DIRECT/217.76.198.68 image/gif 1118394615.029 55 10.10.1.11 TCP_MISS/200 598 GET http://bank.gov.ua/images/ua_a.gif - DIRECT/217.76.198.68 image/gif
---1. почему это озадачивает тебя, а не твоих админов? мой админ в отпуске, озадачить некого, разбираюсь сам...
---2. "конфигурация веб-сервера не совместима с моими проксями..." как дежурный веб-мастер и системный администратор я не могу себе представить такую конфигурацию, которая была бы не совместима аж до "Connectio refused".
вот и я не могу представить такого но блин трабл есть и ничего более умного в голову не лезет. anyway, там хорошему админу - разбираться минут 10. если tail -f /var/log/squid/access.log и tcpdump - его друзья.
угу смотрел я на них конечно токо нифига они не помогут даже отличному админу в access.log сквида токо вот это Code:
1118400169.277 2403 192.168.1.x TCP_MISS/503 1291 GET http://bank.gov.ua/ - NONE/- text/html 1118400172.291 2940 192.168.1.x TCP_MISS/503 1313 GET http://bank.gov.ua/favicon.ico - NONE/- text/html
и все! дамп ничего не дает - судя по всему сквид даже не обращается к сайту банка... мимо сквида - в дампе все видно как коннект идет и все прекрасно...
не вижу проблем- угу, а они есть ладно буду ковыряться дальше....
вообщем ступил я с tcpdump-ом немного просто греп делал не на ту фразу вообщем отследил вывод и получил странную картину что при конекте через прокси - мой роутер и сайт банка начанали перестреливаться странными пакетами с флагами SWE и в ответ от сайта RWE, эти флаги мне незнакомы в инете про них практически ничего не нашел, но сам факт что кроме перестрелки этими пакетами толку никакого не было - в результате получал Connection refused Без прокси - обычные аск и win пакеты и нормальная работа. ОДнако пытаясь найти в инете что-то про эти флаги нашел инфу что в случае проблем с этими пакетами нужно выключить ECN (Explicit Congestion Notification) in TCP/IP, выключив это через sysctl - получил нормальную работу сайта нацбанка! Вот только кто виноват я не понял, почему прокси посылает пакеты с использованием этого расширения, а без прокси без этого идет конект, и почему именно этот сайт не может договориться о работе с использованием этой "расширенной системы нотификаций" не понятно... но судя по тому что у меня этот трабл на разных шлюзах и с разными компами и проксями и разными провайдерами, и только с этим сайтом, то проблема не на моей стороне 100%
Невозможно соединится с некторыми сайтами при работе через Squid Когда используется Squid, при соединении с некоторыми сайтами возникют ошибки тип ``(111) Connection refused'' или ``(110) Connection timed out'', хотя эти сайты нормально работают, если не использовать Squid.
Некторые версии linux используют Explicit Congestion Notification (ECN) и это может быть причиной неудавшихся TCP-соединений, когда происходит обращние к к сайтам с "кривым" файерволом или неверно работающим TCP/IP.
Чтобы работать с подобными "сбоящими" сайтами вы можете выключить использование ECN при помощи следующей команды:
echo 0 >/proc/sys/net/ipv4/tcp_ecn
Вот что было найдено в списке рассылки FreeBSD:
From: Robert Watson
Как уже было указано Bill Fumerola (я подумал, что немного детилизирую пояснения), наблюдаемое вами - есть результат ошибки в коде FreeBSD IPFW. FreeBSD did a direct comparison of the TCP header flag field with an internal field in the IPFW rule description structure. Unfortunately, at some point, someone decided to overload the IPFW rule description structure field to add a flag representing "ESTABLISHED". They used a flag value that was previously unused by the TCP protocol (which doesn't make it safer, just less noticeable). Later, when that flag was allocated for ECN (Endpoint Congestion Notification) in TCP, and Linux began using ECN by default, the packets began to match ESTABLISHED rules regardless of the other TCP header flags. This bug was corrected on the RELENG_4 branch, and security advisory for the bug was released. This was, needless to say, a pretty serious bug, and good example of why you should be very careful to compare only the bits you really mean to, and should seperate packet state from protocol state in management structures, as well as make use of extensive testing to make sure rules actually have the effect you describe.
ps: вывод tcpdump'a не нужно грепать: #tcpdump -pqni eth0 host 1.1.1.1
м-да, глюк развесистый. автору треда - респект.
Да ладно, я ж еще не все забыл со времени своего админства Хотя глючек противнейший..... http://squid.h12.ru/FAQ/FAQ-14.html во, а то я в факе сквида поискать не догадался.
ps: вывод tcpdump'a не нужно грепать: #tcpdump -pqni eth0 host 1.1.1.1 О! Сенкс, я не знал о таком выводе, как то грепал по привычке. а маны без лишней надобности не читаем
Відповісти
Поперед.
Зміст
Наступ.
Гілками
