Возникла необходимость пробросить трафик минуя traffpro (то есть этот трафик считать не надо). В частности это преславутые pptp и ipsec. На форуме множество людей описывали, что они такие финты проворачивали, но вот реальных действенных конфигов еще никто не выкладывал.

Поэтому вопрос в массы: как настроить iptables так, чтобы часть трафика заворачивалась полностью минуя traffpro?

В свое время далел вот такое для проброса OpenVPN



Вот только тут был отдельный интерфейс, а как быть с протоколами и портами?

Ну примерно так :)

Я уже не раз отписывался в форуме по этому поводу, задайтевопрос в ФАК я там отвечу уже всем один раз :)

Sly, это уже не раз писалось. И FAQ есть.

Voler, я знаю про FAQ. Там есть несколько различных способов сделать проброс, однако я заострил внимание именно на ipsec и pptp потому, что они требуют не простого проброса портов tcp, но и нормальной трансляции, вроде travers nat. На форуме неоднократно поднимался вопрос по ipsec, но ни разу не было ответа.

Кстати, Sly, твой вариант тоже не подходит, ipsec и pptp не используют tun интерфейсы

Я tun интерфейсы для примера привёл, можно интерфейсы вообще не указывать а делать по ip типа
-s ip_src
-d ip_dst

Ну тогда давайте в этой теме и ответим на поставленный вопрос конкретно? Исходные данные: сервер три-в-одном (traffpro +ipsec + pptp)

В оригинале для ipsec нужно всего лишь 4 правила


При этом пакеты категорически нельзя изменять (маскарад, простой nat и mangle - не вариант)

Для pptp нужны 2 правила


А теперь нужно понять, как, минуя traffpro, направить этот трафик на демоны, обслуживающие pptp и ipsec

Вопрос эти демоны в белой сети или в серой?
если в белой то не получится, если в серой то проблем нету собственно, тем более что пакеты traffpro не меняет и iptables тоже если явно не указать это.


Ещё одно уточнение, похоже здесь ошибочка, если демон находится на этом же сервере то требуется:
iptables -I INPUT -p udp --dport 500 -j ACCEPT
iptables -I OUTPUT -p udp --sport 500 -j ACCEPT
иначе просто будет проблема, не факт что демоны не перебросят работу на другой порт, и ещё момент, если включён редирект на авторизацию то такое правило не прокатит, там в таблицу mangle вставлять это нужно в цепочки PREROUTING и POSTROUTING

Продолжаем творить безобразие ;-)

1)pptp с traffpro работает без нарекания. Достаточно в самом traffpro разрешить для сервера на вход порты 1723 и 47 порты (через web-админку). В этом случае traffpro не будет обсчитывать vpn трафик пользователей pptp, однако сможет контроллировать доступ пользователей в сеть через шлюз (знаю, что система пользователь->интернет->сервер->интернет выглядит странно, но именно это и было необходимо).
Если нужно обсчитывать всё - покупайте traffpro с встроенным демоном pptp
2)ipsec без танцев с бубном с traffpro не работает. Вернее работает только на половину. При открытии на сервере на вход портов 50 и 500 IKE подключение устанавливается, но потом все пакеты дропаются натом. В ближайшие дни буду пытаться настроить всё по совету товарища assket. Как настрою - отпишусь

Так. С ipsec всё непонятно. Нужна помощь в маршрутизации. При попытке выключить NAT в traffpro и попытаться натить всё самому, не вышло ровным счетом ничего. Еще раз попробовал поработать с traffpro. Соединение по ipsec устанавливается, шлюз на обратной стороне туннеля пингуется, однако всё, что находится по ту сторону туннеля не пингуется. Да и сам шлюз доступен только по icmp. Судя по всему, какой-то затык в маршрутах :(

Беру свои слова из предыдущего поста обратно
Итак, для того, чтобы работал ipsec совместно с traffpro без подсчета трафика пользователей ipsec (трафик будет начисляться на сервер) необходимо:

1) открыть в админке traffpro порты 500 и 50 для доступа к серверу снаружи
2) добавить в traffpro.cfg строку:

3) добавить в traffpro_rule.cfg строку для поднятия NAT:

где eth1 - сетевая карта сервера, смотрящая в интернет
192.168.1.0/24 - ваша внутренняя подсеть
192.168.2.0/24 - подключаемая внешняя подсеть
XXX.XXX.XXX.XXX - внешний ip адрес вашей сетевой карты.

При подготовке данного поста использовались инструкции пользователя assket.

Sly, думаю, всё вышеописаное можно добавить в FAQ
Всем спасибо )

подскажите, все сделал как написано в последнем посте. пакеты все равно уходят к провайдеру, как их все таки направить в подсеть 192.168.201.0/24

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.10.2 * 255.255.255.255 UH 0 0 0 tun1
10.3.0.10 * 255.255.255.255 UH 0 0 0 tun0
192.168.1.0 10.3.0.10 255.255.255.0 UG 0 0 0 tun0
192.168.0.0 * 255.255.255.0 U 0 0 0 eth1
192.168.201.0 192.168.0.100 255.255.255.0 UG 0 0 0 eth1
194.190.59.0 * 255.255.255.0 U 0 0 0 eth0
192.168.10.0 192.168.10.2 255.255.255.0 UG 0 0 0 tun1
169.254.0.0 * 255.255.0.0 U 0 0 0 eth1
default YYY.YYY.YYY.YYY 0.0.0.0 UG 0 0 0 eth0

YYY.YYY.YYY.YYY - провайдер

192.168.201.0 192.168.0.100 255.255.255.0 UG 0 0 0 eth1

Я вот здесь не совсем понял этого правила.

помогло вот это (метод тыка) ;-)
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.0.0/24 -d 192.168.201.0/24 -j SNAT --to-source ZZZ.ZZZ.ZZZ.ZZZ

где ZZZ.ZZZ.ZZZ.ZZZ - внутрений IP сервера
eth0 - внешний интерфейс
192.168.201.0/24 -внешняя подсеть за IPSEC

// 192.168.201.0 192.168.0.100 255.255.255.0 UG 0 0 0 eth1
создается автоматически при поднятии Ipsec тунеля

В таком варианте у Вас будет видна подсеть 192.168.201.0/24 из подсети 192.168.0.0/24, но наоборот Вы не сможете видеть подсети, у Вас проблема скорее всего в том что на другом конце маршруты не прописаны к подсети 192.168.0.0/24