LINUX.ORG.RU
ФорумAdmin

Перенаправление запросов почтовых клиентов во внешнюю сеть (возможно платина)

 , ,


0

1

Прошу помощи. Гугление дает маны на проброс порта с внешних интерфейсов на внутренние сервисы, мне же нужно сделать наоборот.

Как оно работало: Был сервачок с оффтопиком на борту, на нем крутился юзергейт, почтовые клиенты коннектились таким образом

Запрос почтового клиента pop -> 192.168.0.252:111 -> pop.mail.ru:110

Запрос почтового клиента smtp -> 192.168.252:26 -> smtp.mail.ru:25

То есть в TheBat вместо реального сервера прописывался внутренний, который перенаправлял запросы на внешний.

В качестве почтового клиента у всех The Bat (сеть из выньдовых машин). Каждый отдел пользовался почтой со своими логинами-паролями, то есть Usergate банально слушал трафик на указанных портах и перенаправлял его с себя на mail.ru (образно).

В качестве основной прокси UG не использовался давно, вместо него есть ubuntu со сквидом. Машинка с usergate'ом померла, и вместо того, чтобы ее поднимать было принято решение передать его функции шлюзу со сквидом.

Насколько я понял, сквид таким образом перенаправлять трафик не умеет, поэтому нужен iptables, однако

- прокси не прозрачный

- у юзверей не прописан шлюз по-умолчанию, только прокси в браузере

- у TheBat нет возможности указать прокси штатными средствами

- прокси со сквидом можно указать в качестве шлюза по-умолчанию, тогда можно ходить в инет минуя сквид. Но давать такой доступ всем не комильфо

Шлюз со сквидом ходит в инет через другой шлюз. В iptables есть только одно правило:

-A POSTROUTING -o eth0 -j MASQUERADE
Что делает его банальным шлюзом в интернеты.

Как можно реализовать перенаправление запросов так, чтобы оно работало так же, как на Usergate?

Запрос почтового клиента pop -> 192.168.0.252:111 -> pop.mail.ru:110

Запрос почтового клиента smtp -> 192.168.252:26 -> smtp.mail.ru:25

Зачем? А напрямую сразу нельзя ?

vlb ★★★
()
Ответ на: комментарий от vlb

Нет, нельзя. Есть пользователи, которые ходят на прямую, есть те, кто через прокси, при этом и шлюз и прокси на одной машине :\

Некоторые злоупотребляют «прямым» выходом и забивают канал торрентами, радио, и т. п. - squid таким пользователям канал режет.

Если нет вариантов выпустить TheBat через сквид или средствами iptables (не на прямую), то готов выслушать другие варианты.

stiflerwen
() автор топика

юзергейт — говна кусок, причём не он в этом виноват, а его «администраторы», сученята некомпетентные

-A POSTROUTING -o eth0 -d 94.100.180.74 -p tcp --dport 110 -j MASQUERADE -A POSTROUTING -o eth0 -d 94.100.180.160 -p tcp --dport 25 -j MASQUERADE -A POSTROUTING -o eth0 -d 217.69.139.160 -p tcp --dport 25 -j MASQUERADE

anonymous
()
Ответ на: комментарий от anonymous

сраное форматирование!

-A POSTROUTING -o eth0 -d 94.100.180.74 -p tcp --dport 110 -j MASQUERADE 
-A POSTROUTING -o eth0 -d 94.100.180.160 -p tcp --dport 25 -j MASQUERADE 
-A POSTROUTING -o eth0 -d 217.69.139.160 -p tcp --dport 25 -j MASQUERADE
anonymous
()
Ответ на: комментарий от stiflerwen

как ты её набираешь, что без фильтров протокола, порта и назначения, она у тебя «превращает в обычный шлюз», а с моими добавками пишет ошибку?

anonymous
()
Ответ на: комментарий от anonymous

Соединение, кстати, TLS.

Если перед командой вашей командой добавить -t NAT, то правило добавляется, но бат пишет, что

!15.04.2014, 12:44:37: FETCH - Приветствие TLS не завершено. Удаленный хост принудительно разорвал существующее подключение

stiflerwen
() автор топика
Ответ на: комментарий от anonymous

как ты её набираешь

sudo iptables ...

То правило прописано в iptables.up.rules, который читается при запуске компа. Вот его содержимое:

*nat
:PREROUTING ACCEPT [215:26779]
:INPUT ACCEPT [106:15167]
:OUTPUT ACCEPT [24:1657]
:POSTROUTING ACCEPT [24:1657]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT

stiflerwen
() автор топика
Ответ на: комментарий от anonymous

настройки бата как прописал

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

stiflerwen
() автор топика
Ответ на: комментарий от anonymous

Как он попадет на pop.mail.ru или smtp.mail.ru, если на вендовом компе шлюз не прописан?

Если прописать шлюз, то он и без правил ходить будет.

stiflerwen
() автор топика
Ответ на: комментарий от anonymous

Мне не надо пускать его напрямую. Если выпускать комп через шлюз, придется фильтровать кучу ненужного трафика.

Мне надо запрос бата на 192.168.0.231:995 перебросить на 217.69.139.160:995

Неужели у такого убожества как UG такая возможность есть, а в iptables нет?

stiflerwen
() автор топика
Ответ на: комментарий от stiflerwen

да блин. ненадо тебе ничего фильтровать, чо ты такой тугой? выпускай наружу только pop3 и smtp на мылору, а правило, которое всё выпускает, закомментируй. И шлюз конечно пропиши. Веб кому-то понадобится — настрой сквид, он на открытом http может прозрачным быть.

anonymous
()
Ответ на: комментарий от anonymous

Так сделать нельзя, потому что в организации 100+ машин и некоторым «полубогам» через этот же шлюх надо разрешать всякую хрень вроде торрентов, скайпов, некоторого пропиретарного софта, танков и т. п., то есть ежели я таким макаром порежу все, кроме smtp и pop от мылору, это ни к чему хорошему не приведет ибо много чего отвалится в таком случае.

Именно поэтому я создал эту тему на форуме, узнать, есть ли решение, позволяющее пробросить порт вышеописанным способом, причем так, чтобы бат думал, что получает мыло напрямую с сервера, как было с UG.

stiflerwen
() автор топика
Ответ на: комментарий от stiflerwen

а, так тебе тогда филтер надо теребить, в котором ты пропишешь разрешения в цепочке форвардинга от «полубогов» к танкам, а после поставишь реджект

anonymous
()

мне же нужно сделать наоборот

Ну так и сделай наоборот.
Какая нафиг разница.

thesis ★★★★★
()
Ответ на: комментарий от stiflerwen

мне почему-то кажется, что такое не получится, потому что TLS, а он проверяет много чего, то есть, выполняет свои обязанности :)

та же самая тема с прозрачным сквидом https, без своего сертификата не получится

leader32
()
Ответ на: комментарий от leader32

Хорошо, давайте отбросим сквид и iptables, другие решения есть? Ведь usergate каким-то образом это умел? При этом он умел пробросить любой коннект на любой ip/порт, причем по доменному имени.

stiflerwen
() автор топика
Ответ на: комментарий от leader32

Развернул usergate, проверил со стандартными портами POP/SMTP - работает. Проверил такое же соединение через TLS - не работает, ибо в таком случае имя сервера перестает соответствовать указанному в сертификате.

Значит, для TLS придется на виндовых машинах прописывать отдельные маршруты до mail.ru вида

route -P ADD 217.69.139.74 192.168.0.231
route -P ADD 217.69.139.160 192.168.0.231
route -P ADD 94.100.180.160 192.168.0.231

Иначе указывать шлюз по-умолчанию.

Тем не менее, у usergate это была весьма удобная фича, позволяющая выпустить что угодно куда угодно через прокси. Есть ли аналоги в линуксах?

stiflerwen
() автор топика
Ответ на: комментарий от stiflerwen

а можешь глянуть, https там он может прозрачно проксировать?

кстати, pf, который фряшный файервол, умеет TPROXY, как и новые версии iptables с модулями. Может, они через него это делают?

leader32
()
Ответ на: комментарий от leader32

не забыл, я знал, что это кусок дампа iptables-save, где nat уже есть

anonymous
()
Ответ на: комментарий от stiflerwen

оставляй как есть одну строку с masquerade, но добавь фильтры, которые будут управлять доступом — там десяток-другой почти одинаковых строк будет в зависимости от аппетитов твоих жирных бездельников, а после укажи всем правильный шлюз по-умолчанию, и всё будет ок работать без странных выдумок

anonymous
()
Ответ на: комментарий от post-factum

надо же нести добро и просвещение, а не удовлетворять сиюминутные потребности в костылях.

anonymous
()
Ответ на: комментарий от stiflerwen

Тем не менее, у usergate это была весьма удобная фича, позволяющая выпустить что угодно куда угодно через прокси. Есть ли аналоги в линуксах?

Любой tcp-proxy умеет, гугли. Даже xinetd умеет в режиме redirector. Только у xinetd есть маленькая проблема, он резольвит имя в момент собственного запуска, а не тогда, когда клиент подключается. Иногда это неправильно.

anto215 ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.