ISP`s IT Аутсорсинг
Быстрый переход: Главная блога Главная сайта Форум
Если Вы чего то недопоняли или не нашли - задайте
вопрос на нашем форуме и мы попробуем Вам помочь.
Subnets.ru Регистрация IP и Автономных систем mega-net.ru

Архивные статьи в категории ‘FreeBSD’

Добро пожаловать в блог! Надеемся, что Вы еще вернетесь.

Возникла задача удаленного реинсталла сервера c установленной FreeBSD, осложнявшаяся отсутствием KVM как класса и сложностью доступа к серверу.
Погуглив, было найдено это описание. То, что и было нужно. Нам понадобятся две вещи:

  1. ISO-образ будущей устанавливаемой системы
  2. Пакет утилит mfsBSD

Приступим к созданию загрузочного имиджа.

Создадим рабочую директорию:
# mkdir /usr/zzz
# cd /usr/zzz

Выкачиваем ISO:
# fetch ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/ISO-IMAGES/8.1/FreeBSD-8.1-RELEASE-amd64-disc1.iso
Выкачиваем mfsBSD:
#fetch http://people.freebsd.org/~mm/mfsbsd/mfsbsd-latest.tar.gz
распаковываем и переходим в получившующся диру:
# tar xvzf mfsbsd-1.0-beta1.tar.gz
# cd mfsbsd-1.0-beta1/conf/

Тюним конфиги под свои реалии:
# cp loader.conf.sample loader.conf

geom_uzip_load="YES"
mfs_load="YES"
mfs_type="mfs_root"
mfs_name="/mfsroot"
tmpfs_load="YES"
vfs.root.mountfrom="ufs:/dev/md0"
mfsbsd.rootpw="123456"

# cp rc.conf.sample rc.conf

hostname="mfsbsd"
defaultrouter="192.168.109.14"
ifconfig_em0="inet 192.168.109.35 netmask 255.255.255.0" #т.к. сетевая карта известна, то можно ее явно указать

varmfs="YES"
varsize="64m"

sshd_enable="YES"
sendmail_enable="NONE"
cron_enable="NO"

# echo «nameserver 8.8.8.8» >resolv.conf
Монтируем ISO-шник в диру /cdrom
# mdconfig -a -t vnode -f ../../FreeBSD-8.1-RELEASE-amd64-disc1.iso md0
# mount_cd9660 /dev/md0 /cdrom/
# make BASE=/cdrom/8.1-RELEASE/

Extracting base and kernel ... done
Removing unnecessary files from distribution ... done
Installing configuration scripts and files ... done
Generating SSH host keys ... done
Configuring boot environment ... done
Creating usr.uzip ... done
Copying user packages ... done
Creating and compressing mfsroot ... done

Вот и готова наша палочка-выручалочка:
# ls -la *.img

-rw-r--r--  1 root  493  45088768 Nov 11 19:30 mfsboot.img

заливаем ее на удаленную машинку:
# scp mfsboot.img user@remotehost:~/

Далее, заходим на наш удаленный тазик.

Т.к. конфигурацию партиций менять не планировалось, то получаем информацию о текущих партициях:
# bsdlabel /dev/ad0s1 > ~/label.txt

которую нужно где-то сохранить
# scp ~/label.txt user@remotehost:~/

туда же отправляем /etc/fstab
# scp /etc/fstab user@remotehost:~/

Едем дальше:

Осталось записать наш имидж в начало диска:
# dd if=mfsboot.img of=/dev/ad0 bs=1m

dd: /dev/ad0: Operation not permitted

Вот нас и посетила розовая птица обломинго… Но не все так безнадежно — нам поможет в решении этой засады:

# sysctl kern.geom.debugflags=16

kern.geom.debugflags: 0 -> 16

# dd if=mfsboot.img of=/dev/ad0 bs=1m

43+0 records in
43+0 records out
45088768 bytes transferred in 2.797733 secs (16116181 bytes/sec)

Все, мы «закатали» наш временный загрузочный образ и можем ребутаться:
# shutdown -r now

после ребута заходим на наш тазик по ssh сразу под рутом и продолжаем:
Т.к. у sysinstall есть проблемы с созданием устройств в devfs, то сделаем это за него.

В начале пометим системный диск как пустой:
mfsbsd# dd if=/dev/zero of=/dev/ad0 count=2

2+0 records in
2+0 records out
1024 bytes transferred in 0.001632 secs (627369 bytes/sec)

Создадим слайс, размером во весь диск с записью загрузочного кода в сектор 0:
mfsbsd# fdisk -BI /dev/ad0

******* Working on device /dev/ad0 *******
fdisk: invalid fdisk partition table found
fdisk: Class not found

Создаем стандартную метку для диска (включая загрузочный код):
mfsbsd# bsdlabel -wB /dev/ad0s1

Возвращаем обратно инфу о партициях:
scp user@remotehost:/home/user/label.txt .

и реанимируем их:
mfsbsd# bsdlabel -R /dev/ad0s1 label.txt

Форматируем наши партиции:
mfsbsd# newfs /dev/ad0s1a

/dev/ad0s1a: 512.0MB (1048576 sectors) block size 16384, fragment size 2048
using 4 cylinder groups of 128.02MB, 8193 blks, 16448 inodes.
super-block backups (for fsck -b #) at:
160, 262336, 524512, 786688

mfsbsd# newfs /dev/ad0s1e

/dev/ad0s1e: 512.0MB (1048576 sectors) block size 16384, fragment size 2048
using 4 cylinder groups of 128.02MB, 8193 blks, 16448 inodes.
super-block backups (for fsck -b #) at:
160, 262336, 524512, 786688

mfsbsd# newfs /dev/ad0s1d

/dev/ad0s1d: 512.0MB (1048576 sectors) block size 16384, fragment size 2048
using 4 cylinder groups of 128.02MB, 8193 blks, 16448 inodes.
super-block backups (for fsck -b #) at:
160, 262336, 524512, 786688

mfsbsd#  newfs /dev/ad0s1f

/dev/ad0s1f: 5631.0MB (11532192 sectors) block size 16384, fragment size 2048
using 31 cylinder groups of 183.77MB, 11761 blks, 23552 inodes.
super-block backups (for fsck -b #) at:
160, 376512, 752864, 1129216, 1505568, 1881920, 2258272, 2634624, 3010976, 3387328, 3763680, 4140032, 4516384, 4892736, 5269088, 5645440, 6021792, 6398144,
6774496, 7150848, 7527200, 7903552, 8279904, 8656256, 9032608, 9408960, 9785312, 10161664, 10538016, 10914368, 11290720

Подготавливаем плацдарм для будущей ОС:
mfsbsd# mount /dev/ad0s1a /mnt/
mfsbsd# mkdir /mnt/var
mfsbsd# mkdir /mnt/usr
mfsbsd# mkdir /mnt/tmp
mfsbsd# mount /dev/ad0s1d /mnt/var/
mfsbsd# mount /dev/ad0s1e /mnt/tmp/
mfsbsd# mount /dev/ad0s1f /mnt/usr/

Все, работу по подготовке к инсталляции FreeBSD через сеть мы закончили.
Настало время sysinstall — запускаем его и выбираем пункт меню Custom. В пункте Options ОБЯЗАТЕЛЬНО меняем значение Install Root на /mnt .
Далее посещаем Distributions с выбором там опции Minimal. В Media выбираем ближайший к нам ftp. Финализируем Commit’ом.

Если все хорошо, то появится заветный вопрос «Visit the general configuration menu for a chance to set any last options?», ответ на который зависит от вас.
Мы же продолжаем дальше:

mfsbsd# cp /etc/resolv.conf /mnt/etc/
mfsbsd# cp /etc/rc.conf /mnt/etc/

после чего удалите из него все лишнее.
Опционально:
mfsbsd# cp /etc/ssh/sshd_config /mnt/etc/ssh/

Возвращаем назад fstab:
# scp user@remotehost:/home/user/fstab /mnt/etc

Чрутимся в /mnt:
mfsbsd# chroot /mnt
копируем на место ядро и его модули:

mfsbsd# cp -Rp /boot/GENERIC/* /boot/kernel
Меняем пасс на рута:
mfsbsd# passwd root

Changing local password for root
New Password:
Retype New Password:

Финальный ребут:
# shutdown -r now

Скрестив пальцы, молимся великому пингу и ожидаем поднятия сервера с новой осью 🙂

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Пожалуйста, уважайте чужой труд.

Автор: Панфилов Алексей (lehis (at) subnets.ru)

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 4, среднее: 5,00 из 5)
Загрузка...
Отправить на почту Отправить на почту

Поводом для написание этой статьи стало обращение знакомого с вопросом о пробросе порта внутрь локалки.

Я понимаю, что тема вроде как «избитая», так же я ответил и знакомцу: «Гугл тебе в помощь, там все найдешь.»

Через некоторое время он постучался снова, снова с просьбой помочь, что у него не получается. Ну что ж, полез смотреть…..

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

Дабы не объяснять потом одно и тоже очередному знакомому решил накатать сей пост, копипаст рулит ! :)))))

Для простоты будем считать, что у железки  default gateway вообще отсутствует. Почему ?

Причин может быть множество, начиная от «так склалось» заканчивая тем что нет полного доступа ни к серверу (который является шлюзом для железки) ни к самой железке 🙂

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

Уже есть одна, написанная мной, статья о natd: Выпускаем локальную сеть в Интернет используя сервер на FreeBSD и NATD, пусть будет вторая, продолжу тему.

Исходные данные будут такие:

  • Реальник сервера: 8.8.8.8 (да да, ну люблю я гугл :)))
  • Внутренний адрес железки: 10.0.2.18
  • Пробрасываем на железку порт 80 через порт 8080 на сервере (т.к. порт 80 на сервере уже занят apache`ом)
  • Сервер с FreeBSD 7.2
  • Внешний интерфейс: em0
  • Внутренний интерфейс: em1

Для полноты «картины» в статье сначала рассмотрим обычный вариант, а именно схему:

Интернет <==> (<— default GW) [8.8.8.8] Сервер с реальником [10.0.2.2]<===> (<— default GW) [10.0.2.18] Железка с внутренним адресом (default gateway смотрит на сервер)

Так уж повелось, что для natd я никогда не юзал конфиг, а так же не заворачиваю весь трафик с внешнего интерфейса в NAT.

Почему ? Потому что на интерфейсе может быть далеко не один реальный адрес, так зачем туда пхать весь траф ? Фря тем и хороша, что задача одна, а способов её решения множество.

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

Откройте мануал (man natd), как же без него 😉

-redirect_port proto targetIP:targetPORT[-targetPORT]
[aliasIP:]aliasPORT[-aliasPORT]
[remoteIP[:remotePORT[-remotePORT]]]

……………..

The natd utility provides a Network Address Translation facility for use with divert(4) sockets under FreeBSD.

……………..

-port | -p port
Read from and write to divert(4) port port

По умолчанию natd «слушает» сокет 8668, если он у вас вдруг уже занят, то в примере я буду запускать на 8670. Итак запустим сам natd:

natd -p 8670 -s -m -a 8.8.8.8 -redirect_port tcp 10.0.2.18:80 8080

Теперь надо завернуть, только нужный нам трафик, в divert socket, для этого добавим правила ipfw:

ipfw add 700 divert 8670 tcp from any to 8.8.8.8 8080
ipfw add 710 divert 8670 tcp from 10.0.2.18 80 to any

Будьте внимательными с номерами правил, не забывайте о том, что ipfw идет по номерам сверху вниз и ищет более точное совпадение и если выше этих правил будут стоять правила с лучшим совпадением, то трафик до этих правил не дойдет.

Не лишним будет добавить разрешающие правила, например если у вас firewall закрытого типа:

ipfw add 720 allow  tcp from any to 10.0.2.18 80
ipfw add 730 allow  tcp from 10.0.2.18 80 to any

Ну собственно на этом все.

Теперь можно убедиться что все работает зайдя браузером по линку: http://8.8.8.8:8080 и глянув в tcpdump на внутреннем интерфейсе:

tcpdump -ni em1 host 10.0.2.18

Где должны быть видны запросы извне и ответы от 10.0.2.18.

Если у вас возникнут проблемы, то траблшутинг начните с просмотра tcpdump, добавлением ключа -v к запуску natd, добавив слово log в добавленные правила ipfw.

Эти действия помогут вам разобраться и найти причину проблемы.

Но вернемся к первоначальному вопросу. Теперь схема выглядит так:

Интернет <==> (<— default GW) [8.8.8.8] Сервер с реальником [10.0.2.2/24]<===> [10.0.2.18/24] Железка с внутренним адресом

и вариант описанный выше уже не работает. Почему ?

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

Считаем что мы извне обращаемся с адреса 1.1.1.1 и в tcpdump`е будет примерно следущее:

10:20:49.689619 IP 1.1.1.1.52583 > 10.0.2.18.80: S 426822729:426822729(0) win 65535
10:20:49.694417 IP 1.1.1.1.52583 > 10.0.2.18.80: . ack 1 win 260
10:20:49.694750 IP 1.1.1.1.52583 > 10.0.2.18.80: P 1:241(240) ack 1 win 260

Т.е. запросы извне к железке мы видим, но ни одного ответа от неё нет. Почему ? А вы ещё не забыли, что у 10.0.2.18 нет default gateway ? Вот потому и не отвечает, т.к. не знает куда ответить.

Что с этим делать ? Да как обычно 🙂 Решать проблему.

Для этого нам понадобится ещё один natd. Что он будет делать ? А он будет подменять SRC адрес «вопрощающего» (1.1.1.1) на свой внутренний адрес (10.0.2.2). Таким образом мы решим проблему того что на железке нет default gateway, т.к. отвечать она уже будет в свою подсеть.

Запустим второй процесс natd:

natd -s -m -a 10.0.2.2 -p 8671

Снова завернем трафик, добавим правила ipfw к уже добавленным выше:

ipfw add 705 divert 8671 tcp from any to 10.0.2.18 dst-port 80
ipfw add 706 divert 8671 tcp from 10.0.2.18 80 to 10.0.2.2

Как и в предыдущем случае обращаем внимание на номера правил ipfw.

Снова идем по линку http://8.8.8.8:8080 и смотрим в tcpdump, видим там уже другую картину:

10:43:48.573232 IP 10.0.2.2.53368 > 10.0.2.18.80: . ack 1 win 260
10:43:48.573577 IP 10.0.2.2.53368 > 10.0.2.18.80: P 1:241(240) ack 1 win 260
10:43:48.573967 IP 10.0.2.18.80 > 10.0.2.2.53368: . ack 241 win 32647
10:43:48.606660 IP 10.0.2.18.80 > 10.0.2.2.53368: P 1:92(91) ack 241 win 32647
10:43:48.656346 IP 10.0.2.18.80 > 10.0.2.2.53368: FP 92:457(365) ack 241 win 32647
10:43:48.660740 IP 10.0.2.2.53368 > 10.0.2.18.80: . ack 458 win 258
10:43:50.656411 IP 10.0.2.18.80 > 10.0.2.2.53368: R 1003605212:1003605212(0) win 0

Видим что SRC адрес изменился с 1.1.1.1 на 10.0.2.2, что нам и надо было и сразу же пошли ответы на запросы, что означает что линк открылся и в нем отобразился веб-интерфейс железки с внутренним адресом 10.0.2.18.

З.Ы. Не забываем убедиться, что переменная:

sysctl net.inet.ip.forwarding

выставлена в единицу:

net.inet.ip.forwarding: 1

З.Ы.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Пожалуйста, уважайте чужой труд.

Автор: Николаев Дмитрий (virus (at) subnets.ru)

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 4, среднее: 5,00 из 5)
Загрузка...
Отправить на почту Отправить на почту

Поводом для написания этой статьи послужила задача, которая возникла перед нами вчера.

Задача звучала просто: необходимо установить LG (Looking Glass) для отображения информации с BGP роутера FreeBSD с установленной quagga.

Что такое LG ?

Looking Glass позволяет выполнить на BGP роутере команды и отобразить результат их выполнения в web-интерфейсе:

  • show ip bgp
  • show ip bgp neighbors advertised-routes
  • show ip bgp summary
  • ping
  • traceroute

Для получения данных с роутера LG может использовать протоколы:  SSH, telnet или rsh.

Мы пользуемся telnet`ом.

LG мы всегда использовали один. Это разработка Cougar официальный сайт www.version6.net.

LG screenshot

Данный LG написан на языке программирования PERL и является CGI скриптом. Для соединения использует PERL модуль  Net::Telnet (/usr/ports/net/p5-Net-Telnet)

Последняя версия LG, доступная на это момент, датируется 25.11.2004 года и имеет номер 1.9.

Скачать исходный код можно на официальном сайте http://www.version6.net/lg/lg-1.9.tar.bz2 или с нашего сайта http://subnets.ru/files/lg-1.9.tar.bz2.

Ранее мы использовали этот LG для получения инфы с Juniper, а тут понадобилось получить с quagga (демон bgpd).

Установили LG, зашли в web-интерфейс LG и ….. и нифига. По нажатию на кнопку «Submit» LG просто долго «думает» (подвисает), а затем выдает страницу с запрошенной командой и пустым результатом.

Пара слов об установке.

В README автор достаточно четко описал что надо делать, повторяться мы не будем, но позволим себе добавить кусок конфига для HTTP сервера apache:

<VirtualHost XXX.XXX.XXX.XXX:80>
    ServerAdmin mymail@mydomain.ru
    DocumentRoot /usr/local/www/lg
    ServerName lg.subnets.ru

    ScriptAlias / /usr/local/www/lg/cgi/lg.cgi

    ErrorLog /var/log/http/lg_error.log
    CustomLog /var/log/http/lg_access.log common

    <Directory "/usr/local/www/lg">
        Options -Indexes FollowSymLinks MultiViews
        AllowOverride All
    </Directory>
</VirtualHost>

Сначала подумали, что мы напортачили в конфиге, но после перечитывания мануала и разнообразных вариантов конфига стало понятно, что дело не в нем.

Остро встал вопрос о debug`е действий LG, но разработчик не предусмотрел такой возможности 🙁  В логах появляется лишь строчка с запросом и ничего больше….

Пришлось лезть в исходки. В результате изысканий стало понятно, что проблема возникает уже после установки telnet соединения  между LG и quagga (демоном bgpd).

Это удалось понять используя более детальное логирование действий LG и просмотра вывода tcpdump:

tcpdump -Xni lo0 port 2605

Слушали ифейс lo0 (loopback) т.к. LG и quagga находтся на одном сервере и bgpd запущен командой:

/usr/local/sbin/bgpd -d -A 127.0.0.1

Возникает она потому что скрипт не может заматчить «command prompt», иными словами строку приглашения.

Что делать ? Разбираться с этим дальше уже нет времени, т.к. на выяснение проблемы уже убили кучу времени.

Тут я вспомнил про порт p5-Net-Telnet-Cisco (/usr/ports/net-mgmt/p5-Telnet-Cisco).  Примеры  использовании этого порта я показывал в статье Backup конфига Cisco на FTP.

Решил по быстрому попробовать такой вариант подключения по telnet к quagga. Сказано — сделано. Установил  порт p5-Net-Telnet-Cisco, поправил исходный код lg.cgi и все заработало.

Думаю что мы не единственные кто сталкивался/столкнулся/столкнется :))) с этой проблемой, надеюсь эта статья вам поможет.

Модифицированный нами код можно скачать тут: http://subnets.ru/files/lg-1.9.1.tar.gz
В архиве присутствуют файлы:

  • lg-1.9_ORIGINAL.tar.gz — это оригинальный архив от автора LG
  • lg.cgi.diff — это DIFF файл между оригинальной версией и модифицированной

Уточню, что код модифировался только в части отвечающий за подключение по telnet`у к quagga, остальной код остался без изменений.

Списки Looking Glass в Инете:

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Пожалуйста, уважайте чужой труд.

Авторы: Панфилов Алексей (lehis (at) subnets.ru) и Николаев Дмитрий (virus (at) subnets.ru)

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 1, среднее: 5,00 из 5)
Загрузка...
Отправить на почту Отправить на почту

Кто то уже знает, кто-то нет и спит спокойно, точнее пока что спит спокойно.

Как давно вы читали логи своего Asterisk сервера ?

Некоторые из вас или уже видели или ещё увидят в логах строчки:

  • Registration from ‘»100″<sip:100@sip.mydomain.ru>’ failed for ‘188.165.215.79’ — No matching peer found
  • Registration from ‘»111″ <sip:111@sip.mydomain.ru>’ failed for ‘188.165.215.79’ — Wrong password

Догадываетесь к чему они ведут ? К тому что вас сканят и пытаются подобрать пароль к вашим SIP аккаунтам.

Большинство пользователей безалаберно относятся к своим паролям, это факт, а раз так то проверте что на ваших SIP номерах не стоят пароли аля 123 или 1234.

Если пароль таки подберут, то вы (или ваш клиент) попадете на деньги, т.к. через вас пустят звонки забугор, например на Кубу или Северную Корею.

Давайте разберемся как они это делают и попробуем усложнить им жизнь помимо смены паролей к своим SIP аккаунтам.

В сети есть набор утилит sipvicious:

The 4 tools that you should be looking at are:svmapsvwarsvcracksvreportsvcrash

The tools: svmap — this is a sip scanner. When launched against ranges of ip address space, it will identify any SIP servers which it finds on the way. Also has the option to scan hosts on ranges of ports.

svwar — identifies working extension lines on a PBX. A working extension is one that can be registered. Also tells you if the extension line requires authentication or not.

svcrack — a password cracker making use of digest authentication. It is able to crack passwords on both registrar servers and proxy servers. Current cracking modes are either numeric ranges or words from dictionary files.

svreport — able to manage sessions created by the rest of the tools and export to pdf, xml, csv and plain text.

svlearnfp — allows you to generate new fingerprints by simply running the tool against a host. It will attempt to guess most values and allow you to save the information to the local fingerprint db. Then you can choose to upload it to the author so that it can be added to the database.

svcrash — responds to svwar and svcrack SIP messages with a message that causes old versions to crash.

Так вот с их помощью нас и сканят.  Эти же утилиты помогут нам просканить самих себя и  усложнить жизнь уродам жаждущих халявы.

Начнем с того что скачаем этот набор утилит (сохраненная у нас копия).

Распакуйте архив в какую нить папку и можно приступать к скану.

Будет считать что IP-адрес нашего Asterisk сервера это 192.168.1.1  и запустим сканер:

cd /home/virus/sipvicious

./svmap.py -p5060 192.168.1.1 -m INVITE

Получаем результат:

| SIP Device        | User Agent   | Fingerprint |
--------------------------------------------------
| 192.168.1.1:5060 | Asterisk PBX | disabled    |

Идем далее, посканим теперь на аккаунты:

./svwar.py —force -e100-999 192.168.1.1

Ответ может быть таким:

| Extension | Authentication |
------------------------------
| 210       | reqauth        |
| 300       | reqauth        |
| 666       | reqauth        |
| 241       | reqauth        |
| 242       | reqauth        |
| 222       | reqauth        |

Можно ли как то обломать их ? Можно. Для этого отредактируем /usr/local/etc/asterisk/sip.conf и добавим или раскоментируем строчку в секции [general]:

alwaysauthreject = yes

Описание:

When an incoming INVITE or REGISTER is to be rejected, for any reason, always reject with ‘401 Unauthorized’ instead of letting the requester know whether there was a matching user or peer for their request.

Т.е. наш сервер будет всегда при любых ошибках авторизации будет отвечать «401 Unauthorized» и не сообщать подробностей.

После изменения sip.conf зайдите в консоль Asterisk`а:

asterisk -r

и примените изменения:

asterisk*CLI> sip reload

Теперь посканим снова:

./svwar.py —force -e100-999 192.168.1.1

Ответ от сканера изменился и выглядит примерно так:

WARNING:TakeASip:Bad user = SIP/2.0 401  - svwar will probably not work!
WARNING:TakeASip:We got an unknown response
ERROR:TakeASip:Response: 'SIP/2.0 401 Unauthorized\r\n
Via: SIP/2.0/UDP 192.168.1.1:5061;branch=z9hG4bK-3613016185;received=192.168.1.1;rport=5061\r\n
From: "100"; tag=31303001333430333334313736\r\n
To: "100";tag=as47e73e29\r\nCall-ID: 2008271273\r\n
CSeq: 1 REGISTER\r\n
User-Agent: Asterisk PBX\r\n
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO\r\n
Supported: replaces\r\n
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="3b652f8d"\r\n
Content-Length: 0\r\n\r\n'

Как видите списка с номерами более не выдается, то что нам и надо.

Что ещё мы можем сделать ?

A. Например закрыть в диал-плане забугорные направления (коды стран), по которым не вы ни ваши пользователи не звонят или вообще перекрыть выход на международку.

Добавим в  /usr/local/etc/asterisk/extensions.conf в секцию где у вас происходит выход в город:

exten => _810X.,1,playback(pbx-invalid)

exten => _810X.,n,Hangup()

B. Так же мы можем скриптом анализировать логи Asterisk сервера и всех уродов, подбирающих пароль, банить фаирволом (ipfw) сервера.

Нашу версию подобного скрипта можно увидеть пройдя по ссылке: http://subnets.ru/files/protect_aster.txt

Инсталляция скрипта:

1. Сохраните код скрипта на своем сервере

2. Переименуйте файл в protect_aster.sh

3. Сделайте скрипт исполняемым:

chmod a+x protect_aster.sh

4. Добавте в ваш firewall ipfw правило:

ipfw add XXX reject ip from «table(56)» to me

где ХХХ это номер правила.

Будьте внимательны размещая данное правило, не забаньте сами себя ! Обеспечьте allow правила для своих IP-адресов выше этого правила, чтобы избежать неожиданностей.

5. Добавте скрипт на исполнение по crontab, отредактируйте /etc/crontab:

*/5    *       *       *       *       root    /full/path/to/script/protect_aster.sh

Забаненый IP-адрес попадает в таблицу ровно на сутки, через сутки он автоматически будет удален из таблицы.

C. В /usr/local/etc/asterisk/sip.conf, описывая секции пользователей (их номера) указывайте:

type=user

Пароли ставте минимум из 6-ти знаков с использованием букв и цифр.

Если известно с каких адресов будет авторизовываться пользователь, то будет совсем не лишним указать ACL с перечислением IP-адресов/подсетей из которых разрешено подключение, например:

[111]
type=user
context=users
disallow=all
allow = alaw
reinvite=no
canreinvite=no
callerid=User 111
language=ru
secret=Xm32rQ
mailbox=111
host=dynamic
deny=0.0.0.0/0
permit=217.172.16.74/30
nat=yes

В данном примере пользователю разрешено подключаться только из подсети 217.172.16.74/30 и запрещено из всех остальных. Не забудьте прописать пароль (secret=Xm32rQ) и в /usr/local/etc/asterisk/users.conf.

D. Измените план набора номеров для исходящих звонков. Добавте к номеру какой нибудь префикс, например 004 и «отрезайте» его (в моем примере это получается 3 цифры) перед тем как отправить своему провайдеру:
exten => _0048X.,1,Dial(SIP/${EXTEN:3}@sip-provider,60,rT)

Т.е. что бы набрать городской номер, пользователь должен набрать 00484951234567, халявщик этого точно знать не может, потому обломится, а мы ему поможем, дописав:
exten => _8X.,1,playback(pbx-invalid)

Тут же вы можете оставить свое «доброе» голосовое пожелание для таких уродов. Я так и сделал. высказал все что я о них думаю.

Надеемся, что эти не хитрые приемы помогут вам остаться при деньгах и сэкономить ваши нервы.

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Пожалуйста, уважайте чужой труд.

З.Ы.Ы. Ваши комментарии и дополнения к статье приветствуются.

Авторы: Панфилов Алексей (lehis (at) subnets.ru) и Николаев Дмитрий (virus (at) subnets.ru)

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 4, среднее: 5,00 из 5)
Загрузка...
Отправить на почту Отправить на почту

Делалось по статье http://tuxnotes.ru/articles.php?a_id=18
Тут приведу её полностью, со своими комментариями и дополнениями [в квадратных скобках].

В конце статьи будут приведены мои конфиги сервера и клиента.
—————————————————————————————————————

Создание сервера OpenVPN в FreeBSD

Однажды передо мной предстала задача реализации безопасного доступа из внешнего мира к внутренней корпоративной сети. На выходе из корпоративной сети стоял FreeBSD 7.0, в качестве реализации был выбран OpenVPN.
В данной статье я на примере из личной практики опишу процесс создания OpenVPN сервера на системе FreeBSD, с возможностью подключения к нему удаленных пользователей (с различных операционных систем: Windows, Linux, MacOS etc.).

Настройка проводилась на системе FreeBSD версии 7.0, настройка на других версиях аналогична данной.

Адрес внутренней сети — 192.168.1.0/24

1. Установка OpenVPN, создание сертификатов и ключей

Устанавливаем OpenVPN из портов:

cd /usr/ports/security/openvpn
make install clean

Далее создаем сертификаты и ключи:

cd /usr/local/share/doc/openvpn/easy-rsa/
[при моей инсталляции требуемые файлы лежали в /usr/local/share/doc/openvpn/easy-rsa/2.0]

Редактируем файл vars, содержащий переменные окружения:

chmod +w vars
vi vars

[также нужно отчмодить и скрипты в каталоге, за исключением файлов *.cnf и текстовых Makefile и README]

затем добавляем в файле vars к переменной export KEY_DIR=$D/keys еще каталог server (для удобства). Должно получиться так:

export KEY_DIR=$D/keys/server
[я не добавлял дополнительный каталог]

Загружаем переменные в оболочку:

sh
. ./vars

[таким образом переменные у меня не загрузились и чтобы не терять время на разборы, я сделал экспорт всех переменных вручную. они нужны только для создания файлов сертификации и т.д.]

создаем каталог keys и в нем подкаталог server

mkdir -p keys/server

создаем сертификат для сервера:

chmod +x build-ca
./build-ca

Пример ввода данных:

#./build-ca
Generating a 1024 bit RSA private key
....................++++++
...++++++
writing new private key to 'ca.key'
----- You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----

Country Name (2 letter code) [UA]:UA
State or Province Name (full name) [Kiev]:Kharkov
Locality Name (eg, city) [Kiev]:Kharkov
Organization Name (eg, company) [x]:server
Organizational Unit Name (eg, section) []:server
Common Name (eg, your name or your server's hostname) []:server
Email Address [root@localhost]:

Создаем файлы index.txt и serial:

touch /usr/local/share/doc/openvpn/easy-rsa/keys/server/index.txt
echo «00»>/usr/local/share/doc/openvpn/easy-rsa/keys/server/serial

Затем создаем сертификат X.509 для сервера. Всё необходимо заполнить аналогично и добавить строки с указанием пароля и имени организации:

chmod +x build-key-server
./build-key-server server

#./build-key-server server
Country Name (2 letter code) [UA]:UA
State or Province Name (full name) [Kiev]:Kharkov
Locality Name (eg, city) [Kiev]:Kharkov
Organization Name (eg, company) [x]:server
Organizational Unit Name (eg, section) []:server
Common Name (eg, your name or your server's hostname) []:server
Email Address [root@localhost]:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []: your_password
An optional company name []:server

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

Создаём ключ для клиента:

chmod +x build-key
./build-key client

# ./build-key client
Generating a 1024 bit RSA private key
........++++++
...................................++++++
writing new private key to 'client.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [KG]:UA
State or Province Name (full name) [NA]:Kharkov
Locality Name (eg, city) [BISHKEK]:Kharkov
Organization Name (eg, company) [OpenVPN-TEST]:server
Organizational Unit Name (eg, section) []:client
Common Name (eg, your name or your server's hostname) []:client
Email Address [me@myhost.mydomain]:root@localhost
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:your_password
An optional company name []:client

Стоит заметить, что поле organizationName должно совпадать с тем, которое мы ввели при создании сертификата сервера. В нашем случае это будет имя server.

Создаем ключ Диффи-Хелмана (необходим для безопасной авторизации двух сторон):

chmod +x build-dh
./build-dh

выходим из sh:

exit

Создаем ключ для tls-аутентификации:

openvpn —genkey —secret keys/server/ta.key

создаем каталоги для нашего openvpn-сервера:

cd /usr/local/etc/
mkdir openvpn
cd openvpn/
mkdir keys
mkdir ccd

Переходим в каталог /usr/local/etc/openvpn/keys и копируем в него необходимые для сервера ключи и сертификаты:

cd /usr/local/etc/openvpn/keyscp /usr/local/share/doc/openvpn/easy-rsa/keys/server/ca.crt
cp /usr/local/share/doc/openvpn/easy-rsa/keys/server/dh1024.pem
cp /usr/local/share/doc/openvpn/easy-rsa/keys/server/server.crt
cp /usr/local/share/doc/openvpn/easy-rsa/keys/server/server.key
cp /usr/local/share/doc/openvpn/easy-rsa/keys/server/ta.key

Когда сертификаты и ключи созданы, переходим к настройке OpenVPN-сервера.

2. Настройка сервера

в каталоге /usr/local/etc/openvpn создаем файл конфигурации нашего openvpn-сервера

touch server.conf

#указываем порт, на котором будет работать наш сервер
port 2000
# протокол будет использоваться udp (по идее он работает быстрее чем tcp)
proto udp
# используемый тип устройства и номер
dev tun0
#указываем файл CA
ca /usr/local/etc/openvpn/keys/ca.crt
#указываем файл с сертификатом сервера
cert /usr/local/etc/openvpn/keys/server.crt
#указываем файл с ключем сервера
key /usr/local/etc/openvpn/keys/server.key
#указываем файл Диффи Хельман
dh /usr/local/etc/openvpn/keys/dh1024.pem

#задаем виртуальный IP-адрес сервера и маску подсети, которые будут использоваться в нашем туннеле между сервером и удаленным клиентом
server 10.0.0.0 255.255.255.0

#указываем клиенту маршрут к серверу по виртуальному интерфейсу
push «route 10.0.0.0 255.255.255.0»

# указываем где хранятся файлы с настройками клиентов
client-config-dir ccd

# включаем TLS аутентификацию
tls-server
# указываем tls-ключ, и указываем 0 для сервера, а 1 для клиента
tls-auth keys/ta.key 0
# таймаут до реконекта
tls-timeout 120
auth MD5
# включаем шифрацию пакетов с использованием алгоритма симметричного шифрования Blowfish. Пока не было известно ни одно случая взлома данного алгоритма + он быстрее DES
cipher BF-CBC
[в моём случае шифрование не использовалась и поэтому этот пункт закомменчен]

#указывем, что каждые 10 секунд пинговать удаленный хост, и в случае если, в течении 120 секунд не будет ответа — то разрывать соединение
keepalive 10 120

# сжатие трафика
comp-lzo
[если эта опция используется на одной из сторон, она должна обязательно использоваться и другой стороной. иначе коннект будет рваться на этапе согласования MTU туннеля
между сервером и клиентом
]

# максимум клиентов
max-clients 100

#по умолчанию используется аутентификация пользователей по файлам сертификатов, то есть пользователь у себя хранит файлы сертификатов, соответственно пароль в таком случае не используется. На мой взгляд это не совсем безопасно (т.к. если кому-то удастся заполучить эти сертификаты, то он легко сможет получить доступ к нашей корпоративной сети). Я решил добавить к аутентификации по сертификатам еще и аутентификацию по паролю. Будет использоваться пара логин/пароль пользователя в системе FreeBSD ( которого необходимо заранее создать).
[разумеется, используется пользователь с паролем и без шелла — /usr/sbin/nologin
в случае автора эти логин-пароль при установлении соединения нужно ввести вручную, как сделать это автоматически рассмотрено ниже
]

Для добавления аутентификации по паролю подключаем плагин openvpn-auth-pam (который обычно идет вместе с пакетом OpenVPN):

plugin /usr/local/lib/openvpn-auth-pam.so loginuser nobody
group nobody

# Не перечитывать ключи после получения
# SIGUSR1 или ping-restart
persist-key
# Не закрывать и переоткрывать TUN\TAP
# устройство, после получения
# SIGUSR1 или ping-restart
persist-tun
# логирование (не забудьте создать дирректорию /var/log/openvpn/)
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log

# Уровень информации для отладки
verb 3

затем создаем в каталоге ccd файл с настройками удаленного клиента (имя файла должно строго совпадать с именем сертификата, то есть в нашем случае это имя client) следующего содержания:

push «route 192.168.1.0 255.255.255.0»

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

добавляем в файл /etc/rc.conf следующие строчки, для атоматического запуска openvpn-сервера при загрузке системы

openvpn_enable=»YES»
openvpn_if=»tun»
openvpn_configfile=»/usr/local/etc/openvpn/server.conf»
openvpn_dir=»/usr/local/etc/openvpn»

Если у вас стоит фаервол, то не забудьте открыть в нем порт. У меня стоит pf, я добавляю следующие правила:

set skip on tun0
pass in inet proto udp from any to $ext_if port 2000 keep state
pass quick on tun0

Не забудьте указать в /etc/rc.conf:

gateway_enable=»YES»

для того, что что бы ваше сервер мог перенаправлять пакеты.

[если до этого момента gateway_enable не было в /etc/rc.conf, то что бы применить изменения без перезагрузки выполните: sysctl net.inet.ip.forwarding=1]

Все. На этом настройка нашего сервера закончена.

3. Настройка клиента

С сервера необходимо скопировать созданные ранее сертификаты, но не все, а только необходимые пользователю, а именно: ca.crt, client.crt, client.key, dh1024.pem, ta.key.

В рабочем каталоге OpenVPN на стороне клиента создаем папку keys, куда и копируем вышеприведенные файлы. Затем создаем конфигурационный файл с любым именем, например client.ovpn, со следующим содержимым:

dev tun
proto udp
remote 11.11.11.11
#(вместо 11.11.11.11 необходимо указать внешний IP вашего сервера)
port 2000 #(порт к которому устанавливать соединение)
client
resolv-retry infinite
ca keys/ca.crt
cert keys/client.crt
key keys/client.key
tls-client
tls-auth keys/ta.key 1
auth MD5

auth-user-pass
# команда, указывающая клиенту использовать авторизацию по паролю
cipher BF-CBC
ns-cert-type server
comp-lzo
persist-key
persist-tun

#proxy 192.168.1.50:3128 #Раскомментируйте эту строчку, если вы работаете через прокси-сервер

status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 3

На этом настройка закончена. Все конфиги брались с рабочего сервера.
Процесс создания OpenVPN-сервера на других системах (Debian, Gentoo, Slackware, *BSD) будет аналогичен данному.
Тем и хорош OpenVPN.

Алексей Михайлов
Специально для tuxnotes.ru

[Мои конфиги сервера и клиента]

——————————————————————————-

Сервер:

local 77.87.200.10
port 2000
proto tcp
dev tun0
ca /usr/local/etc/openvpn/keys/ca.crt
cert /usr/local/etc/openvpn/keys/server.crt
key /usr/local/etc/openvpn/keys/server.key
dh /usr/local/etc/openvpn/keys/dh1024.pem

server 172.20.20.0 255.255.255.0 #примечание: сервер забирает себе при организации тунеля первые два адреса из подсети
push «route 172.20.20.0 255.255.255.0»
client-config-dir ccd
tls-server
tls-auth keys/ta.key 0
tls-timeout 120
auth MD5
#cipher BF-CBC
keepalive 10 120
comp-lzo
max-clients 1
plugin /usr/local/lib/openvpn-auth-pam.so login
user nobody
group nobody
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 3

#tun-mtu 1450 #примечание: можно регулировать размер MTU (должен быть одинаковым на сервере и на клиенте)

Клиент:

dev tun
proto tcp
remote 77.87.200.10
port 2000
client
resolv-retry infinite
ca keys/ca.crt
cert keys/client.crt
key keys/client.key
tls-client
tls-auth keys/ta.key 1
auth MD5
auth-user-pass
#cipher BF-CBC
ns-cert-type server
comp-lzo
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 3

#tun-mtu 1450 #примечание: см. сервер
auth-user-pass keys/account #примечание: в текстовом файле account двумя отдельными строками хранятся логин и пароль
auth-nocache #примечание: чтобы логин-пароль не оставались на клиентской стороне в памяти

=========================================================================

[Конфиги OpenVPN (в режиме server) для сервера и клиента под Windows]

——————————————————————————-

Качаем OpenVPN клиента под Windows: http://swupdate.openvpn.net/community/releases/openvpn-2.1.4.tar.gz

Конфиг клиента Windows

C:\Program Files\OpenVPN\config\config.ovpn:

auth-user-pass
remote 191.XXX.XXX.1
port 2000
dev tun
dev-node MyTap
proto tcp
client
resolv-retry infinite
ca C:/Progra~1/OpenVPN/keys/ca.crt
cert C:/Progra~1/OpenVPN/keys/client.crt
key C:/Progra~1/OpenVPN/keys/client.key
tls-client
tls-auth C:/Progra~1/OpenVPN/keys/ta.key 1
auth MD5
cipher BF-CBC
ns-cert-type server
persist-key
persist-tun
verb 3
route-method exe
route-delay 30
ping 5
ip-win32 netsh

Конфиг клиента FreeBSD

/usr/local/etc/openvpn/server.conf:

local 191.XXX.XXX.1
port 2000
proto tcp
dev tun
ca /usr/local/etc/openvpn/keys/ca.crt
cert /usr/local/etc/openvpn/keys/server.crt
key /usr/local/etc/openvpn/keys/server.key
dh /usr/local/etc/openvpn/keys/dh1024.pem
topology subnet
server 10.8.0.0 255.255.255.0
route 10.8.0.0 255.255.255.248
client-config-dir ccd
tls-server
tls-auth keys/ta.key 0
tls-timeout 120
auth MD5
#cipher BF-CBC
keepalive 10 20
#ping-restart 20
#comp-lzo
max-clients 2
ifconfig-pool-persist ipp.txt 0
plugin /usr/local/lib/openvpn-auth-pam.so login
user nobody
group nobody
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
#log /var/log/openvpn/openvpn.log
verb 3
log-append /var/log/openvpn/openvpn.log
duplicate-cn
tun-mtu 1500
mssfix
#for udp packets
#fragment 1300

В этом файле мы назначаем нашим 2м клиентам (логины client и client2) статические IP-адреса, /usr/local/etc/openvpn/ipp.txt:
client,10.8.0.3
client2,10.8.0.2

затем в папке /usr/local/etc/openvpn/ccd создаем два файла, имена файлов соответствуют логинам клиентов, в которых описываем персональные настройки для клиентов:

/usr/local/etc/openvpn/ccd/client
push «ip-win32 manual»
ifconfig-push 10.8.0.3 255.255.255.248

/usr/local/etc/openvpn/ccd/client2
push «ip-win32 manual»
ifconfig-push 10.8.0.2 255.255.255.248

При этом в vipw клиенты заведены так:

client:$1$SOigCh/z$Kj8.cP166D9ecve5XoJMh0:65530:65530::0:0:account for openvpn client:/nonexistent:/usr/sbin/nologin
client2:$1$SOigCh/z$Kj8.cP166D9ecve5XoJMh0:65531:65531::0:0:account for openvpn client2:/nonexistent:/usr/sbin/nologin

При использовании Windows XP SP#2 может понадобиться следущее:

http://michaelellerbeck.com/2008/10/27/openvpn-client-hangs-on-dhcp-renewal-gets-apipa-address-instead/

1. Отключить windows firewall на TAP интерфейсе, через «Сетевое окружение» в свойствах соединения
2. Скачать devcon.exe с сайта Microsoft http://support.microsoft.com/kb/311272
3. Переименовать TAP ифейс в «сетевом окружении» в MyTap
4. Через консоль войти в папку с devcon.exe и выполнить:

devcon hwids =net @root\NET\*

Обычно выдаст имя  tap0901, которое будет использоваться ниже.
5. Создать два файла .bat в папке OpenVPN\config, название файлов должны начинаться с названия файла конфига (в моем примере это config.ovpn):
C:\Program Files\OpenVPN\config\config_pre.bat:
devcon enable tap0901
C:\Program Files\OpenVPN\config\config_down.bat:
devcon disable tap0901

Gui OpenVPN`а  будет запускать эти два файла при старте и закрытии соединения.

6. IP-адреса клиентов явно прописать на TAP интерфейсе MyTap (через «Сетевое окружение» в свойствах соединения) с маской как указано в конфиге сервера.

=========================================================================

[Конфиги OpenVPN (в режиме P2P) для сервера FreeBSD и клиента FreeBSD]

10.8.0.1 — тунельный IP-адрес сервера

10.8.0.2 — тунельный IP-адрес клиента

Конфиг сервера

local 191.XXX.XXX.1
port 2000
proto udp
dev tun0
ca keys/ca.crt
cert keys/server.crt
key keys/server.key
dh keys/dh1024.pem

ifconfig 10.8.0.1 10.8.0.2
topology p2p
tls-server
tls-auth keys/ta.key 0
tls-timeout 120
auth MD5
#cipher BF-CBC
keepalive 10 20
#ping-restart 20
#comp-lzo
max-clients 1
plugin /usr/local/lib/openvpn-auth-pam.so login
user nobody
group nobody
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
verb 3
log-append /var/log/openvpn/openvpn.log
#duplicate-cn  #указывается если мы хотим что бы под одним сертификатом могло ходить несколько клиентов
tun-mtu 1500
mssfix
#for udp packets
fragment 1300

#Назначаем нашему клиенту IP-адрес

push «ifconfig 10.8.0.2 10.8.0.1»

Конфиг клиента

dev tun0
proto udp
remote 191.XXX.XXX.1
port 2000
client

# Т.к. в конфиге сервера мы уже назначили клиенту IP-адрес, то строчку с ifocnfig тут можно закоментить

#ifconfig 10.8.0.2 10.8.0.1

resolv-retry infinite
ca keys/ca.crt
cert keys/client.crt
key keys/client.key
tls-client
tls-auth keys/ta.key 1
auth MD5
auth-user-pass
#cipher BF-CBC
keepalive 10 20
ns-cert-type server
#comp-lzo
persist-key
persist-tun
status /var/log/openvpn/openvpn_client-status.log
verb 3
auth-user-pass account
#auth-nocache
user nobody
group nobody
log-append /var/log/openvpn/openvpn_client.log
mssfix
tun-mtu 1500
fragment 1300

Комментарии

1. Если хочется назначать адрес OpenVPN-клиенту с сервера, то в server.conf нужно описать его в строке push, а на клиенте  (в конфиге) строчку ifconfig не писать вовсе.

2. Очень хорошо человек написал, что помогло нам решить проблему рассматриваемую в п. 4, процитирую его (оригинал: http://www.securitylab.ru/forum/forum21/topic42044/)

у OpenVPN есть два режима работы: а) p2p (point to point).
б) server mode.P2P режим был предусмотрен в OpenVPN изначально с самых ранних версий. Он предназначен только для одного соединения типа «точка — точка». Для примера можно привести ситуацию, в которой посредством OpenVPN необходимо соединить два офиса (возможно это как раз ситуация, аналогичная Вашей). В этом случае tun/tap, интерфейс OpenVPN соединения можно сравнить с обычным PPP интерфейсом, а для межсетевого обмена трафиком между peer’ами необходимо просто поднять на каждом из них соответсвующие маршруты через опцию route.

Server mode — это относительно новая фича, которая поддерживается в OpenVPN начиная с версии 2.0. Именно этот режим Вы и выбрали, включив в конфигурационный файл своего сервера опцию «server 10.8.0.0 255.255.255.0». Попробую объяснить в чем суть этого режима. OpenVPN работает через tun или tap интерфейсы. В отличие от p2p, server mode позволяет работать нескольким клиентам (peer’ам) одновременно c одним и тем же сервером, причем через один и тот же tun/tap интерфейс. В связи с этим изменяется и механизм межсетевой маршрутизации. На стороне клиента никаких изменений нет, но на стороне сервера добавляется дополнительный уровень инкапсуляции. Это значит, что при отправке пакета в клиентскую сеть, серверу недостаточно просто бросить его в tun0. Необходимо также каким-то образом указать какому именно клиенту данный пакет предназначен. Стандартным параметром route уже не обойтись т.к. он только направляет пакеты в tun0 к OpenVPN не указывая на конкретного peer’а-адресата. Здесь необходим дополнительный уровень маршрутизации. Эта маршрутизация реализована в OpenVPN посредством опции iroute совместно с опцией client-config-dir (см. ниже).

3.  Если после коннекта в логах клиента:

SENT CONTROL [server]: ‘PUSH_REQUEST’ (status=1)

а в логах сервера:

PUSH: Received control message: ‘PUSH_REQUEST’

и далее ничего  не происходит, а строчки повторяются и повторяются, но адреса на туннеле со стороны клиента не появляются, то попробуйте на сервере (в конфиге) push`уть любую строчку, если там ничего не push`иться (например IPшник клиента (ifcоnfig)), то можно push`уть например:

push «dhcp-option DNS 8.8.8.8»

4. Важное замечание, что если OpenVPN запускается в режиме server (см. комментарии п.2), то статический или динамический  маршрут, даже который смотрит правильно и напрямую в интерфейс tun, ни к чему не приведет, работать не будет.

Т.к. в режиме server получается point-to-multipoint линк и именно поэтому серверу надо уже объяснять какому клиенту за ифейсом tun нужно отправлять трафик. Поэтому туннельные интерфейсы могут пинговаться, а любые подсети за OpenVPN-клиентом нет, т.к. трафик не уедет в туннель.

Это хорошо видно по tcpdump, если с OpenVPN-сервера попробовать попинговать любой адрес из подсети, которая находится ЗА OpenVPN-клиентом.

С одной стороны (со стороны OpenVPN-сервера) трафик в tun виден, а до другой стороны трафик просто не доходит, а если быть точнее, то на самом деле трафик с OpenVPN-сервера просто не отправляется.

Ответ кроется в этом:

By default, when an OpenVPN client is active, only network traffic to and from the OpenVPN server site will pass over the VPN.

Что бы решить данную проблему нужно или переходить на режим p2p или прописать route и iroute на стороне OpenVPN-сервера (см. http://openvpn.net/index.php/open-source/documentation/howto.html):

Including multiple machines on the client side when using a routed VPN (dev tun)In a typical road-warrior or remote access scenario, the client machine connects to the VPN as a single machine. But suppose the client machine is a gateway for a local LAN (such as a home office), and you would like each machine on the client LAN to be able to route through the VPN.For this example, we will assume that the client LAN is using the 192.168.4.0/24 subnet, and that the VPN client is using a certificate with a common name of client2. Our goal is to set up the VPN so that any machine on the client LAN can communicate with any machine on the server LAN through the VPN.

Before setup, there are some basic prerequisites which must be followed:
The client LAN subnet (192.168.4.0/24 in our example) must not be exported to the VPN by the server or any other client sites which are using the same subnet. Every subnet which is joined to the VPN via routing must be unique.
The client must have a unique Common Name in its certificate («client2» in our example), and the duplicate-cn flag must not be used in the OpenVPN server configuration file.

First, make sure that IP and TUN/TAP forwarding is enabled on the client machine.

Next, we will deal with the necessary configuration changes on the server side. If the server configuration file does not currently reference a client configuration directory, add one now:
client-config-dir ccd

In the above directive, ccd should be the name of a directory which has been pre-created in the default directory where the OpenVPN server daemon runs. On Linux this tends to be /etc/openvpn and on Windows it is usually \Program Files\OpenVPN\config. When a new client connects to the OpenVPN server, the daemon will check this directory for a file which matches the common name of the connecting client. If a matching file is found, it will be read and processed for additional configuration file directives to be applied to the named client.

The next step is to create a file called client2 in the ccd directory. This file should contain the line:
iroute 192.168.4.0 255.255.255.0

This will tell the OpenVPN server that the 192.168.4.0/24 subnet should be routed to client2.

Next, add the following line to the main server config file (not the ccd/client2 file):
route 192.168.4.0 255.255.255.0

Why the redundant route and iroute statements, you might ask? The reason is that route controls the routing from the kernel to the OpenVPN server (via the TUN interface) while iroute controls the routing from the OpenVPN server to the remote clients. Both are necessary.

Next, ask yourself if you would like to allow network traffic between client2’s subnet (192.168.4.0/24) and other clients of the OpenVPN server. If so, add the following to the server config file.
client-to-client
push «route 192.168.4.0 255.255.255.0»

This will cause the OpenVPN server to advertise client2’s subnet to other connecting clients.

The last step, and one that is often forgotten, is to add a route to the server’s LAN gateway which directs 192.168.4.0/24 to the OpenVPN server box (you won’t need this if the OpenVPN server box is the gateway for the server LAN). Suppose you were missing this step and you tried to ping a machine (not the OpenVPN server itself) on the server LAN from 192.168.4.8? The outgoing ping would probably reach the machine, but then it wouldn’t know how to route the ping reply, because it would have no idea how to reach 192.168.4.0/24. The rule of thumb to use is that when routing entire LANs through the VPN (when the VPN server is not the same machine as the LAN gateway), make sure that the gateway for the LAN routes all VPN subnets to the VPN server machine.

Similarly, if the client machine running OpenVPN is not also the gateway for the client LAN, then the gateway for the client LAN must have a route which directs all subnets which should be reachable through the VPN to the OpenVPN client machine.

Т.е. возмем наш пример с конфигурацией в режиме server (рассмотренный выше) и допустим что за OpenVPN-клиентом, за его вторым интерфейсом с IP-адресом 192.168.1.1/24, находится подсеть 192.168.1.0/24.

Вот туннель установился, туннельные адреса прекрасно пингуются с обеих сторон, но вот мы берем и прописываем на OpenVPN-сервере маршрут:

route add 192.168.1.0/24 -iface tun0

запускаем  пинг до 192.168.1.1 и….. и ничего, пинга нет…… Почему ?

Для того что бы он появился ещё раз вникните в то, что написано выше и выполните следующие действия:

На OpenVPN-сервере в файле /usr/local/etc/openvpn/ccd/client (где, напомню вам, что название файла соответствует логину клиента) допишем:

iroute 192.168.1.0 255.255.255.0

Затем, там же на OpenVPN-сервере, поправим основной конфиг (server.conf) и добавим в него:

route 192.168.1.0 255.255.255.0

Перезапускайте OpenVPN с обоих сторон и запускайте пинг до 192.168.1.1 и он  будет в наличии.

Все конечно хорошо и здорово, НО есть нюанс…. А что если за OpenVPN-клиентом находится клиент подключенный по BGP и у него куча подсетей ??? Даже не смотря на то, что BGP сессия между OpenVPN-сервером и OpenVPN-клиентом установилась и маршруты приходят, трафик до подсетей анонсированых OpenVPN-клиентом через OpenVPN-сервер не пойдет, т.к. отсутствуют строчки с route и iroute в настройках OpenVPN-сервера. Варианта 2: а) переходить с режима server в режим p2p б) каждый раз описывать на OpenVPN-сервере route и iroute с подсетями клиента.

Как мне кажется, что если вы все же озадачились поднятием BGP через тунель OpenVPN, то проще будет перевести OpenVPN-сервер в режим p2p.

Ссылки

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Пожалуйста, уважайте чужой труд.

Автор: Будимиров Максим (madmax (at) subnets.ru) и Николаев Дмитрий (virus (at) subnets.ru)

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 5, среднее: 4,60 из 5)
Загрузка...
Отправить на почту Отправить на почту