iptables форвардинг

показывай как делал

ну, у тебя reply не проходит через твой сервер и уходит напрямую клиенту с адреса 10.0.0.3, который благополучно его дропает, ибо ничего про твой форвардинг не знает

так что либо на 10.0.0.3 делать обратное преобразование src ip:port исходящих пакетов для клиента, либо все ответы там завертывать назад на .2, где оно само преобразуется
только вот вопрос: на кой черт нужна такая лапша?

дык а как сделать без лапши?

либо пусть клиент сразу на .3 коннектится, либо сделать нормальный роутинг: на роутере .2 поднять второй сетевой интерфейс, выделить новую подсеть, в этот сегмент подключить сервер, отвечающий за сервис, прописать на нем в качестве шлюза IP-адрес первого сервера-роутера на новом внутреннем интерфейсе; на этом роутере настроить обычный DNAT

iptables -t nat -A PREROUTING -p tcp --dport 4567 -j DNAT --to-destination 10.0.0.3:7654
iptables -t nat -A POSTROUTING -p tcp -d 10.0.0.3 --dport 7654 -j SNAT --to-source 10.0.0.2
iptables -t filter -A FORWARD -d 10.0.0.3 -p tcp --dport 7654 -j ACCEPT

net.ipv4.ip_forward = 1

красота!
а как он клиентов будет различать, если они все будут приходить с адреса 10.0.0.2?

В OP это не требуется.

OP?

No route to host

представим реквест в таком виде: ${src_host}:${src_port} => ${dst_host}:${dst_port}

тогда:

iptables -t nat -A PREROUTING -p tcp --dport ${src_port} -j DNAT --to-destination ${dst_host}:${dst_port}
iptables -t nat -A POSTROUTING -p tcp -d ${dst_host} --dport ${dst_port} -j SNAT --to-source ${src_host}
iptables -t filter -A FORWARD -d ${dst_host} -p tcp --dport ${dst_port} -j ACCEPT

выдаёт No route to host

либо пусть клиент сразу на .3 коннектится, либо сделать нормальный роутинг: на роутере .2 поднять второй сетевой интерфейс, выделить новую подсеть, в этот сегмент подключить сервер, отвечающий за сервис, прописать на нем в качестве шлюза IP-адрес первого сервера-роутера на новом внутреннем интерфейсе; на этом роутере настроить обычный DNAT

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

ан нет, вру! работает, спасибо.

необходимо, чтобы сервер был доступен в том числе отдельно от роутера

дык, а почему не коннектиться напрямую к серверу и в случае сервиса на tcp-7654-порту?

Я не знаю что ты там делаешь и чем тестишь, вот пруф что команды из моего поста рабочие: http://imgur.com/wuoMXcs.

C - клиентская виртуалка, F - форвардер, T - таргет.

Блин, а я скрутил виртуалки для проверки :-/

сервер работает внутри небольшой подсети вместе с «роутером». внутри этой подсети к нему должен быть прямой доступ со всех хостов, но наружу он сам по себе роутить ничего не должен. «роутер» на самом деле тоже является серваком, но менее «опасным», поэтому он может смотреть в общую подсеть, и поэтому выступает в роли гейта для конкретных портов сервера.

всё работает, спасибо :)

красота!
а как он клиентов будет различать, если они все будут приходить с адреса 10.0.0.2?

Клиентов можно различать не только по IP-адресу и/или номеру порта.

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

это как заколотить парадный вход, но всех подряд пускать через подсобку :)

это придумал не я, для меня это вынужденное решение

а как он клиентов будет различать, если они все будут приходить с адреса 10.0.0.2?

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

Клиентов можно различать не только по IP-адресу и/или номеру порта.

а как еще?
имеется ввиду не когда все хорошо работает, тогда действительно теоретически может какой-нибудь логин авторизации быть в логах, хотя мы не знаем что там за сервис, а когда у какого-то клиента коннект не устанавливается? в этом случае клиент ничего кроме своего ip сказать не может, даже порт, кстати

кстати, когда много клиентов подключаются с разных адресов одновременно, действительно возникают проблемы

т.е. у тебя так много клиентов, что им tcp-портов на роутере в NAT'е не хватает? :-0
или в чем проблема?