abills.net.ua

Имею желание дать пользователям реальные ip, планирую сделать следующим образом:

Пользователи коннектятся по vpn.
vpn сервер имеет адрес 10.0.0.1, пользователь допустим получит 10.0.0.7
Xочу пользователю выдать белый ip XX.XX.XX.XX
Прописываю этот белый ip на внешнем интерфейсе маршрутизатора
И добавляю в фаервол строчку вида:
iptables -t nat -A PREROUTING --dst XX.XX.XX.XX -j DNAT --to-destination 10.0.0.7

Собственно вопросы:
1. Применим ли такой подход?
2. Есть ли подводные камни?
3. Может быть это делают как-то подругому?
4. Возможно ли $conf{IPN_FW_START_RULE}=?? сделать зависимым от тарифного плана или группы пользователей. Т.к. белые ip будут использовать не все и соответственно не всем надо применять правило для nat.


По поводу 3-го вопроса - мысль в слух:
По идеи можно назначить реальный ip пользователю при подключении по vpn, но становиться непонятно каким должен быть ip сервера. Как то сомнительно, что цепочка 10.0.0.1-------XX.XX.XX.XX заработает...

уууу... как всё запущено...

-j DNAT и -j SNAT две большие разницы однако... man iptables

mich писал(а):По поводу 3-го вопроса - мысль в слух:
По идеи можно назначить реальный ip пользователю при подключении по vpn, но становиться непонятно каким должен быть ip сервера. Как то сомнительно, что цепочка 10.0.0.1-------XX.XX.XX.XX заработает...

Как-то работать будет, но не советую на маршрутизаторе использовать серый IP.
Будут проблемы, особенно связанные с фрагментацией пакетов, точнее с отсылкой управляющих сообщений от маршрутизатора и к нему.

Если под маршрутизатором понимается что-то типа Cisco, то выдавай биилингом пользователям реальные IP, а на маршике пропиши статик-роут в свой сервак:

ip route xxx.xxx.xxx.xxx 255.255.255.0 10.0.0.1

realmarkiz писал(а):Если под маршрутизатором понимается что-то типа Cisco, то выдавай биилингом пользователям реальные IP, а на маршике пропиши статик-роут в свой сервак:

ip route xxx.xxx.xxx.xxx 255.255.255.0 10.0.0.1

Внутри сети провайдера проблем не будет, но вот к примеру этот роутер с серым IP 10.0.0.1 отошлёт ICMP пакет какому-то другому хосту в сети Internet, скажем с "просьбой делать фрагментацию" в ответ на получение пакетов с флагом no-df
и это сообщение никак не дойдёт к адресату

Про SNAT я не писал как о само собой разумеющееся, конечно исходящий трафик клиента будет снатится на белый ip.

роутер с серым IP 10.0.0.1 не отошлет ICMP пакет какому-то другому хосту в сети Internet, т.к. роутер имеет собственный реальный ip, и весь трафик роутера пойдет через этот ip.

Ну вижу принципиальных возражений нет, буду пробовать.
Если что получиться отпишусь позже

А зачем нужно реальный ип прятать за нат? Достаточно заиметь на интерфейсе роутера смотрящем в инет реальный ип и на вышестоящем маршрутизаторе смаршрутизировать за него выданную Вам подсеть. Дальше просто прописуете ип из этой подсети пользователю и все работает посредствам роутинга

sopov верно говорит, к тому же если пользователи цепляются по VPN, то можно им указывать для подключения (я так понимаю PPtP) серый адрес сервера, а в самой ppp сессии свой и адрес пира выдавать реальные.
Тогда вообще всё пучком должно быть без лишних натов.

чёт я не въеду, зачем какие-то извращения с натом, роутингом... На серверный конец туннеля абсолютно любой адрес поцепить можно (в том числе и тот, который уже например на изернете висит). А на клиентский конец - публичный ип и вешать. Поднимется туннель - маршрут на этот ип пропишется через dev ppp?, а со стороны клиента вынь или кто там у тебя дефолт на туннель пропишет...

Все, всем спасибо, понял.

Смущал меня серверный серый ip...

Tux писал(а):

realmarkiz писал(а):Если под маршрутизатором понимается что-то типа Cisco, то выдавай биилингом пользователям реальные IP, а на маршике пропиши статик-роут в свой сервак:

ip route xxx.xxx.xxx.xxx 255.255.255.0 10.0.0.1

Внутри сети провайдера проблем не будет, но вот к примеру этот роутер с серым IP 10.0.0.1 отошлёт ICMP пакет какому-то другому хосту в сети Internet, скажем с "просьбой делать фрагментацию" в ответ на получение пакетов с флагом no-df
и это сообщение никак не дойдёт к адресату

iptables -I FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

это насчёт фрагментации. это правило во всех TCP SYN пакетах будет править поле MSS (Maximal Segment Size) в значение минимального MTU - 40(хедер тсп) ифейсов рутера, через которые проходит пакет. и хрен с ним что ICMP пакет не дойдёт - коннекшн будед

можно и конкретное значение мсс задать наскродько помню... man iptables

Я в курсе что можно править TCPMSS, но это вынужденное нарушение стандартов TCP/IP, кроме всего прочего может влиять на максимальную скорость передачи по TCP соединению и увеличивает служебный трафик, т.к. в обратную сторону нужно отсылать на каждый пришедший пакет ответ о подтверждении приёма этого пакета. В нормальной ситуации ответ отсылается о подтверждении приема сегмента данных, а сегмент данных может быть многократно больше одного пакета.

Правка TCPMSS - это костыль, применяется многими, в основном благодаря кривости осей от микрософт, или кривости рук системных админов, у большинства из которых вместо упорядоченных знаний в голове калейдоскоп бессвязной информации (обычно эта информация состоит из представления где надо выставить галочки). И которые считают что понимать модель OSI абсолютно ни к чему, ведь есть же галочный GUI

Правка TCPMSS - это костыль, применяется многими, в основном благодаря кривости осей от микрософт, или кривости рук системных админов

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

+1 ran. Для этих целей лучше использовать бордер. Ну топикстартер разобрался вобщем...

ps. Раз уж мы тут так хорошо сидим давайте попросим модеров создать ветку для околоабилсовых проблем...

sopov писал(а):ps. Раз уж мы тут так хорошо сидим давайте попросим модеров создать ветку для околоабилсовых проблем...

а нету тута модеров... Один Site Admin тока... Вот и трещат о чём не попадя