Linux за българи: Форуми

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

значи - следната ситуация:
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-а каквото и да значи това.

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

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

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

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

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

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

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

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

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

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

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

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

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.

Значи, пробвах с външно прокси (ще рече - намиращо се зад 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 е проблема в моя случай, просто описанието на симптомите адски прилича на моята ситуация.

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

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

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

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

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

Ами не става.

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

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

Не баш. И в двата случая не работи.

1. Не слагам никакво прокси при мен -> пакетите излизат директно през моя рутер -> влизат в transparent proxy-то на доставчика -> арената не работи като хората.

2. Слагам на моята машина squid -> пакетите минават през моя squid, после минават през рутера ми и отново през проксито на доставчика ми.

3. Настройвам прокси, което се намира "зад" това на доставчика ми -> арената работи. За момента това е единствения вариянт, при който арената работи нормално.

Да, въпроса е обаче, че проблема е много вероятно да не е у доставчика ми.

Ако вържа кабела, който идва от доставчика и влиза в рутера, директно в някой от компютрите зад рутера arenabg.com си работи. Освен това, ако проблема беше при тях нямаше да съм единствения клиент с такова оплакване.

Не твърдя, че при доставчика ми няма проблем. Не твърдя, че при мен няма проблем. Твърдя, че нямам идея къде е проблема и по-лошо - нямам идея как да разбера. :(

Възможно ли е това ?!?
Ако си оправиш ТТЛ почти няма начин да се установи дали пакета преимнава НАТ
пусни тцпдумп за да се ориентираш какво става ...
поне да разбереш на кой слой е проблемът .
Поздрави

TTL-а няма причина да ебава нещата, смисъл че доставчика ми знае че сме с NAT и т.н. и от тая гледна точка няма проблем - не сме нелегано маскирани . Освен това arenabg.com е единствения сайт, с който има проблем...

tcpdump пусках по всякакъв начин, по какъвто се сетих, не мога да го хвана къде е....

Както и да е, за момента има workaround и малко ми писна да го боря, така че по-натам като се захвана пак ще пиша ако има нещо ново. Благодаря за съдействието.

Другото което се сещам е:
1. connlimit за всяко IP. Да не би да имаш много едновременни сесии към Арената ?
2. Доставчикът ти може и да не прави проблем ... ама Арена-та може да не харесва определении ТТЛ-и и ИП-а а защо не и портове (--sport).

Нещото което може би си направил но си забравил да публикуваш тук е :
tcptraceroute -i eth1 -p 1025 www.arenabg.com 80
tcptraceroute -i eth1 -p 1025 www.arenabg.com 8080

и също така "workaround"-a e ? Не че ме интересува де ...  АренаБг,цд,тв и т.н. не посещавам, но някой може да има подобен проблем.
външно прокси?

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

п.с.: тъпото е, че и аз не влизам по такива сайтове, обаче другите две типчета, дето си share-ваме интернета с тях само оттам точат...