Помогите пожалуйста, срочно нужно...Никак не получается выдать белые IP пользователям через PPPoE, вернее выдавать-то они выдаются, только после этого клиент видит один лишь сервер и всё, далее никуда ничего не проходит...
секция "line" в ppp.conf:
set mru 1464
set mtu 1464
set timeout 36000
allow mode auto
enable pap passwdauth
enable chap
enable pap chap
accept lqr
enable lqr
accept pap
set lqrperiod 10
set radius /etc/radius.conf
disable acfcomp protocomp
deny acfcomp
set ifaddr <внешний ip сервака> HISADDR 255.255.255.255
accept dns
set dns <первичный> <вторичный>В Радиусе - Check атрибуты:
+------+----------+------------------+--------+
| id | UserName | Attribute | Value |
+------+----------+------------------+--------+
| 5463 | ses3 | Password | lalala |
| 5464 | ses3 | Simultaneous-Use | 1 |
+------+----------+------------------+--------+В Радиусе - Reply атрибуты:
+---------+----------+-------------------+-----------------+
| id | UserName | Attribute | Value |
+---------+----------+-------------------+-----------------+
| 3178693 | ses3 | Framed-IP-Netmask | 255.255.255.255 |
| 3177462 | ses3 | Framed-Protocol | PPP |
| 3177268 | ses3 | Framed-IP-Address | 213.148.182.218 |
| 3177513 | ses3 | Framed-MTU | 1496 |
| 3177382 | ses3 | Service-Type | Framed-User |
+---------+----------+-------------------+-----------------+pppoed запущен так:
/usr/libexec/pppoed -P /var/run/pppoedrl0.pid -p line -a line rl0Во время подключения на серваке запустил на интерфейсе tcpdump. В общем, после того, как проходит коннект, tcpdump вываливается в core с сообщением segmentation fault. Хотя все стадии коннекта PPPoE проходят в общем-то успешно: PADI, PADO, PADR, PADS - всё ок! Послылает Welcome, назначает DNS - и после этого segmentation fault (core dumped)...
После этого tcpdump выглядет так:
19:57:18.829858 PPPoE [ses 0x4e] LCP, Echo-Request (0x09), id 5, Magic-Num 0x69c4cd2e, length 16
19:57:18.872729 PPPoE [ses 0x4e] LCP, Echo-Reply (0x0a), id 5, Magic-Num 0x4c2a506d, length 16
19:57:25.548158 PPPoE [ses 0x4e] IP 213.148.182.218 > 213.148.182.254: icmp 40: echo request seq 256
19:57:28.930015 PPPoE [ses 0x4e] LCP, Echo-Request (0x09), id 6, Magic-Num 0x69c4cd2e, length 16
19:57:28.930670 PPPoE [ses 0x4e] LCP, Echo-Reply (0x0a), id 6, Magic-Num 0x4c2a506d, length 16
19:57:30.887363 PPPoE [ses 0x4e] IP 213.148.182.218 > 213.148.182.254: icmp 40: echo request seq 512
19:57:36.389545 PPPoE [ses 0x4e] IP 213.148.182.218 > 213.148.182.254: icmp 40: echo request seq 768
19:57:39.030188 PPPoE [ses 0x4e] LCP, Echo-Request (0x09), id 7, Magic-Num 0x69c4cd2e, length 16
19:57:39.030712 PPPoE [ses 0x4e] LCP, Echo-Reply (0x0a), id 7, Magic-Num 0x4c2a506d, length 16
19:57:41.890254 PPPoE [ses 0x4e] IP 213.148.182.218 > 213.148.182.254: icmp 40: echo request seq 1024
19:57:49.130317 PPPoE [ses 0x4e] LCP, Echo-Request (0x09), id 8, Magic-Num 0x69c4cd2e, length 16
19:57:49.131049 PPPoE [ses 0x4e] LCP, Echo-Reply (0x0a), id 8, Magic-Num 0x4c2a506d, length 16
19:57:57.442053 PPPoE [ses 0x4e] IP 213.148.182.218.2095 > 195.96.187.101.http: S 3936339013:3936339013(0) win 65535 <mss 1424,nop,nop,sackOK>
19:57:59.230477 PPPoE [ses 0x4e] LCP, Echo-Request (0x09), id 9, Magic-Num 0x69c4cd2e, length 16
19:57:59.231212 PPPoE [ses 0x4e] LCP, Echo-Reply (0x0a), id 9, Magic-Num 0x4c2a506d, length 16
19:58:00.458882 PPPoE [ses 0x4e] IP 213.148.182.218.2095 > 195.96.187.101.http: S 3936339013:3936339013(0) win 65535 <mss 1424,nop,nop,sackOK>
19:58:06.394587 PPPoE [ses 0x4e] IP 213.148.182.218.2095 > 195.96.187.101.http: S 3936339013:3936339013(0) win 65535 <mss 1424,nop,nop,sackOK>
19:58:09.330640 PPPoE [ses 0x4e] LCP, Echo-Request (0x09), id 10, Magic-Num 0x69c4cd2e, length 16
19:58:09.331773 PPPoE [ses 0x4e] LCP, Echo-Reply (0x0a), id 10, Magic-Num 0x4c2a506d, length 16
19:58:15.850675 PPPoE [ses 0x4e] IP 213.148.182.218 > 81.176.69.215: icmp 40: echo request seq 1280
19:58:19.430780 PPPoE [ses 0x4e] LCP, Echo-Request (0x09), id 11, Magic-Num 0x69c4cd2e, length 16
19:58:19.431597 PPPoE [ses 0x4e] LCP, Echo-Reply (0x0a), id 11, Magic-Num 0x4c2a506d, length 16
19:58:21.754999 PPPoE [ses 0x4e] IP 213.148.182.218.2096 > 195.96.187.101.http: S 443841978:443841978(0) win 65535 <mss 1424,nop,nop,sackOK>Firewall - flushed!!!
Выглядет так:
allow ip from any to any
deny ip from any to anyПодскажите, пожалуйста где рыть, в чём может быть трабл. Срочно нужно делать, а я застрял на этом и ни в какую...
P.S.: если выдавать внутренние адреса, а затем их NATить - всё окей и всё работает...
213.148.182.254 - это внешний ip твоего роутера? Какой внутренний?
213.148.182.218 - какая маска у клиентов? Они в той же подсети, что и 213.148.182.254?
Укажи все адреса с масками.
213.148.182.218 - это внешний интерфейс сервера. Маска 255.255.255.0
213.148.182.254 - шлюз сети 213.148.182.0/24На внутреннем интерфейсе разве важен IP? Там он - 10.10.3.1
Маска для клиентов естественно 255.255.255.255 - это же P-t-P
маска всегда 255 4 раза. ????Клиентам нужно раздать адреса из сети 213.148.182.0/24
Думаю проблема в следующем. Допустим клиент получил ip 213.148.182.1 и отправил запрос в Инет. Ответ приходит на шлюз 213.148.182.254. Он видит, что получатель находится в тойже подсети (маска 24) и отправляет arp-запрос: какой mac у адреса 213.148.182.1? Т.к. клиент физически не находится в этой подсети, то ответа шлюз не получит. Попробуй на сервере включить proxy_arp (eth0 - внешний интерфейс):echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp
Да! Спасибо большое за идею и совет, в принципе всё получилось. Проблема решена. Но так как у меня FreeBSD, то сабж в этом случае можно решить через sysctl выставив в следующей ветке флаг в "1".net.link.ether.inet.proxyall=1