В сообщении от Monday 04 February 2008 16:03:39 Александр Новосёлов написал(а): > Пытаюсь перевести впн сервер с мастера 2.4 на новый 4.1 сервер. > > > Такие вопросы: > > 1) в М2.4 приходилось править максимальное число PTY до 2048 - чтобы > тысячу впн туннелей на один сервер поднять... С новым ядром что делать? > Само зарботает? С опцией delegate не пишет в лог что 1000 сессий может. > Сможет? Для 2.6 ядра ничего делать не надо.
> 2) не работает chap (некоторым нужен для старых ящиков) с моим конфигом > если добавить +chap то игнорируется mschap-v2 - тоесть WindowsXP по крайней > мере соединяется на chap MD5 использую только mschap-v2. > 3) можно ли сделать опциональной mppe? при добавлении mmpe-128 не > соединяется с впн сервером. Что подразумевается под "опциональным mppe"? установление или нет mppe от того как захотел клиент? Если так - то надо патчить pppd патчем: http://mppe-mppc.alphacron.de/ Но, мой Вам совет - откажитесь от использования mppe вообще. Меньше проблем. > 4) есть ли установки впн серверов с большим количеством клиентов? > посмотреть бы их конфиги итд. -------- code ------------ require-mschap-v2 nomppe lcp-echo-failure 3 lcp-echo-interval 3 lock noipdefault nodefaultroute mtu 1400 mru 1400 nobsdcomp nodeflate noccp nopcomp 172.16.254.1: # RADIUS Plugins plugin radius.so plugin radattr.so ------------code-------- > 5) приходится делать обвязку по поводу второго логина - с другого адреса, > есть ли "внутренние резервы" тут не понятно. > 6) чтото непонятное в mtu - ifconfig показывает что WindowsXP подключилась > с MTU:1400 , может поэтому следующий вопрос у себя выставил mtu/mru в 1400. > 7) ... > пн сервер, поднятое соединение... > клиент пингует мою сторону туннеля > как только выполняю команду : > tc qdisc add dev ppp0 root tbf rate 1024kbit latency 50ms burst 300k > не пингуется, хотя tcpdump показывает входящие icmp запросы > tc qdisc del dev ppp0 root решает проблему. > тоже самое работает на M2.4 > 16:00:42.698284 IP 172.16.12.2 > 192.168.6.1: ICMP echo request, id 1024, > seq 256, length 1376 > ^^^^^ использую CBQ. > ppp-2.4.4-alt10 > ppp-common-0.4.2-alt1 > pptpd-1.3.4-alt1 > > cat pptpd.conf > option /etc/ppp/options.pptpd > delegate > > cat options.pptpd > > mtu 1480 > mru 1480 > name pptpd > auth > novj > novjccomp > nobsdcomp > nodeflate > noproxyarp > lcp-echo-failure 10 > lcp-echo-interval 5 50 секунд очень много. > +mschap-v2 > noipx > ms-dns 84.47.143.250 > #plugin radius.so > 192.168.6.1: > > > cat options > > lock > noipdefault > nopredictor1 > > С уважением, Александр Новосёлов На таком решении организации vpn столкнулся с проблемой: если при работе впн, теряются пакеты или идут не попорядку - то сообщения lcp-echo-failure и lcp-echo-interval НЕ БУДУТ доставлятся к pppd, пока pptp не соберёт все фрагметы или не дождётся потерянного пакета. Соотвественно велик шанс, что pppd на серверной стороне не дожётся ответов lcp-echo и сбросит сеодинение. Такая ситуация часто возникает, когда клиент загружает свой канал на всю разрешённую ему полосу. Может из-за того, что CBQ как-то влияет на это, не могу найти в чём причина. Пока решения данной проблемы не смог найти. -- С уважением, Михаил Александрович, Плужников Системный администратор ООО "РДМ-холдинг" тел.: (495) 981-0322 e-mail: [EMAIL PROTECTED] site: www.rdm.ru _______________________________________________ Sysadmins mailing list [email protected] https://lists.altlinux.org/mailman/listinfo/sysadmins
