*Drive*- Здесь рулят padonki

*Drive* - Counter Strike Source
Текущее время: 28 мар 2024, 16:38

Часовой пояс: UTC + 3 часа [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 2 ] 
Автор Сообщение
СообщениеДобавлено: 03 апр 2008, 19:31 
Не в сети
padonki
Аватар пользователя

Зарегистрирован: 14 авг 2006, 20:43
Сообщений: 3750
Благодарил (а): 9 раз.
Поблагодарили: 96 раз.
Введение!
Казалось бы - про VPN не говори, про него все сказано. В сети выложено огромное количество настроек и HOW-TO на любой вкус. Однако, поток одинаковых вопросов, которые задают на форуме http://www.linuxforum.ru начинающие линуксоиды, не иссякает. Скрупулезный анализ показал, что основные проблемы новичков возникают на этапах аутентификации клиента и VPN-сервера, а также настройки роутинга. На них мы остановимся подробно. Попутно выяснилось что настройки VPN-соединения можно сильно упростить и тем самым облегчить понимание ключевых параметров.
Именно для облегчения понимания мы рекомендуем всем новичкам настраивать VPN из командной строки и не пользоваться (полу)автоматическими конфигураторами VPN -- как показывает практика, от их непрозрачных настроек одни неприятности. Как вы увидите ниже, этих настроек очень небольшое количество, так что незачем вставать на костыли, чтобы бежать стометровку. К тому же командная строка вам сослужит добрую службу, когда пойдет что-то не так. Вы всегда можете запостить свои конфиги и вывод консольных команд на наш форум, и суровые бородатые дядьки, которые давно на "ты" с линуксом, вам помогут. Потому что вы говорите с ними на одном языке. И наоборот, что-нибудь вроде "в этом окошке я отмечаю галочкой второй снизу пункт" практически гарантирует отсутствие обратной связи.
Настраивать VPN-соединение мы будем по шагам. В конце каждого шага - шаг проверки. Все команды в командной строке вводятся от имени суперпользователя (root). Готовы? Тогда вперед!
[править] Что нам нужно для работы
Для поднятия и настройки VPN-соединения нам потребуются всего две программы - ppp и pptp. Программа ppp с вероятностью 99% уже стоит в вашем дистрибутиве, пакет, содержащий pptp, в разных дистрибутивах называется по-разному, в основном pptp-linux. После установки в системе должны присутствовать два исполняемых файла - /usr/sbin/pppd и /usr/sbin/pptp. Вкратце - pptp создает туннель к VPN-серверу, через который ppp соединяется и работает как обычное модемное соединение.
Естественно, для поднятия соединения нам необходима рабочая локальная сеть и данные провайдера об IP (или имени) VPN-сервера, VPN-логине и VPN-пароле. Также пригодится информация об используемом протоколе аутентификации и о наличии шифрования траффика. Если ее нет - ничего страшного. Подавляющее большинство провайдеров используют протокол аутентификации MS-CHAP v2, а о наличии шифрования нам подскажут логи ошибок pppd. Подсказка: если у вас стоит MS Windows и там поднято VPN-соединение, его параметры можно посмотреть на вкладке соединения "Сведения". Нас интересуют параметры "Проверка подлинности" и "Шифрование".
Все манипуляции мы будем проводить на имеющейся под рукой домашней сети Корбина телеком. Итак, провайдер снабдил нас следующей информацией:
Локальная сеть:
IP: 10.167.17.38
Маска подсети: 255.255.0.0.
Шлюз (gateway): 10.167.0.17
DNS1: 195.14.50.1
DNS2: 195.14.50.21
VPN параметры:
Имя VPN-сервера: vpn.corbina.net
Логин: VPN_LOGIN
Пароль: VPN_PASSWORD
Проверка работоспособности локальной сети
Если сеть уже настроена, мы должны увидеть примерно следующее
[root@myhost sergo]# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:13:D4:68:B2:3E
inet addr:10.167.17.38 Bcast:10.167.255.255 Mask:255.255.0.0
inet6 addr: fe80::213:d4ff:fe68:b23e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2884 errors:0 dropped:0 overruns:0 frame:0
TX packets:25 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:243742 (238.0 Kb) TX bytes:2242 (2.1 Kb)
Interrupt:19
или
[root@myhost sergo]# ip a sh dev eth0
3: eth0: <BROADCAST> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:13:D4:68:B2:3E brd ff:ff:ff:ff:ff:ff
inet 10.167.17.38/16 brd 10.167.255.255 scope global eth0
[root@myhost sergo]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.167.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
0.0.0.0 10.167.0.17 0.0.0.0 UG 0 0 0 eth0
или
[root@myhost sergo]# ip r
10.167.0.0/16 dev eth0 proto kernel scope link src 10.167.17.38
default via 10.167.0.17 dev eth0 scope link
Если ничего подобного не выводится,поднимаем сеть и указываем в качестве шлюза по умолчанию наш шлюз
ifconfig eth0 10.167.17.38 netmask 255.255.0.0 up
route add default gw 10.167.0.17
или
ip a a 10.167.17.18/16 dev eth0
ip l s up dev eth0
ip r a default via 10.167.0.17
Прописываем IP DNS-серверов в файл /etc/resolv.conf Он должен выглядень следующим образом:
[root@myhost sergo]# cat /etc/resolv.conf
nameserver 195.14.50.1
nameserver 195.14.50.21
Если сеть работоспособна, должны пинговаться шлюз и VPN-сервер. Проверяем
[root@myhost sergo]# ping -c5 10.167.0.17
PING 10.167.0.17 (10.167.0.17) 56(84) bytes of data.
64 bytes from 10.167.0.17: icmp_seq=1 ttl=255 time=3.95 ms
64 bytes from 10.167.0.17: icmp_seq=2 ttl=255 time=0.526 ms
64 bytes from 10.167.0.17: icmp_seq=3 ttl=255 time=0.528 ms
64 bytes from 10.167.0.17: icmp_seq=4 ttl=255 time=3.31 ms
64 bytes from 10.167.0.17: icmp_seq=5 ttl=255 time=0.534 ms
[root@myhost sergo]# ping -c5 vpn.someserver.net
PING vpn.corbina.net (195.14.38.8) 56(84) bytes of data.
64 bytes from vpn8-l0.msk.corbina.net (195.14.38.8): icmp_seq=1 ttl=248 time=1.17 ms
64 bytes from vpn8-l0.msk.corbina.net (195.14.38.8): icmp_seq=2 ttl=248 time=1.16 ms
64 bytes from vpn8-l0.msk.corbina.net (195.14.38.8): icmp_seq=3 ttl=248 time=1.19 ms
64 bytes from vpn8-l0.msk.corbina.net (195.14.38.8): icmp_seq=4 ttl=248 time=1.17 ms
64 bytes from vpn8-l0.msk.corbina.net (195.14.38.8): icmp_seq=5 ttl=248 time=1.00 ms
[править] Предварительная настройка роутинга
Настоятельно рекомендуем отложить ненадолго это руководство и прочитать Linux Network Administrators Guide Russian (http://www.linux.yaroslavl.ru/docs/book/lnag/lnag.html). Главы 2 и 5 снимут большинство ваших вопросов относительно роутинга.
Примечание: Предварительная настройка роутинга необходима в том случае, когда VPN и/или DNS-сервера находятся в других подсетях. Если это не так (да вы счастливчик!) - смело пропускайте этот шаг.
Из таблицы маршрутизации мы видим, что в настоящий момент доступ ко всем хостам сети (включая DNS и VPN сервера) осуществляется по маршруту по умолчанию (default route). Это означает, что любой хост, расположенный за пределами нашего сегмента, машина будет искать, обращаясь к шлюзу, указанному в этом маршруте. Когда мы поднимаем VPN-соединение, VPN-сервер дает нам новый шлюз, через который доступны интернет-хосты. Мы должны удалить из маршрута старый шлюз и заменить его на новый. Проблема в том, что после удаления старого шлюза машина перестанет видеть VPN-сервер и разорвет VPN-соединение. Чтобы этого не произошло, наша машина всегда должна знать, где искать VPN и DNS сервера вне зависимости от наличия или отсутствия маршрута по умолчанию. Для этого мы пропишем статические маршруты на каждый VPN и DNS сервер. Также статические маршруты на VPN сервера избавят нас от возможной проблемы, когда удаленный IP адрес, выдаваемый нам VPN сервером, равен IP адресу самого сервера. Подробнее об этом здесь (http://pptpclient.sourceforge.net/howto ... ml#ip_loop пункт 4с.)
Для начала узнаем IP нашего VPN-сервера с помощью команды ping.
[root@myhost sergo]# ping -c5 vpn.corbina.net
PING vpn.corbina.net (195.14.38.8) 56(84) bytes of data.
Как видно из команды ping, IP VPN сервера 195.14.38.8
Примечание: Чтобы не копаться в частностях, мы допускаем в данном примере, что vpn.corbina.net имеет только один IP. Ситуацию, когда хост vpn.corbina.net имеет не один а несколько IP адресов (на самом деле их 20) мы рассмотрим в шаге "Автоматизация".
Добавляем в нашу таблицу роутинга статические маршруты на VPN и DNS сервера:
route add -host 195.14.50.1 gw 10.167.0.17
route add -host 195.14.50.21 gw 10.167.0.17
route add -host 195.14.38.8 gw 10.167.0.17
или
ip r a 195.14.50.1 via 10.167.0.17
ip r a 195.14.50.21 via 10.167.0.17
ip r a 195.14.38.8 via 10.167.0.17
Удаляем маршрут по умолчанию
route del default
или
ip r d default
Таблица маршрутизации будет выглядеть так:
[root@myhost sergo]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
195.14.50.21 10.167.0.17 255.255.255.255 UGH 0 0 0 eth0
195.14.50.1 10.167.0.17 255.255.255.255 UGH 0 0 0 eth0
195.14.38.8 10.167.0.17 255.255.255.255 UGH 0 0 0 eth0
10.167.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
или
[root@myhost sergo]# ip r
195.14.50.21 via 10.167.0.17 dev eth0
195.14.50.1 via 10.167.0.17 dev eth0
195.14.38.8 via 10.167.0.17 dev eth0
10.167.0.0/16 dev eth0 proto kernel skope link src 10.167.17.38
Проверка: мы должны успешно пинговать DNS и VPN сервера.
[root@myhost sergo]# ping -c5 195.14.50.1
PING 195.14.50.1 (195.14.50.1) 56(84) bytes of data.
64 bytes from 195.14.50.1: icmp_seq=1 ttl=56 time=4.45 ms
64 bytes from 195.14.50.1: icmp_seq=2 ttl=56 time=1.30 ms
64 bytes from 195.14.50.1: icmp_seq=3 ttl=56 time=1.22 ms
[root@myhost sergo]# ping -c5 195.14.50.21
PING 195.14.50.21 (195.14.50.21) 56(84) bytes of data.
64 bytes from 195.14.50.21: icmp_seq=1 ttl=56 time=0.982 ms
64 bytes from 195.14.50.21: icmp_seq=2 ttl=56 time=0.954 ms
64 bytes from 195.14.50.21: icmp_seq=3 ttl=56 time=1.02 ms
[root@myhost sergo]# ping -c5 195.14.38.8
PING 195.14.38.8 (195.14.38.8) 56(84) bytes of data.
64 bytes from 195.14.38.8: icmp_seq=1 ttl=248 time=1.34 ms
64 bytes from 195.14.38.8: icmp_seq=2 ttl=248 time=2.60 ms
64 bytes from 195.14.38.8: icmp_seq=3 ttl=248 time=1.09 ms
Настройка параметров VPN-соединения. Тестовый запуск
Все параметры нашего VPN соединения мы запишем в файле /etc/ppp/peers/corbina. Создадим его и наполним следующим содержанием:
pty "pptp 195.14.38.8 --nolaunchpppd"
user VPN_LOGIN
password "VPN_PASSWORD"
nodeflate
nobsdcomp
noauth
Параметры user и password в комментариях не нуждаются, значение остальных можно посмотреть в файле справки man pppd. Обратим внимание на то, что пароль забран в кавычки.
Убеждаемя, что в файлах /etc/ppp/options, ~/.ppprc, /etc/ppp/options.ppp0 нет незакомментированных параметров, которыми бы система могла затереть наши настройки. Если есть - комментируем
Поднимаем VPN соединение
pppd call corbina debug nodetach
Появятся логи соединения. Если все прошло успешно, они будут выглядеть примерно так:
[root@myhost sergo]# pppd call corbina debug nodetach
using channel 2
Using interface ppp0
Connect: ppp0 <--> /dev/pts/0
sent [LCP ConfReq id=0x1 <asyncmap> <magic> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x1 <auth> <magic>]
sent [LCP ConfAck id=0x1 <auth> <magic>]
sent [LCP ConfReq id=0x1 <asyncmap> <magic> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap> <magic> <pcomp> <accomp>]
sent [LCP EchoReq id=0x0 magic=0x33368137]
rcvd [CHAP Challenge id=0x1 <f872f6df5542429b46d6cf7e89a3386c>, name = "bras8"]
sent [CHAP Response id=0x1 <ebb4965e871c49a07565b148dc2dbf29>, name = "unicorn2"]
rcvd [LCP EchoRep id=0x0 magic=0x36da4966]
rcvd [CHAP Success id=0x1 ""]
CHAP authentication succeeded
CHAP authentication succeeded
sent [IPCP ConfReq id=0x1 <compress> <addr>]
rcvd [IPCP ConfReq id=0x1 <addr>]
sent [IPCP ConfAck id=0x1 <addr>]
rcvd [IPCP ConfRej id=0x1 <compress>]
sent [IPCP ConfReq id=0x2 <addr>]
rcvd [IPCP ConfNak id=0x2 <addr>]
sent [IPCP ConfReq id=0x3 <addr>]
rcvd [IPCP ConfAck id=0x3 <addr>]
Cannot determine ethernet address for proxy ARP
local IP address 89.178.77.182
remote IP address 195.14.38.8
Script /etc/ppp/ip-up started (pid 4072)
Script /etc/ppp/ip-up finished (pid 4072), status = 0x0
На соседнем терминале убедимся, что VPN-соединение установлено. Должен появиться сетевой интерфейс ppp0: [root@myhost sergo]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:13:D4:68:B2:3E
inet addr:10.167.17.38 Bcast:10.167.255.255 Mask:255.255.0.0
inet6 addr: fe80::213:d4ff:fe68:b23e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:24990 errors:0 dropped:0 overruns:0 frame:0
TX packets:97 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2327027 (2.2 Mb) TX bytes:8516 (8.3 Kb)
Interrupt:19

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:13496 errors:0 dropped:0 overruns:0 frame:0
TX packets:13496 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1387313 (1.3 Mb) TX bytes:1387313 (1.3 Mb)

ppp0 Link encap:Point-to-Point Protocol
inet addr:89.178.77.182 P-t-P:195.14.38.8 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:40 (40.0 B) TX bytes:46 (46.0 B)
Если VPN сервер использует шифрование, соединение закончится ошибкой [ЗДЕСЬ ДОЛЖНЫ БЫТЬ ЛОГИ ОШИБКИ]. В этом случае добавим в файл /etc/ppp/peers/corbina строчку
require-mppe-128
и загрузим соответствующий модуль ядра командой
modprobe ppp_mppe
Запускаем снова. Все должно заработать.
Обратите внимание на параметр MTU интерфейса ppp0. По умолчанию он равен 1500. Если ваш провайдер использует другую величину MTU (допустим, 1492) - в тот же файл конфигурации etc/ppp/peers/corbina добавляем строчку
mtu 1492
Окончательная настройка роутинга
Итак, мы подняли VPN соединение, но в интернет выйти не можем - машина пока не знает, где искать интернет-хосты. Для этого мы должны добавить маршрут по умолчанию через интерфейс ppp0 в нашу таблицу маршрутизации (помните - старый маршрут по умолчанию мы удалили). В качестве шлюза по умолчанию теперь выступает remote IP address, который нам любезно предоставил VPN сервер - 195.14.38.8 (да-да, в нашем случае он совпадает с IP VPN сервера!). Этот remote IP address присутствует как в логах pppd (remote IP address 195.14.38.8), так и в параметрах интерфейса ppp0, которые выводятся на экран командой ifconfig (P-t-P:195.14.38.8). Вводим:
route add default gw 195.14.38.8
или
route add default dev ppp0
что в данном контексте - одно и то же Теперь попробуем пропинговать какой-нибудь интернет-хост
[root@myhost sergo]# ping -c5 www.ya.ru
PING ya.ru (213.180.204.8) 56(84) bytes of data.
64 bytes from ya.ru (213.180.204.8): icmp_seq=1 ttl=61 time=2.11 ms
64 bytes from ya.ru (213.180.204.8): icmp_seq=2 ttl=61 time=2.23 ms
64 bytes from ya.ru (213.180.204.8): icmp_seq=3 ttl=61 time=2.39 ms
Работает!
Автоматизация
Теперь, когда соединение оттестировано, можно подумать и об автоматизации. Когда pppd устанавливает соединение, он автоматически выполняет скрипт /etc/ppp/ip-up, когда соединение рвется - выполняется скрипт /etc/ppp/ip-down. Значит, в эти файлы и надо забить весь роутинг, который в предыдущих пунктах мы вводили руками.
Мы не случайно сначала рассмотрели идеальный вариант, когда VPN сервер провайдера представлен в единственном числе и имеет один IP. В этом случае именем хоста (vpn.corbina.net) можно пренебречь и использовать в настройках только его IP, что мы и сделали. Однако если провайдер большой, под именем VPN сервера скрывается несколько серверов с разными IP, что позволяет провайдеру динамически регулировать нагрузку на них. Для того, чтобы выяснить, какие IP имеет хост vpn.corbina.net, воспользуемся командой host из пакета dnsutils
[root@myhost sergo]# host vpn.corbina.net
vpn.corbina.net has address 195.14.38.19
vpn.corbina.net has address 195.14.38.20
vpn.corbina.net has address 195.14.38.1
vpn.corbina.net has address 195.14.38.2
vpn.corbina.net has address 195.14.38.3
vpn.corbina.net has address 195.14.38.4
vpn.corbina.net has address 195.14.38.5
vpn.corbina.net has address 195.14.38.6
vpn.corbina.net has address 195.14.38.7
vpn.corbina.net has address 195.14.38.8
vpn.corbina.net has address 195.14.38.9
vpn.corbina.net has address 195.14.38.10
vpn.corbina.net has address 195.14.38.11
vpn.corbina.net has address 195.14.38.12
vpn.corbina.net has address 195.14.38.13
vpn.corbina.net has address 195.14.38.14
vpn.corbina.net has address 195.14.38.15
vpn.corbina.net has address 195.14.38.16
vpn.corbina.net has address 195.14.38.17
vpn.corbina.net has address 195.14.38.18
Роутинг на всю эту прорву серверов нам нужно один раз внести в файл /etc/ppp/ip-up и привести файл к следующему виду:
#!/bin/sh
#
# This script is run by pppd when there's a successful ppp connection.
#
route add -host 195.14.38.1 gw 10.167.0.17
route add -host 195.14.38.2 gw 10.167.0.17
route add -host 195.14.38.3 gw 10.167.0.17
.....
route add -host 195.14.38.19 gw 10.167.0.17
route add -host 195.14.38.20 gw 10.167.0.17
route del default
а в скрипт /etc/ppp/ip-down мы запишем всего одну строчку, которая вернет нам шлюз по умолчанию после обрыва соединения:
#!/bin/sh
#
# This script is run by pppd after the connection has ended.
#
route add default gw 10.167.0.17
Вы, наверное, уже заметили, что мы не вписали в файл /etc/ppp/ip-up строчку route add default dev ppp0. Это не нужно - после успешного коннекта pppd сам впишет шлюз по умолчанию, если мы дадим ему команду defaultroute. В результате наш файл настроек /etc/ppp/peers/corbina будет выглядеть следующим образом:
pty "pptp vpn.corbina.net --nolaunchpppd"
user VPN_LOGIN
password "VPN_PASSWORD"
nodeflate
nobsdcomp
noauth
defaultroute
Мы заменили IP VPN-сервера на его имя и добавили defaultroute Запускать и прерывать соединение можно командами
pon corbina
poff corbina
Если есть необходимость запускать соединение от простого пользователя, установите программу sudo и в файл /etc/sudoers впишите:
sergo myhost = NOPASSWD: /usr/bin/pon, /usr/bin/poff
Соответственно, замените sergo и myhost на имя вашего пользователя и его машины. Он сможет запускать и прерывать соединение командами
sudo pon corbina
sudo poff corbina
материал взят и успешно протестирован с сайта http://ru.posix.wikia.com/wiki/PPTP

_________________
Моя характеристика с детского сада: Хорошо кушает, спит, гуляет! Прошло много лет, ничего не изменилось.
Изображение


Вернуться наверх
 Профиль  
 
СообщениеДобавлено: 25 апр 2008, 13:18 
Не в сети
padonki
Аватар пользователя

Зарегистрирован: 14 авг 2006, 20:43
Сообщений: 3750
Благодарил (а): 9 раз.
Поблагодарили: 96 раз.
Небольшое предисловие - у многих наверное стоят VPN сервера на указанной выше связке, возможно без mppe/mppc патчей но все же pptpd(poptop)+pppd потому что это единственный способ поднимать vpn соединение с МД средствами этого же МД и не сильно сложно для пользователя, я не исключение и у меня тоже есть такой сервер, стоял он себе на debian woody, вышел sarge, апгрейднули до sarge, и тут заметили такую неприятную особенность - если 1 linux клиент поднимает 2 и более соединения тоесть одна linux машина устанавливает 2 соединения с сервером то на сервере получается зомби процесс pppd а на клиенте некоторое время висят 2 интерфейса, начали разбираться, пришли к выводу что виноват pptpd, причем ситуация легко воспроизводится на debian sarge системах, отправили багрепорт, начали смотреть дальше, с МД в качестве клиента не воспроизводится, радиус не дает сделать 2 соединения что вобщем то правильно, специально так настроен, но если клиент linux то почемуто это не срабатывает, один товарищ подсказал что pptp соединение идентифицируется парой IP адрес и еще какоето Id которое назначается сервером клиенту и должно быть уникальным, а linux клиент как оказалось на это id внимания не обращает и оно у него всегда одинаковое, это хоть как то объяснило ситуацию, получается что сервер пытается использовать для нового соединения те же параметры что и для первого поэтому радиус их не различает. Посмотрели версию pptpd, увидели что в дебиане она мягко говоря старовата - 1.2.1 когда на http://www.poptop.org/ текущая стабильная версия 1.2.3 которую думаю и следует использовать на данный момент а экспериментальная 1.3.0 которую как оказалось тоже можно использовать после небольшой обработки напильником.

Вобщем решили потестировать разные версии pptpd, попробовали с woody - зомби не появляются, попробовали 1.2.3 - зомби тоже не появляются, пришли к выводу что появляются только на 1.2.1 которая в debian sarge, делать нечего решили обновиться, и попутно пришла в голову идея потестировать всю эту связку на предмет скорости и попробовать оптимизировать ее.

Потестировали, pppd 2.4.3 из дебиана с mppe-mppc ратчем с http://mppe-mppc.alphacron.de/, и pptpd 1.2.3, машина:

cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 10
model name : AMD Athlon(tm) XP 2600+
stepping : 0
cpu MHz : 2080.646
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow
bogomips : 4154.98

соединение было с включенной MPPC компрессией без MPPE(чтото не додумались включить, она у нас по дефолту выключена) из оставшихся настроек pppd способных по моему мнению повлиять на производительность стоит отметить mtu/mru (поправьте если я не прав) которые выставлены в 1490, ядро 2.4.32, тестировали путем скачивания фильма со своего же ftp сервера, на нем стоит ограничение по скорости в 10 мегабит на одну сессию поэтому запустили сразу несколько скачек(снимать ограничение было неохото:)), примерно на 30-40 мегабитах загрузка процессора оказалась на уровне 50-70% причем практически все это судя по топу отъедала система (system) из чего сделали вывод что виновница этого MPPC так как модули реализующие ее в ядре. Попробовали то же самое но без компресси, получили загрузку в районе 1-2% что еще больше уверило нас что таки это MPPC и ничего с этим поделать не представляется возможным, но тем не менее решили попробовать оптимизировать то что можно и заодно посмотреть на pptpd 1.3.0 потому что там заявляют поддержку "prototype packet buffering and reordering" а у нас есть некоторые нестабильные линки через которые пакеты иногда приходят не в том порядке в каком были отправлены да и просто если тоннель через интернет то это вполне нормальная ситуация, а pptpd такие пакеты попросту отбрасывает с матюками в лог а тут появилась надежда что он их не будет отбрасывать а корректно переставит и обработает.

Итак смотрим pptpd 1.3.0: Первое что видим директорию debian, как оказалось автор pptpd тоже использует дебиан как и мы и в архиве присутствует система сборки в deb пакет что порадовало:) Идем в ./debian/rules, правим параметры вызова configure скрипта на такие:

./configure --prefix=/usr --mandir=/usr/share/man \
--with-pppd-ip-alloc \
--enable-facility=LOG_LOCAL3

тоесть убираем впринципе не нужные нам --with-libwrap (позволяет ограничивать доступ к pptpd посредством /etc/hosts.allow/hosts.deny, но я привык делать такие вещи фаерволом) и --with-bcrelay (это специальный демон который позволяет транслировать бродкасты приходящие на определенный ethernet интерфейс на ppp интерфейс, надобности у нас в нем нет поэтому тоже выключили), --with-pppd-ip-alloc включает режим когда адреса назначает сам pppd что нам вобщем то и нужно, если не включить то это будет делать pptpd отдавая адреса прописанные у него в конфиге ppp через параметры при запуске и плюс при этом будет ограничение в 100 конектов которое нам не нужно потому что клиентов больше 100, --enable-facility=LOG_LOCAL3 просто для удобства, в syslog.conf пишем:

local3.* /var/log/pptpd

и получаем все сообщения от pptpd в отдельном логе.

Далее делаем в директории с исходниками pptpd ./debian/rules binary, это запустит процедуру сборки в deb пакет, у кого не дебиан могут собрать традиционным путем запустив configure с теми же параметрами, еще архиве есть система сборки в rpm но о ней я ничего не знаю и знать не хочу поэтому те кто знают - разберутся сами:)

Собралось и поставилось без проблем, соединение установилось, пингую с клиента сервер, и тут я в логах вижу такое:

Nov 26 02:23:00 ghhosthome pptpd[20850]: GRE: accepting packet #1
Nov 26 02:23:00 ghhosthome pptpd[20850]: GRE: accepting packet #2
Nov 26 02:23:00 ghhosthome pptpd[20850]: GRE: accepting packet #3
Nov 26 02:23:00 ghhosthome pptpd[20850]: GRE: accepting packet #4
Nov 26 02:23:00 ghhosthome pptpd[20850]: GRE: accepting packet #5
Nov 26 02:23:00 ghhosthome pptpd[20850]: GRE: accepting packet #6
Nov 26 02:23:00 ghhosthome pptpd[20850]: GRE: accepting packet #7
Nov 26 02:23:00 ghhosthome pptpd[20850]: GRE: accepting packet #8
Nov 26 02:23:00 ghhosthome pptpd[20850]: GRE: accepting packet #9
Nov 26 02:23:00 ghhosthome pptpd[20850]: GRE: accepting packet #10
Nov 26 02:23:00 ghhosthome pptpd[20850]: GRE: accepting packet #11
Nov 26 02:23:10 ghhosthome pptpd[20850]: GRE: accepting packet #12
Nov 26 02:23:11 ghhosthome pptpd[20850]: GRE: accepting packet #13
Nov 26 02:23:12 ghhosthome pptpd[20850]: GRE: accepting packet #14
Nov 26 02:23:13 ghhosthome pptpd[20850]: GRE: accepting packet #15
Nov 26 02:23:14 ghhosthome pptpd[20850]: GRE: accepting packet #16
Nov 26 02:23:15 ghhosthome pptpd[20850]: GRE: accepting packet #17
Nov 26 02:23:16 ghhosthome pptpd[20850]: GRE: accepting packet #18
Nov 26 02:23:17 ghhosthome pptpd[20850]: GRE: accepting packet #19
Nov 26 02:23:18 ghhosthome pptpd[20850]: GRE: accepting packet #20
Nov 26 02:23:19 ghhosthome pptpd[20850]: GRE: accepting packet #21
Nov 26 02:23:20 ghhosthome pptpd[20850]: GRE: accepting packet #22
Nov 26 02:23:21 ghhosthome pptpd[20850]: GRE: accepting packet #23

ну и так далее, тоесть на каждый GRE пакет делается запись в лог:) Это мне не очень понравилось ибо на боевом сервере пакетов будет много и никаких дисков не хватит, да и думаю производительности такая фича не прибавит а скорее наоборот, смотрим в /etc/pptpd.conf, debug выключен а сообщения в лог всеравно идут, читаем man pptpd, находим там секцию debugging, вдумчиво читаем, видим там в конце "Disable this line and restart syslog after you are done debugging. See the syslog man pages for more details.", понимаем что автор с юмором и выключить это путем настроек не получится, но чтож, сами виноваты, написано же что experimental, поэтому отдаем автору должное за его труд и пытаемся делать чтото самостоятельно а не предьявлять претензии - ищем по исходникам pptpd строку "accepting packet", находим в pptpgre.c строка 402:

syslog(LOG_DEBUG, "GRE: accepting packet #%d", seq);

коментируем чтобы было вот так:

/* syslog(LOG_DEBUG, "GRE: accepting packet #%d", seq); */

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

Поднимаем второе соединение с той же машины что и первое, смотрим на сервере - зомбей нет что не может не радовать и этого нам впринципе уже достаточно для сервера, но судя по логам запускается еще один процесс pppd который затем убивается, на клиенте же появляется второй интерфейс и ниодно соединение не работает, плюс ко всему в логах pptpd видим следующее:

Nov 28 03:29:02 ghhosthome pptpd[23389]: CTRL: Request to open call when call is already open, closing

из чего делаем вывод что pptpd всетаки видит ситуацию с двумя конектами и каким то образом ее отрабатывает, напрашивается вопрос каким же именно. Исходя из принципа the sources is a documentation ищем в исходниках pptpd строку "Request to open call when call is already open, closing", и находми ее в pptpctrl.c строка 365, смотрим подробнее кусок кода:

case OUT_CALL_RQST:
/* for killing off the link later (ugly) */
NOTE_VALUE(PAC, call_id_pair, ((struct pptp_out_call_rply *) (rply_packet))->call_id);
NOTE_VALUE(PNS, call_id_pair, ((struct pptp_out_call_rply *) (rply_packet))->call_id_peer);
if (gre_fd != -1 || pty_fd != -1) {
syslog(LOG_WARNING, "CTRL: Request to open call when call is already open, closing");
if (gre_fd != -1) {
FD_CLR(gre_fd, &fds);
close(gre_fd);
gre_fd = -1;
}
if (pty_fd != -1) {
FD_CLR(pty_fd, &fds);
close(pty_fd);
pty_fd = -1;
}
}
/* change process title for accounting and status scripts */
my_setproctitle(gargc, gargv,
"pptpd [%s:%04X - %04X]",
inet_ntoa(inetaddrs[1]),
ntohs(((struct pptp_out_call_rply *) (rply_packet))->call_id_peer),
ntohs(((struct pptp_out_call_rply *) (rply_packet))->call_id));
/* start the call, by launching pppd */
syslog(LOG_INFO, "CTRL: Starting call (launching pppd, opening GRE)");
pty_fd = startCall(pppaddrs, inetaddrs);
if (pty_fd > maxfd) maxfd = pty_fd;
/* wait for first packet from ppp before proceeding, thus
delaying outgoing call reply, and avoiding traffic
injection into the pty before echo has been turned off
by pppd */
if (PPP_WAIT) {

Судя по этому фрагменту, открывается новое соединение, запускается pppd и затем оно благополучно убивается, что вобщем то подтверждается логами, непонятно чем в данном случае руководствовался автор обрабатывая такую ситуацию таким образом, может просто еще не дописал, версия то экспериментальная, но первое что пришло в голову - зачем запускать а потом убивать если можно просто не запускать?

Пробуем это реализовать: После

if (pty_fd != -1) {
FD_CLR(pty_fd, &fds);
close(pty_fd);
pty_fd = -1;
}

вставляем break; чтобы выглядело вот так:

case OUT_CALL_RQST:
/* for killing off the link later (ugly) */

NOTE_VALUE(PAC, call_id_pair, ((struct pptp_out_call_rply *) (rply_packet))->call_id);
NOTE_VALUE(PNS, call_id_pair, ((struct pptp_out_call_rply *) (rply_packet))->call_id_peer);

if (gre_fd != -1 || pty_fd != -1) {
syslog(LOG_WARNING, "CTRL: Request to open call when call is already open, closing");
if (gre_fd != -1) {
FD_CLR(gre_fd, &fds);
close(gre_fd);
gre_fd = -1;
}
if (pty_fd != -1) {
FD_CLR(pty_fd, &fds);
close(pty_fd);
pty_fd = -1;
}
break;
}
/* change process title for accounting and status scripts */
my_setproctitle(gargc, gargv,
"pptpd [%s:%04X - %04X]",
inet_ntoa(inetaddrs[1]),
ntohs(((struct pptp_out_call_rply *) (rply_packet))->call_id_peer),
ntohs(((struct pptp_out_call_rply *) (rply_packet))->call_id));
/* start the call, by launching pppd */

снова пересобираем и переустанавливаем pptpd и смотрим что получилось - устанавливаем первое соединение, работает, пробуем установить второе - не устанавливается, и вдобавок обрывается первое, более углубленное изучение sources которые вдобавок the best documentation видим что соединение не устанавливается но процедура убивания всеравно отрабатывается, а постольку поскольку либо gre_fd либо pty_fd у этих соединений получается одинаковое то закрывается первое соединение, подумав и поэкспериментировав пришли к выводу что впринципе такое поведение вполне приемлемо по двум причинам: Первая это то что адреса у нас статические, соответственно 2 соединения будут иметь одинаковые адреса и поэтому даже если их корректно установить то нормально работать всеравно не будет. Вторая это то что при нормальной работе двух соединений быть не должно, если происходит попытка установить второе соединение при живом первом то тут на мой взгляд 2 варианта, один это если из за проблем на несущей сети соединение со стороны клиента уже отвалилось а со стороны сервера еще нет и клиент пробует соединиться занова,и второй вариант это если клиент идиот и пытается поднять второе соединение.

В первом варианте конечно наилучшим выходом было бы закрыть старое соединение и установить новое, но реализовывать это неохото:) да и не так много таких ситуаций возникает, должно быть стечение обстоятельств - pptp клиент не обращающий внимание на id + повторное соединение с сервером, всеравно клиент нажмет соединиться и в третий раз и тогда у него это получится, а во втором варианте можно прибивать и принципиально:) так что на этом оставим pptpd в покое и перейдем к оптимизации pppd.

Итак, заранее берем исходники дебьяновского pppd - apt-get source ppp (на самом деле мы это сделали давно потому что используем несколько патчей которых в дебиане нету), и пока они берутся думаем чего там может быть лишнего, и понимаем что лишними на сервере могут быть PPP multilink и PPP filtering, уточняем в man pppd что PPP multilink нужен для обьединения нескольких ppp соединений между двумя машинами в одно виртуальное но с большей пропускной способностью, нам это на сервере не нужно, попутно видим что для этого же самого нужна поддержка TDB(это такая база в которой хранятся данные необходимые для организации этого самого multilink), может на скорость это сильно и не влияет но на размер самого pppd влиять должно, а учитывая то что их на сервере тысячи то стоит выключить как multilink так и TDB в целях экономии памяти. PPP filtering это фильтрация пакетов на ppp интерфейсе, не путать с iptables, это фильтрация реализованная в самом pppd, и насколько я понял фактически используется только для режима dial-on-demand когда соединение устанавливается только при появлении пакетов на ppp интерфейсе которые улавливаются какраз этой фильтрацией, плюс вдобавок можно просто фильтровать пакеты, правила фильтрации схожи с правилами задания фильтрации у tcpdump - man tcpdump(1) и эту фильтрацию можно с тем же успехом обеспечить средствами фаервола, а вот ресурсов такая фильтрация возможно может отъедать прилично, dial-on-demand нам на сервере не нужно, отфильтровать если понадобится можно и фаерволом поэтому относим фильтрацию к тому что можно выключить.

Теперь смотрим как это все поотключать, разглядываем систему сборки дебьяновского pppd, понимаем что при каждой сборке исходники разархивируются из оригинального архива, далее накладывается ряд патчей и уже на результирующем дереве запускается сборка, поэтому смотрим в архиве оригинального ppp, читаем README и README.linux, узнаем что сборка происходит на сонове Makefile который выбирается в зависимости от системы скриптом configure, попутно узнаем что реализация ppp протокола состоит из двух частей - одна часть в ядре другая userspace, сам pppd какраз и есть userspace часть и нужен только для установки соединения и согласования его параметров а в процессе приема/передачи пакетов никак не задействован, этим занимаются модули ядра что впринципе подтверждает тестирование проведенное выше и обьясняет почему большую часть процессорного времени откусила система (но забегая вперед скажу что не обьясняет итоговых результатов, скорее наоборот вводит в заблуждение). Попробовав запустить ./configure видим что он в качестве мэйкфайла устанавливает pppd/Makefile.linux, соответсвенно смотрим в pppd/Makefile.linux и находим какраз то что нужно - опции FILTER=y, HAVE_MULTILINK=y, USE_TDB=y, причем над опцией HAVE_MULTILINK=y находим следующую прозьбу разработчиков pppd:

# Linux distributions: Please leave multilink ENABLED in your builds
# of pppd!

Тоесть они просят дистрибьюторов linux не выключать поддержку мультилинка, видимо из за жалоб пользователей у которых это вдруг может не заработать, но мы то не пользователи, и жаловаться не привыкли:) поэтому нужно закоментировать все эти три опции, а заодно можно и HAS_SHADOW=y и USE_PAM=y если у вас авторизация как у нас через радиус то они не нужны, а заодно и HAVE_INET6=y и CBCP=y если не нужны IpV6 и каллбэк (каллбэк при pptp точно не нужен, но впринципе тот же сервер может обслуживать и какойнить диалап при котором может быть оно нужно, вобщем сами разберетесь), просто закоментировать можно если ставить традиционным путем - ./configure;make;make install, а нам нужен deb пакет поэтому у нас 2 пути - перепаковать архив с оригинальными исходниками pppd подправив там мэйкфайл откуда их потом достает дебьяновская система сборки, но тут есть опастность что не наложатся какие либо патчи, или же наоборот сделать свой патч и положить его к остальным дебьяновским, второй вариант на мой взгляд более правильный, но чтобы сделать патч нужно иметь конечное дерево исходников после наложения всех патчей на котором уже и происходит сборка, чтобы его получить необходимо наложить все дебьяновские патчи. Накладывать их руками мне было неочень охото, поэтому немного подумав появилось предположение что по аналогии с другими пакетами если собрать пакет то после сборки это самое дерево не удалится. Проверяем - ./debian/rules binary, собирается и действительно - дерево соталось в build-tree, соответсвенно копируем его куда нибудь, идем в куданибудь/build-tree/ppp-2.4.3/pppd/Makefile.linux и коментируем все что нам не нужно, далее делаем diff -ruN между оригинальным и исправленным деревьями, результат обзываем как нибудь к примеру noTDB-noNultilink-noFilter.diff и кладем в ./debian/patches в исходниках pppd. у меня содержание получилось вот такое:

diff -ruN ppp-2.4.3-vanulla/pppd/Makefile.linux ppp-2.4.3/pppd/Makefile.linux
--- ppp-2.4.3-vanulla/pppd/Makefile.linux 2004-11-13 15:02:22.000000000 +0300
+++ ppp-2.4.3/pppd/Makefile.linux 2005-11-25 23:52:48.000000000 +0300
@@ -48,17 +48,17 @@
# Uncomment the next line to include support for PPP packet filtering.

# This requires that the libpcap library and headers be installed
# and that the kernel driver support PPP packet filtering.
-FILTER=y
+#FILTER=y

# Uncomment the next line to enable multilink PPP (enabled by default)
# Linux distributions: Please leave multilink ENABLED in your builds
# of pppd!
-HAVE_MULTILINK=y
+#HAVE_MULTILINK=y

# Uncomment the next line to enable the TDB database (enabled by default.)
# If you enable multilink, then TDB is automatically enabled also.
# Linux distributions: Please leave TDB ENABLED in your builds.
-USE_TDB=y
+#USE_TDB=y

HAS_SHADOW=y
#USE_PAM=y

если нехотите возиться можете просто скопировать и наложить, думаю ляжет даже на оригинальные исходники без дебьяновских патчей. Дальше делаем ./debian/rules clean затем ./debian/rules binary, все должно пройти без ошибок, если произошли ошибки при наложении патчей то скорее всего вы както неправильно сделали diff, вобщем после сборки устанавливаем и пробуем тестировать.

Кстати чуть не забыл, поддержка PPP multilink и PPP Filtering еще есть в ядре и там ее тоже поидее надо бы выключить, но мне на боевом сервере перезагрузки устраивать не охото да и забегая вперед скажу что полученных результатов пока вполне достаточно так что выключу при следующем обновлении ядра или плановой перезагрузке:), multilink у меня там итак выключен а вот filtering включен и все тесты производились при включенной опции PPP filtering в ядре, возможно если ее еще выключить и там то производительность будет еще больше.

Итак те же параметры соединения что и в предыдущем тесте, пробуем скачать кино, смотрим top, и понимаем что чтото ничего не видно, переспрашиваем (этот тест я уже делал не сам а из дома совместно с еще одним человеком который собственно и запускал закачки сидя в серверной), диалог был примерно такой: я- ты там качаеш?
он - качаю
для верности даю ftpwho -vv на сервере - правда качает, на 10 мегабитах в секунду, но по top ничего не заметно загрузка процессора 1-2% и на фоне общей работы пользователей можно сказать что нагрузки нет, следовательно стало явно быстрее, вопрос на сколько:)

Таки лезу в конфиг ftp сервера и убираю оттуда ограничение в 10 мегабит, пробуем снова, и получаем скорость практически на уровне несущей сети - 100 мегабит в секунду с MPPC компрессией, при этом загрузка процессора колебалась в пределах 50-70% что не может не радовать:) учитывая что от количества клиентов нагрузка практически не зависит, тоесть главное общий траффик который проходит по pptp запас получается не плохой, как я уже говорил возможно если одноименные опции выключить еще и в ядре станет еще лучше. Но тем не менее такой результат я для себя обьяснить пока не могу, эти 50-70% CPU при 100 мегабитах в секунду заняты были системой, поидее если сам pppd в процессинге пакетов не учавствует то его оптимизация не должна бы была давать такой прирост, если только pptpctrl который занимается инкапсуляцией пакетов использует чтото системное и его работа отображается как работа системы тогда это как то обьясняет такой результат, вообще хочу сегодня если у ребят будет время потестировать получше и с включенным MPPE, если получится допишу результаты. Но тем не менее на данный момент результат таков хоть и необьясним. может кто прольет на это свет?

_________________
Моя характеристика с детского сада: Хорошо кушает, спит, гуляет! Прошло много лет, ничего не изменилось.
Изображение


Вернуться наверх
 Профиль  
 
Показать сообщения за:  Сортировать по:  
Начать новую тему Ответить на тему  [ Сообщений: 2 ] 

Часовой пояс: UTC + 3 часа [ Летнее время ]


Кто сейчас на форуме

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 19


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти: