Firefox vs яндекс

[artflam]

Всем доброго дня.
уважаемые модераторы не уверен, что пост ставлю в нужную ветку.

проблема вот какая. локальная сеть. Инет приходит на сервер (5 мастер с прокси) , здесь же фильтруется (через squid по white list)  и раздается в локальную сеть.
на локальных машинах  и на сервере некорректно отображаются внутренние страницы яндекса (прочие сайты - ОК). пример в аттаче. проблема в том, что школьная почта хранится на яндексе. На сервере работает Thunderbird и отлично получает/отправляет почту по IMAP. на локальных машинах не получается ни Thunderbird настроить, ни корректно октрыть веб интерфейс яндекса через Firefox.
TB - говорят на форумах не работает через https. а что с FF - не ясно. поначалу на сервере открывалось, потом перестало. хотя вроде бы ничего не менял.
саппорт яндекса ответил : Попробуйте в антивирусной программе зайти в сканирование ПК — Настройка сканирования — Интернет и электронная почта — Защита доступа в Интернет и защиты от фишинга — Настройка модуля сканирования — HTTP. HTTPS — Не проверять протокол HTTPS.

пробовал на локальной машине с виндой (там касперский стоит) - не помогло.
впрочем подозреваю дело в кривой настройке прокси. а потому прошу вашей помощи.

заранее спасибо.

[asy]

проблема в том, что школьная почта хранится на яндексе. На сервере работает Thunderbird и отлично получает/отправляет почту по IMAP. на локальных машинах не получается ни Thunderbird настроить, ни корректно октрыть веб интерфейс яндекса через Firefox.
TB - говорят на форумах не работает через https.

Что значит "говорят" ? http - это web-протокол. Он не имеет отношения к почте. А TB - почтовый почтовый клиент. Это протоколы pop/imap/smtp. То, что понадели всяких web-интерфейсов для работы с почтой через web-браузер, ни в коем случае не делает http почтовым протоколом.

[artflam]

под говорят я имел ввиду вот что (видимо совсем не корректно выразился я) - http://forum.mozilla-russia.org/viewtopic.php?pid=205236#p205236

имелось ввиду http-прокси, хотя скажу честно, это для меня уже не совсем понятно, хотя и по гуглу ходил и мануалы по прокси читал, далеко не все ясно :( вот и подозреваю потому, что проблема с настройками прокси...

[asy]

под говорят я имел ввиду вот что (видимо совсем не корректно выразился я) - http://forum.mozilla-russia.org/viewtopic.php?pid=205236#p205236

Ну да. Это от непонимания. Это всё равно, что пытаться прокачать гравий через водопроводную трубу вместо транспортёрной ленты. Он http-проксти, а не pop/imap прокси. И всё тут. А то, что, допустим, icq работает через http-прокси, так это специально протокол так разработали дополнительно. Инкапсуляцией pop/imap/smtp в http, в рамках добавления такого функционала к почтовым серверам, никто никогда не занимался. На сколько я в курсе. Слышал только про разработку софта для организации тонеля через http-прокси, но это, разумеется, подразумевает установку специального сервера за прокси, который будет терминировать тонель и преобразовывать протоколы к нормальному виду.

имелось ввиду http-прокси, хотя скажу честно, это для меня уже не совсем понятно, хотя и по гуглу ходил и мануалы по прокси читал, далеко не все ясно :( вот и подозреваю потому, что проблема с настройками прокси...

Тут можно вести речь только про доступ к веб-интерфейсу из обычного браузера. То есть, как в теме и написано - Firefox. Thunderbird и прочие почтовые клиенты тут не в тему.

[artflam]

под говорят я имел ввиду вот что (видимо совсем не корректно выразился я) - http://forum.mozilla-russia.org/viewtopic.php?pid=205236#p205236

Ну да. Это от непонимания. Это всё равно, что пытаться прокачать гравий через водопроводную трубу вместо транспортёрной ленты. Он http-проксти, а не pop/imap прокси. И всё тут. А то, что, допустим, icq работает через http-прокси, так это специально протокол так разработали дополнительно. Инкапсуляцией pop/imap/smtp в http, в рамках добавления такого функционала к почтовым серверам, никто никогда не занимался. На сколько я в курсе. Слышал только про разработку софта для организации тонеля через http-прокси, но это, разумеется, подразумевает установку специального сервера за прокси, который будет терминировать тонель и преобразовывать протоколы к нормальному виду.



ммм, ладно, сам виноват.  не совсем понял, т.к. опыта маловато. поставим вопрос по другому - в моей ситуации т.е. когда инет в локальную сеть раздается через прокси, можно заставить TB работать на локальной машине? если да, то в какую сторону копать надо? хотеллось бы и самому разобраться, но запутался окончательно в терминах :(.

имелось ввиду http-прокси, хотя скажу честно, это для меня уже не совсем понятно, хотя и по гуглу ходил и мануалы по прокси читал, далеко не все ясно :( вот и подозреваю потому, что проблема с настройками прокси...

Тут можно вести речь только про доступ к веб-интерфейсу из обычного браузера. То есть, как в теме и написано - Firefox. Thunderbird и прочие почтовые клиенты тут не в тему.

так там вроде как раз про TB разговор идет(http://forum.mozilla-russia.org/viewtopic.php?pid=205236#p205236)
а по поводу доступа к веб-интерфейсу - тоже проблема - см. приложенные скриншоты к первому посту.


да, вот еще что добавлю. TB в локалке стоит на винХР машине. и надо сказать при включении, он устанавливает соединение (стандартное окно ТБ делится на две части. вверху письма, внизу добро пожаловать в ТБ. когда не было соединения вместо надписи добро пожаловать было - ошибка соединения с сервером). Теперь же ТБ приветствует, но зависает на соединении с imap.yandex.ru 

[palex]

если правильно понял, то у Вас так - все ходят в инет через прокси, в браузерах и на сервере(он тоже идет через прокси?) и на клиентах не корректно отображается, а Thunderbird не работает только на клиентах.
Возможно, что Thunderbird на сервере идет мимо прокси(просто имеет такую возможность), а в конфигурации прокси (squid ? ) нет параметров acl типа

Код: [Выделить]

acl Safe_ports port 443    # HTTPS
acl SSL_ports port 443    # HTTPS (C)
http_access deny !Safe_ports   
http_access deny CONNECT !SSL_ports
  опять-таки, предполагаю, что часть контента страниц веб-почты может идти по http, а часть по https. Поэтому так криво отображается.

[artflam]

если правильно понял, то у Вас так - все ходят в инет через прокси, в браузерах и на сервере(он тоже идет через прокси?) и на клиентах не корректно отображается, а Thunderbird не работает только на клиентах.
Возможно, что Thunderbird на сервере идет мимо прокси(просто имеет такую возможность), а в конфигурации прокси (squid ? ) нет параметров acl типа

Код: [Выделить]

acl Safe_ports port 443    # HTTPS
acl SSL_ports port 443    # HTTPS (C)
http_access deny !Safe_ports   
http_access deny CONNECT !SSL_ports
  опять-таки, предполагаю, что часть контента страниц веб-почты может идти по http, а часть по https. Поэтому так криво отображается.

а говорят еще что телепатов не существует :)

вы понял верно. на сервере инет идет через прокси, а ТБ на самом деле в обход. дело в том что в браузере на сервере прописаны настройки прокси и инет есть, а в ТБ я ничего не писал. он сам заработал. :)  яндекс (только этот сайт, а точнее его внутренние страницы) криво отображаются как на сервере, так и на клиентах. (кстати опять же наверно неясно выразился, на сервере какое-то время внутренние страницы яндекса работали.)

в сквиде параметры посмотрю. на память такое само-собой не помню.

по поводу http и https - можно ли в таком случае разрешить доступ и по обоим протоколам? (в веб-интерфейсе сервера отмечал галочками разрешить HTTP и HTTPS, но возможно, этого не достаточно?

[palex]

можно и по обоим протоколам, пример-то я привел из реального конфига прокси, там это работает(наверное ).
 По части "галочек" не знаю как оно реагирует, предпочитаю конфиг просто править. Когда-то шаблоны для "галочек" squid альтератора лежали в /etc/caterva/squid/squid.conf . Посмотрите там, может там что есть.
Для начала проще проверить любой другой сайт по https, а то может я в сторону от истины увожу

[asy]

поставим вопрос по другому - в моей ситуации т.е. когда инет в локальную сеть раздается через прокси, можно заставить TB работать на локальной машине? если да, то в какую сторону копать надо?

Конечно можно. Через прокси.
Но не http. Например, компьютер с NAT - это тоже прокси-сервер, по большому счёту. А NAT уже обеспечивает работу почти любых протоколов. Либо можно использовать какой-то специфический pop/imap/smtp-прокси, delegate, к примеру (только его в репозитарии нет - свободен только для некоммерческого использования). Хотя delegate, вообще, мультипротокольный, http он умеет в том числе

[artflam]

понятно. по поводу NAT посмотрю на сервере. такую аббревиатуру встречал. проблема вся в интернет-фильтрации, сейчас не уверен, но возможно, NAT как раз таки и нельзя использовать из-за настроек инет фильтра, но... опять же не уверен, и подтвердить свои слова не могу в данный момент.

проверю настройки на сервере и отпишусь сюда.

спасибо за помощь.

[asy]

NAT как раз таки и нельзя использовать из-за настроек инет фильтра,

Это всё та же беда с терминологией. Интернет - это не только веб. А фильтр Вам нужен для веб-контента, очевидно. Ну так не разрешайте NAT для http и https. Или, даже, наоборот, разрешайте только для icmp, pop, imap и smtp.

[palex]

asy,

NAT - это тоже прокси-сервер, по большому счёту.

наверное по очень большому счету
В данном случае, я так понимаю, нужна фильтрация посредством прокси, т.к. школа, и почта на яндексе т.к. опять-таки школа.
А может пойдет вариант включения NAT с последующим DROP-ом всех пакетов из локалки, идущих не на pop,smtp,imap вовне. Ну и как-то  прокси желательно не порубить. Соответственно, нужно написать правила для iptables.
В итоге - клиенту пишем умолчальный шлюз через сервер, в браузере ему пишем прокси:порт, thunderbird идет прямиком в инет на почтовики, а все иные протоколы отрубаются от FORWARD-а дабы не нарушать "политику партии"...
Как-то так видится...
asy, если такой вариант имеет право жить - подскажите человеку написание правил, сам слегка отдалился от предметной области.
Ну, вот пока чепятал, все уже почти решено....

[asy]

наверное по очень большому счету

достаточно посмотреть перевод слова proxy.

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

А вот это мне, наверное, не стоит делать: идеологически верно это через Альтератор сделать, в данном случае, а я привых руками, по-старинке, даже без "service iptables"...

Кстати, что касается непосредственно Squid, это кэширующий http/ftp прокси-сервер. Основное тут - кэширующий. Все остальные его возможности - просто то, чем оброс кэш. Правда сейчас, в условиях развития динамического контента, кэширование уходит на второй план.

[artflam]

наверное по очень большому счету

достаточно посмотреть перевод слова proxy.

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

А вот это мне, наверное, не стоит делать: идеологически верно это через Альтератор сделать, в данном случае, а я привых руками, по-старинке, даже без "service iptables"...

Кстати, что касается непосредственно Squid, это кэширующий http/ftp прокси-сервер. Основное тут - кэширующий. Все остальные его возможности - просто то, чем оброс кэш. Правда сейчас, в условиях развития динамического контента, кэширование уходит на второй план.

мда.. насчет терминологии вы правы. но это дело наживное :).
а вот про кэширование сквида, что-то не совсем понял. как я понял, сквид не самый лучший вариант для фильтрации трафика?

[asy]

а вот про кэширование сквида, что-то не совсем понял. как я понял, сквид не самый лучший вариант для фильтрации трафика?

Это смотря какого. Если трафика по тем протоколам, на работу с которыми он рассчитан, то почему бы и нет ? Я просто напомнил про его основное предназначение - http/ftp кэш, который был призван когда-то решать проблему экономии трафика.