Имею желание дать пользователям реальные 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 заработает...
Белый ip
Re: Белый ip
Как-то работать будет, но не советую на маршрутизаторе использовать серый IP.mich писал(а):По поводу 3-го вопроса - мысль в слух:
По идеи можно назначить реальный ip пользователю при подключении по vpn, но становиться непонятно каким должен быть ip сервера. Как то сомнительно, что цепочка 10.0.0.1-------XX.XX.XX.XX заработает...
Будут проблемы, особенно связанные с фрагментацией пакетов, точнее с отсылкой управляющих сообщений от маршрутизатора и к нему.
Человек должен думать, машина - работать
-
realmarkiz
- Сообщения: 95
- Зарегистрирован: Сб июн 24, 2006 5:38 pm
Внутри сети провайдера проблем не будет, но вот к примеру этот роутер с серым IP 10.0.0.1 отошлёт ICMP пакет какому-то другому хосту в сети Internet, скажем с "просьбой делать фрагментацию" в ответ на получение пакетов с флагом no-dfrealmarkiz писал(а):Если под маршрутизатором понимается что-то типа Cisco, то выдавай биилингом пользователям реальные IP, а на маршике пропиши статик-роут в свой сервак:
ip route xxx.xxx.xxx.xxx 255.255.255.0 10.0.0.1
и это сообщение никак не дойдёт к адресату
Человек должен думать, машина - работать
Про SNAT я не писал как о само собой разумеющееся, конечно исходящий трафик клиента будет снатится на белый ip.
роутер с серым IP 10.0.0.1 не отошлет ICMP пакет какому-то другому хосту в сети Internet, т.к. роутер имеет собственный реальный ip, и весь трафик роутера пойдет через этот ip.
Ну вижу принципиальных возражений нет, буду пробовать.
Если что получиться отпишусь позже
роутер с серым IP 10.0.0.1 не отошлет ICMP пакет какому-то другому хосту в сети Internet, т.к. роутер имеет собственный реальный ip, и весь трафик роутера пойдет через этот ip.
Ну вижу принципиальных возражений нет, буду пробовать.
Если что получиться отпишусь позже
Достаточно заиметь на интерфейсе роутера смотрящем в инет реальный ип и на вышестоящем маршрутизаторе смаршрутизировать за него выданную Вам подсеть. Дальше просто прописуете ип из этой подсети пользователю и все работает посредствам роутингачёт я не въеду, зачем какие-то извращения с натом, роутингом... На серверный конец туннеля абсолютно любой адрес поцепить можно (в том числе и тот, который уже например на изернете висит). А на клиентский конец - публичный ип и вешать. Поднимется туннель - маршрут на этот ип пропишется через dev ppp?, а со стороны клиента вынь или кто там у тебя дефолт на туннель пропишет...
iptables -I FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtuTux писал(а):Внутри сети провайдера проблем не будет, но вот к примеру этот роутер с серым IP 10.0.0.1 отошлёт ICMP пакет какому-то другому хосту в сети Internet, скажем с "просьбой делать фрагментацию" в ответ на получение пакетов с флагом no-dfrealmarkiz писал(а):Если под маршрутизатором понимается что-то типа Cisco, то выдавай биилингом пользователям реальные IP, а на маршике пропиши статик-роут в свой сервак:
ip route xxx.xxx.xxx.xxx 255.255.255.0 10.0.0.1
и это сообщение никак не дойдёт к адресату
это насчёт фрагментации. это правило во всех TCP SYN пакетах будет править поле MSS (Maximal Segment Size) в значение минимального MTU - 40(хедер тсп) ифейсов рутера, через которые проходит пакет. и хрен с ним что ICMP пакет не дойдёт - коннекшн будед
можно и конкретное значение мсс задать наскродько помню... man iptables
Я в курсе что можно править TCPMSS, но это вынужденное нарушение стандартов TCP/IP, кроме всего прочего может влиять на максимальную скорость передачи по TCP соединению и увеличивает служебный трафик, т.к. в обратную сторону нужно отсылать на каждый пришедший пакет ответ о подтверждении приёма этого пакета. В нормальной ситуации ответ отсылается о подтверждении приема сегмента данных, а сегмент данных может быть многократно больше одного пакета.
Правка TCPMSS - это костыль, применяется многими, в основном благодаря кривости осей от микрософт, или кривости рук системных админов, у большинства из которых вместо упорядоченных знаний в голове калейдоскоп бессвязной информации (обычно эта информация состоит из представления где надо выставить галочки). И которые считают что понимать модель OSI абсолютно ни к чему, ведь есть же галочный GUI
Правка TCPMSS - это костыль, применяется многими, в основном благодаря кривости осей от микрософт, или кривости рук системных админов, у большинства из которых вместо упорядоченных знаний в голове калейдоскоп бессвязной информации (обычно эта информация состоит из представления где надо выставить галочки). И которые считают что понимать модель OSI абсолютно ни к чему, ведь есть же галочный GUI
Человек должен думать, машина - работать
ну а куда деваться, если у меня например рутер с туннельным сервером в приватной сети за натом стоит, а мту разные? Уж лучше пусь тспмсс чем сервер во внешний мир выставлять... да и не хоца мне маскарадить на нём - гемора меньшеПравка TCPMSS - это костыль, применяется многими, в основном благодаря кривости осей от микрософт, или кривости рук системных админов
