Изпечатай

[Hapkoc]

модераторите ако преценят да преместят темата, но си мисля, че е за напреднали все пак.

значи - следната ситуация:
internet <-> [ gateway ] <-> lan (192.168.1.0/24)

проблема е с arenabg.com, а именно - пускаш browser, пишеш arenabg.com в адрес полето и бичиш enter - резултат - излиза title-а на арената, като дадеш view source излиза целия html, browser-а показва бяла страница (нищо не рендира (бахти думата)) и статуса е "Transferring data" и прогрес бара седи на средата все едно зарежда.

с nat-а няма проблеми, понеже останалите сайтове си работят на пушка (и не само сайтове).

сега доколкото разбирам от доставчика са сложили transparent proxy до арената. така мисля ей затова:

Примерен код

$ telnet arenabg.com 80 Trying 82.101.72.23... Connected to arenabg.com. Escape character is '^]'. GET / HTTP/1.0 HTTP/1.0 503 Service Unavailable Server: squid/2.5.STABLE5 Mime-Version: 1.0 Date: Thu, 01 Dec 2005 14:22:09 GMT Content-Type: text/html Content-Length: 1 Expires: Thu, 01 Dec 2005 14:22:09 GMT X-Squid-Error: ERR_CONNECT_FAIL 111 X-Cache: MISS from <url> Connection: close Connection closed by foreign host.

въпроса ми е каква боза може да се получава м/у gateway-а и proxy-то, че да работи по тоя малоумен начин.

друг тест - зареждам в links2 arenabg.com - резултата е следния - показва се пак title-а на страницата, долу пише "Request sent". натискам "\", което е "toggle html/plain text view" - излиза ми html кода на страницата. натискам пак "\" - воала, излиза си страницана на arenabg.com

изобщо държи се сякаш не може да си финализира connection-а каквото и да значи това.

благодаря предварително на заинтересувалите се.

[laskov]

Мисля си, че в страницата може да има препратка към друг сайт - WebCounter, банер някакъв или кой знае какво, което да не се зарежда поради дявол знае каква причина '>

[Hapkoc]

има логика, обаче е и малко съмнително да е от това, т.к. допреди да сменим доставчика се зареждаше без проблеми. възможно е да е станало някакво лудо съвпадение и по същото време да са сменили нещо по арената, че да става така, обаче сигурно и други хора щяха да изпищят...

иначе установявам следното:
с lynx се отваря моментално
с links се отваря почти моментално
с links2 се отвяря след няколко минути
с firefox не се отваря, т.е. след чакане 30 мин не се отвори, което практически е равносилно на "не се отваря"

[Hapkoc]

Ситуацията стана още по-интересна (поне за мен).

Направих следния тест: бучнах кабела за интернет в една от машините зад рутера и направих съответните настройки за да има интернет. Резултат - arenabg.com се зарежда мигновено без никакви проблеми. Правя си извода, че проблема вероятно е в рутера ми и правя следващ експеримент:

Махам всички правила на firewall-а (pass all) освен SNAT-а. Резултат - проблема си го има.

След разсъждения стигам до предположението, че през proxy-то на доставчика ми минава не са само трафика за arenabg.com, а и за други "free" сървъри и се оказвам прав - free.data.bg също минава през proxy-то. Обаче free.data.bg се зарежда без никакви проблеми.

По моите разсъждения стигам до извода, че проблема може да е както при мен, така и при доставчика ми, така и при arenabg.com, а още по-вероятно някаква комбинация от настройки на повече от едно място, но като цяло продължавам да нямам идея къде точно е проблема. '>

Сега остава някой по-вещ да каже дали разсъждавам правилно... и някакви идеи как да установя къде е проблема...

п.с.: ако някой има благородното желание да ми пусне едно прокси за 5 мин моля да пише  '>

[Hapkoc]

последният тест показа, че има прогрес и при firefox - за  час и десет минути успява да render-не http://www.arenabg.com:8080/image/logo.gif .

[Uvigii]

arena.bg:80 и arena.bg:8080 са различни неща

Цитат

The httpd_accel_port option Accelerated requests can only be forwarded to one port: there is no table that associates accelerated hosts and a destination port. Squid will connect to the port that you set the httpd_accel_port value to. When acting as a front-end for a web server on the local machine, you will set up the web server to listen for connections on a different port (8000, for example), and set this squid.conf option to match the same value. If, on the other hand, you are forwarding requests to a set of slow backend servers, they will almost certainly be listening to port 80 (the default web-server port), and this option will need to be set to 80.

Цитат

arena.bg:80 и arena.bg:8080 са различни неща

не съм твърдял друго. а това трябва ли да ми подскаже нещо?

[Hapkoc]

Значи, пробвах с външно прокси (ще рече - намиращо се зад gateway-а на доставчика ми) и нещата работят. Като вариянт за заобикаляне на проблема реших да setup-на transparent proxy при мен, което да пренасочва заявките към "външното" proxy. Докато разучавах настройките на squid попаднах на следния параметър:

Цитат

#  TAG: httpd_accel_no_pmtu_disc        on|off #       In many setups of transparently intercepting proxies Path-MTU #       discovery can not work on traffic towards the clients. This is #       the case when the intercepting device does not fully track #       connections and fails to forward ICMP must fragment messages #       to the cache server. # #       If you have such setup and experience that certain clients #       sporadically hang or never complete requests set this to on. # #Default: # httpd_accel_no_pmtu_disc off

Т.к. ми се стори, че описанието доста добре се припокрива с моя проблем поразрових насам натам.

Доколкото разбирам path mtu discovery проблема се състои в следното - сървъра започва да изпраща пакети с по-голям размер, отколкото могат да бъдат обработени по дадения маршрут и с DF флаг, някой от рутерите по пътя (именно този, на който му идват твърде големи пакетите) връща ICMP Destination Unreachable-Fragmentation Needed, но ICMP трафика се блокира и не стига да сървъра, който няма как да разбере, че трябва да намали размера на пакетите (казано с прости думи, и вероятно не съвсем коректно).

Ако не съм разбрал нещо, моля някой да ме коригира.

И да съм разбрал и да не съм разбрал искам да попитам следното: от кого именно би трябвало да се генерира ICMP съобщението в конкретния случай. От моя рутер, от рутера на доставчика, от клиентската машина (май не е от нея)? 'Щото tcpdump на рутера не показва да се генерират такива пакети при опит да се зареди арената.

edit: не твърдя, че именно path mtu discovery е проблема в моя случай, просто описанието на симптомите адски прилича на моята ситуация.

Отново предварително благодаря на заинтересувалите се. '>

[Uvigii]

Цитат (Guest @ Дек. 03 2005,19:00)

Цитат arena.bg:80 и arena.bg:8080 са различни неща не съм твърдял друго. а това трябва ли да ми подскаже нещо?

Ами предполагам - ДА
'>
Accelerated requests can only be forwarded to one port
сега като е по-кратичко ?

[Hapkoc]

Това ясно, обаче не ми решава проблема... или поне аз не се сещам как го решава

[Uvigii]

ами пробвай:
1. Да ползваш твоето прокси НЕ* като transparent
2. Огледай какви хедъри пращаш
и кажи какво е станало

[Hapkoc]

Няма как да не го ползвам като transparent, пробвах, филтрирани са портовете...
Хедърите са ок, горе примера, който съм го дал с telnet-а е просто като доказателство за наличието на споменатото прокси. Иначе ако пратя Host: arenabg.com и връща страницата без проблеми (това пак през телнет става въпрос). През firefox/opera/links2 се пъне и не успява да я зареди (или по-скоро да я покаже - както писах по-горе, html-a си пристига при мене, обаче нищо не се "рендира").

edit: Може да не съм те разбрал правилно за първото предложение. Кое прокси имаш предвид - това на доставчика ми или на мойта машина което е?

[Uvigii]

Цитат

Кое прокси имаш предвид

Цитат

ами пробвай: 1. Да ползваш твоето прокси НЕ* като transparent

[Hapkoc]

Ами не става.

Ефекта е аналогичен, като с trasparent proxy-то на доставчика ми.

т.е. ако ти не пускаш прокси
а пакетите минават директно през твоя рутер/нат
арена.бг - работи
а като пуснеш прокси (без значение какво) спира