modprobe ip_nat_pptp

Во-первых, эти модули должны подгружаться автоматически при необходимости (то есть при использовании iptables).

Во-вторых, модуль сам называется nf_nat_pptp, хотя modprobe должен найти его по алиасу ip_nat_pptp. Но...

В-третьих, вы забыли тот самый modprobe. echo modprobe nf_nat_pptp

Но, повторюсь, по-хорошему самому этот модуль подгружать не нужно.

[root@localhost ~]# modinfo nf_nat_pptp
modinfo: could not find module nf_nat_pptp

Возможно в вашей системе он называется так как вы сказали. Но в centos5 такого нет.

Если iptables сам мог его подгрузить в нужное время я б вообще не парился. Но проблема в том, что он этого не делает во время подключения пользователя из локалки на внешний сервер VPN.

Но в одном вы мне помогли. Спасибо. Надо чтоб запись в файлике была такая:

modprobe ip_nat_pptp

Черт побери, везде указано как просто модуль...

Во-первых, эти модули должны подгружаться автоматически при необходимости (то есть при использовании iptables).

...

Но, повторюсь, по-хорошему самому этот модуль подгружать не нужно.

Инфа 100%? А откуда iptables узнает, что именно вот этот модуль нужен или не нужен?

# modinfo nf_nat_pptp
filename:       /lib/modules/3.5.3-40-desktop/kernel/net/ipv4/netfilter/nf_nat_pptp.ko
alias:          ip_nat_pptp
description:    Netfilter NAT helper module for PPTP
author:         Harald Welte <laforge@gnumonks.org>
license:        GPL
srcversion:     B5BF107FCF24F0319638945
depends:        nf_conntrack_pptp,nf_nat_proto_gre,nf_nat,nf_conntrack
intree:         Y
vermagic:       3.5.3-40-desktop SMP preempt mod_unload modversions 

Возможно в вашей системе он называется так как вы сказали. Но в centos5 такого нет.

Вы случаем ядро сами не пересобирали? depmod не забыли? Впрочем, может в вашей centos как-то по-другому. А попробуйте find /lib/modules | grep nat_pptp

Инфа 100%? А откуда iptables узнает, что именно вот этот модуль нужен или не нужен?

Нет, не сто, ближе к 76%. В общем случае, iptables подгружает модули, которые будут использоваться:

# lsmod  | grep nat
# iptables -L > /dev/null 
# lsmod  | grep nat

А теперь попробуем nat:

# iptables -t nat -L > /dev/null
# lsmod  | grep nat
iptable_nat            13430  0 
nf_nat                 30506  1 iptable_nat
nf_conntrack_ipv4      15055  6 iptable_nat,nf_nat
ip_tables              27717  3 iptable_nat,iptable_raw,iptable_filter
nf_conntrack           98319  8 iptable_nat,nf_nat,nf_conntrack_ipv6,xt_NOTRACK,nf_conntrack_netbios_ns,nf_conntrack_broadcast,nf_conntrack_ipv4,xt_conntrack
x_tables               34102  16 iptable_nat,xt_LOG,xt_tcpudp,xt_limit,xt_pkttype,ip6t_REJECT,ipt_REJECT,ip6table_raw,xt_NOTRACK,iptable_raw,iptable_filter,ip6table_mangle,ip_tables,xt_conntrack,ip6table_filter,ip6_tables

Прямого доказательства, что nat_pptp должен подгружаться (как только будет нужен) я привести не могу, но, например в net/netfilter/nf_conntrack_pptp.c есть MODULE_ALIAS_NFCT_HELPER(«pptp»), а в net/netfilter/nf_conntrack_proto_gre.c struct nf_ct_pptp_master *ct_pptp_info = nfct_help_data(ct). То есть, вроде бы оно тянет одно за другим.

Но голову на отсечение не дам. Может быть, в случае с nat, нужно и руками поднять. Но было бы логично, если бы таки руками модули добавлять не нужно.

Но голову на отсечение не дам. Может быть, в случае с nat, нужно и руками поднять. Но было бы логично, если бы таки руками модули добавлять не нужно.

Дело в том, что напрямую в правилах iptables эти модули не указываются.

Ну так я же говорю, что мешает в ядре применить маску к пакету, и если встретился pptp, при работающем nat'e подгрузить нужный модуль? Там система алиасов и матчинга запутанная, мне лень разбираться — но какие-то зачатки того, о чем я говорю, вроде есть. Но лезть дальше мне лень/некогда.

Ну так я же говорю, что мешает в ядре применить маску к пакету, и если встретился pptp, при работающем nat'e подгрузить нужный модуль?

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

Система на centos 5.8

Может я неверно выбрал способ загрузки модуля?

Не «может быть», а точно. Правильный — прописать строку IPTABLES_MODULES=«ip_nat_pptp» в /etc/sysconfig/iptables-config, после чего сказать service iptables restart

Более того, они не просто могут быть не нужны - они могут мешать нормальной работе.

Мне кажется это неправильным. То есть сама идея использовать факт наличия модуля для управления поведения сетевым стэком... это как-то сильно походит на времена ядер 2.2, 2.4. :-) Вот покрутить значения в /proc/net, после загрузки модуля, это я бы понял.

Но, видимо, текущее поведение чем-то действительно обусловлено...

Спасибо. Но обнаружил проблему. Если ip_nat_ftp и ip_nat_pptp загружаются отлично то, сенсор ipt_NETFLOW грузится криво. Модуль вроде как загружен, но не отсылает данные. При проверке состояния видно, что нет «сети» (в данном случае не знаю как правильно сказать):

shell> cat /proc/net/stat/ipt_netflow
Flows: active 345 (peak 534 reached 0d0h0m ago), mem 18K
Hash: size 8192 (mem 32K), metric 1.0, 1.0, 1.0, 1.0. MemTraf: 424 pkt, 26 K (pdu 8, 396).
Timeout: active 1800, inactive 15. Maxflows 2000000
Rate: 3678 bits/sec, 9 packets/sec; Avg 1 min: 10055 bps, 13 pps; 5 min: 2730 bps, 2 pps
cpu#  stat: <search found new, trunc frag alloc maxflows>, sock: <ok fail cberr, bytes>, traffic: <pkt, bytes>, drop: <pkt, bytes>
Total stat:     24     77    563,    0    0    0    0, sock:      7 0 0, 10 K, traffic: 640, 0 MB, drop: 0, 0 K
cpu0  stat:      0      0      0,    0    0    0    0, sock:      7 0 0, 10 K, traffic: 0, 0 MB, drop: 0, 0 K
cpu1  stat:     24     77    563,    0    0    0    0, sock:      0 0 0, 0 K, traffic: 640, 0 MB, drop: 0, 0 K
sock0: 127.0.0.1:8818, sndbuf 110592, filled 0, peak 0; err: sndbuf reached 0, other 0

Нет последней строчки (в данном примере она есть). Помогает если только выгрузить ручками модуль и потом загрузить. При этом надо еще остановить iptables иначе будет ругаться на то, что данный модуль используется. Пока решения не нашел.