Pptp Path Through (Нужны модули ядра для протокола GRE)

[Uncle Bob]

Доброго времени суток.

Дистр. SuSE 10.1
На шлюзе настроена трансляция адресов. Однако для трансляции и трэкинга PPTP-туннелей необходимы 4 модуля. 2 из них я нашел в системе и подгрузил, а остальные - ip_nat_proto_gre, ip_conntrack_proto_gre отсутствуют. Читал в интернете, что просто установить эти два модуля нельзя - надо заново конфигурировать ядро, чего делать не хочется. Тем более шлюз постоянно "in use".
Есть ли возможность решить эту ситуацию без пересборки ядра?

Спасибо.

[Uncle Bob]

нашел в инете вот еще что:

pptpproxy - forward a PPTP VPN connection through a Linux firewall
Пояснение PPTP прокси решающий проблему создания PPTP туннеля из интранет сети находящейся за транслятором адресов.

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

[nyncuk]

пробовал пптппрокси - не заработал
а ядро наверно лучше пересобрать
может даже оставить то что есть + добавить свежий иптаблес
отпишись плз как сделаешь натинг пптп

[Uncle Bob]

Народ, выручайте! точно никак без пересборки не обойтись?
Сегодня слышал (уже не первый раз), что можно осуществить пропускание GRE-пакетов, открыв 47-й TCP-порт????????
Непойму причем здесь TCP. Насколько помню, 47 - это номер протокола GRE в стеке IP, это случайное совпадение или так задумано?

[nyncuk]

http://www.cyberguard.info/snapgear/faqoma.../cache/398.html

соль:
PPTP clients initiate all connections using TCP port 1723 which allocates session ID's for the particular connection. Once the initial handshaking is done using this port, communications switch to the GRE protocol which is protocol number 47, which also contain the session ID's that were setup by the TCP 1723 control connection. The TCP 1723 control connection is then only used for echo requests and echo replies between the client and server so that both ends know the remote end is still alive. The TCP 1723 control connection is also used to terminate the VPN connection.

вкратце перевожу - по порту 1723 начинается соединение, Высокие Договаривающиеся Стороны добазариваются про идентификатор (бирочку)
потом переключаются на туннель, работают и маркируют пакеты биркой
1723 нужен типа для пингов, мол жывы стороны или нет, ну и для окончания обмена в туннеле

думаю слова ESTABLISHED, RELATED для иптаблеса самое то

З.Ы. Ковыряю натинг пптп вторую неделю - результата ноль. Проблема в множественных сессиях из одной подсети к одному впн-серверу в мире.



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

кусочек скрипта иптаблеса который грузит модули:

/sbin/modprobe nf_nat_pptp
if [ $? -eq 0 ]; then
echo "load nf_nat_pptp................. OK "
else
echo "load nf_nat_pptp ERROR!"
fi

/sbin/modprobe nf_nat_proto_gre
if [ $? -eq 0 ]; then
echo "load nf_nat_proto_gre............ OK "
else
echo "load nf_nat_proto_gre ERROR!"
fi

/sbin/modprobe nf_conntrack_pptp
if [ $? -eq 0 ]; then
echo "load nf_conntrack_pptp........... OK "
else
echo "load nf_conntrack_pptp ERROR!"
fi

/sbin/modprobe nf_conntrack_proto_gre
if [ $? -eq 0 ]; then
echo "load nf_conntrack_proto_gre...... OK "
else
echo "load nf_conntrack_proto_gre ERROR!"
fi



идея понятна?

[Uncle Bob]

непосредственно с пптп-протоколом проблем нет. проблема в том, что та часть туннеля, по которой непосредственно передаются инкапсулированные ип-пакеты (т.е. протокол GRE) остается "непонятой" маршрутизатором.
Некоторые умудряются решать эту проблему путем открытия 47-го tCP-порта, чего я понять не могу...

[Uncle Bob]

кусочек скрипта иптаблеса который грузит модули:

/sbin/modprobe nf_nat_pptp
if [ $? -eq 0 ]; then
echo "load nf_nat_pptp................. OK "
else
echo "load nf_nat_pptp ERROR!"
fi

/sbin/modprobe nf_nat_proto_gre
if [ $? -eq 0 ]; then
echo "load nf_nat_proto_gre............ OK "
else
echo "load nf_nat_proto_gre ERROR!"
fi

/sbin/modprobe nf_conntrack_pptp
if [ $? -eq 0 ]; then
echo "load nf_conntrack_pptp........... OK "
else
echo "load nf_conntrack_pptp ERROR!"
fi

/sbin/modprobe nf_conntrack_proto_gre
if [ $? -eq 0 ]; then
echo "load nf_conntrack_proto_gre...... OK "
else
echo "load nf_conntrack_proto_gre ERROR!"
fi
идея понятна?

Это понятно. Я только не совсем врубаюсь, почему нельзя просто установить недостающие модули.
nyncuk,
почему пишешь, что результата ноль? У тебя и после подключения все небходимых модулей не пашет?

[nyncuk]

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

да
стремаюсь маскарадить
думаю что простой маскарад зело опасен - за неделю получил от прова три мессаги что от меня идет спам
ну ясно что не от меня лично а от айпишника на котором висит опекаемый мною тазик
если бы не сегодняшняя запланированная пьянка - то остался бы на работе и потестил "последнюю надежду"
гейт в работе - много людей рубают капустку
экпериментировать отведены очень узкие временные окна

установить низзя потому что их нету в системе

[Uncle Bob]

Кстати, меня вдруг мысть посетила.
Для случая многих пользоватлей из внутренней сети понятно - нужна поддержка натинга GRE, т.к. нужно просматривать GRE-пакет на предмет идентификатора канала.
А если у меня только один клиент внутри сети, может итак попрет, лишьбы модули для pptp были загружены? GRE-пакеты будут обрабатываться только на уровне IP, но в случае одного клиента глубже ведь и не надо копать?

[nyncuk]

для одного? хехе
проще в разы
один и так преть по умолчанию
искаропки(тм)
причем подозреваю что и без модулей поедет
напиши как чего делал и чего получил

[nyncuk]

для очистки совести поставил pptpproxy
работает