![]() |
реально ли без выделенного IP получать почту?
ADSL, стоит UserGate 2.8 и Bat! но в юзергейте стоит каскад проксей на прокси прова. http работает прекрасно. бат почту не получает даже с прововского ящика. пишет: FETCH - Сервер сообщает об ошибке: -ERR UserGate: Unauthorized
логин в бате правильный! (с разделителем: [логин на ящик] [разд.] [e-mail адрес]), pop3 сервер - IP компа с юзергейтом. и как быть с SMTP, FTP, ICQ и проч. без внешнего IP? |
Если провайдер выдаёт внешний IP -- тогда проблем нет. Если внутренний, то тогда он должен обеспечивать маскарад и тоже проблем не должно быть. Именно ваша машина подключена именно к провайдеру, или это "самолепная" сеть? Зачем и на какой машине стоит UserGate? С вашей машины внешние адреса пингуются? Например, тот же mail-сервер провайдера?
|
одна машина в сети подключена к интернету, на ней стоит UserGate. с нее сервера инета не пингуются, т.е IP - внутренний. что такое маскарад и как узнать есть ли он?
|
Внутренние ip (10.0.0.0/8, 90.0.0.0/8, 192.168.0.0/16, ещё какие-то -- 172 с чем-то и тп.. -- знатоки поправят) отличаются от внешних только тем, что магистральные маршрутизаторы их не маршрутизируют (сорри за тавтологию). То есть, если у любого из наших раутеров спросить через traceroute, куда они отправят пакет с destination ip == 192.168.0.1, например, они ответят !N (network unreachable).
Сделано это специально затем, чтобы каждый субпровайдер или просто местный админ мог юзать эти адреса локально, не боясь, что выбранный диапазон перекроется с кем-то -- ну, перекроется, что с того? Они по любому снаружи не ходят. Тогда встаёт проблема, как пользователям таких (локальных) ip выходить в наружную сеть? Часто (так проще всего) делают так: на выходе из локальной сети ставят шлюз, одним интерфейсом смотрящий во внутренню сеть и имеющий локальный адрес, а другим -- во внешнюю и имеющий обычный (анонсированный, как его иногда называют) адрес. Все машины внутренней сети имеют default gateway == локальный ip этого шлюза. А когда пакеты внутренних машин проходят наружу через шлюз, он меняет им source ip на свой внешний. Это называется source network address translation, оно же SNAT, оно же маскарад. Таким образом, ответы на такие пакеты идут на шлюз, который держит таблицу соответствия по соединениям, и, согласно это таблице, меняет этим ответам destination ip на внутренний -- чтобы он прошёл на ту машину, откуда шёл запрос. Это если в двух словах. Так вот, если на машине, подключенной к провайдеру, получается (автоматически, кстати, или руками прописывали?) внутренний ip, то провайдер должен держать такой шлюз или давать доступ через прокси-сервер. Насчёт пингов -- чёрт знает, может, их на том же шлюзе и зарезали... Я, к сожалению, в упор не в курсе про UserGate (:)) т.к. не юзаю, поэтом не могу сказать про его настройки ничего путного. А из общих соображений -- как-то так. Можно попробовать спросить у провайдера, как именно он даёт доступ -- через прокси только, или маскарадит. Похоже, что это скорее вопросы взаимодействия с провайдером, чем настройки конкретной программы. |
ok, спасибо за подробное объяснение.
немного проясню ситуацию и поразмышляю. у нас в доме своя сетка 192.168.0.x машина, подключенная к инету (//server), имеет у нас адрес 192.168.0.5 а в локальной сети провайдера - 192.168.105.125 у провайдера есть шлюз, который прописан на //server: 192.168.105.1, который смотрит в другую сетку провайдера формата 10.x.x.x (это можно узнать, если сделать tracert прокси провайдера смашины //server - он идет через хост 10.17.2.1), и в ней как раз находится прокси провайдера. итак, когда мы запрашиваем http с МОЕЙ машины, происходит следующее: браузер обращается к нашему прокси (UserGate), UserGate обращается через шлюз 192.168.105.1/10.17.2.1 к прокси провайдера, а прокси провайдера запрашивает нужный ресурс. при этом не важно, на какой порт послан запрос (80, или 110). сервер отвечает, и все приходит обратно. тут вопрос: у прокси провайдера адрес внешний. как из сети 10.x.x.x его видно, что, еще один шлюз или SNAT, и наверно он от меня запросы НЕ на прокси провайдера отсекает. но если http работает через прокси провайдера, то какая разница какой протокол? почему pop3 не работает? в чем разница? прокси провайдера отсекает обращение к порту 110? |
Если такая колбаса с сетями -- должна быть цепочка шлюзов, из 192.168.0 в 192.168.105, дальше -- в 10.17.2, дальше наружу. Я вот только начинаю путаться с проксями в этом случае -- если бы была полная картина (traceroute, traceroute -I, tcptraceroute), было бы проще, ну да это уже сами сообразите...
Насчёт прокси -- дык, есть разница, какой протокол. Коротко, как работает прокси. Предположим, я спрашиваю у прокси про ya.ru: Код:
[peet@kehlisaari peet]$ telnet localhost 3128 <---- это я иду на порт прокси Код:
[peet@kehlisaari peet]$ telnet peet.spb.ru 110 <---- иду на 110 (pop3) порт своего почтовика Сейчас перечитал схему ещё раз, в общем, если я правильно её понял: Код:
192.168.0.x |
да схема такая, а из "внешних" адресов доступны только прокси провайдера и его почтовые сервера.
ну кажется разобрались. в общем, нельзя: только протокол http. общение с внешним миром исключительно через прокси. поэтому ничего кроме браузера не работает. работает еще (в миранде) MS Messenger, ICQ не пашет.ihc |
Если всё так плохо, то остаётся веб-интерфейс до почты. Опять же, при наличии доступа к http-proxy можно опробовать использовать jabber -- это протокол IM, вроде аськи или msn. Фишкой является (помимо прочего) наличие транспортов к другим IM на стороне сервера. То есть, ставишь jabber-клиента (например, psi с http://psi.affinix.com/ ), заводишь аккаунт а дальше через сервисы jabber логинишься в аську и msn, yahoo и прочее. Вроде бы psi умеет ходить через http-прокси.
|
надо будет попробовать...
|
Время: 12:08. |
Время: 12:08.
© OSzone.net 2001-