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

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

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

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

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

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

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

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

-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

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

-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

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

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

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

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

разумеется -t nat

iptables -t nat -I POSTROUTING итд...

вот за тебя порты нагуглил: http://help.mail.ru/mail-help/mailer/popsmtp

переписать ещё за тебя прошлые команды?

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

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

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

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

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

пиши как надо — pop3.mail.ru и smtp.mail.ru, а после почитай книжек побольше

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

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

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

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

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

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

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

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

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

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

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

-t nat

забыл

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

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

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

Развернул 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 это была весьма удобная фича, позволяющая выпустить что угодно куда угодно через прокси. Есть ли аналоги в линуксах?

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

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

На дворе XXI век.

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

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

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

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

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