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

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

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

Задача

Необходимо создать внутри одного физического роутера отдельную роутинг таблицу для одного клиента и двух его апстримов.

Иными словами нужно что бы эти три пира «жили» в своей таблице маршрутизации и не имели отношения к основной таблице маршрутизации.
Каждая таблица будет «жить» по своим законам и трафик будет ходить по своим маршрутам.

Имеем

  • Juniper M10i
  • JUNOS 10.1R1.8

Решение

Решить эту задачу нам поможет  routing-instances.

Благодаря им мы можем создать несколько таблиц маршрутизации и явным образом указать для каких интерфейсов роутера её использовать.

Читаем доку: Configuring Routing Instances

Первый возникающий вопрос это какого типа routing-instances нам нужен ? Смотрим описание:

  • forwarding—Provide support for filter-based forwarding, where interfaces are not associated with instances. All interfaces belong to the default instance. Other instances are used for populating RPD learned routes. See Configuring Filter-Based Forwarding.
  • l2vpn—Provide support for Layer 2 VPNs. For more detailed information about configuring VPNs, see the JUNOS VPNs Configuration Guide.
  • layer2-control—(MX Series routers only) Provide support for RSTP or MSTP in customer edge interfaces of a VPLS routing instance. For more detailed information about configuring RSTP and MSTP, see the JUNOS MX Series Ethernet Services Routers Layer 2 Configuration Guide
  • no-forwarding—This is the default routing instance. Do not create a corresponding forwarding instance.
  • virtual-router—Similar to a VPN routing and forwarding instance type, but used for non-VPN-related applications. There are no VRF import, VRF export, VRF target, or route distinguisher requirements for this instance type.
  • virtual-switch—(MX Series routers only) Provide support for Layer 2 bridging. Use this routing instances type to isolate a LAN segment with its Spanning Tree Protocol (STP) instance and separates its VLAN identifier space. For more detailed information about configuring a virtual switch, see the JUNOS MX Series Ethernet Services Routers Layer 2 Configuration Guide and the JUNOS MX Series Ethernet Services Routers Solutions Guide.
  • vpls—Virtual private local-area network (LAN) service. Use this routing instance type for point-to-multipoint LAN implementations between a set of sites in a VPN. For more information about configuring VPLS, see the JUNOS VPNs Configuration Guide.
  • vrf—VPN routing and forwarding instance. Provides support for Layer 3 VPNs, where interface routes for each instance go into the corresponding forwarding table only. For more information about configuring VPNs, see the JUNOS VPNs Configuration Guide.

To configure a routing instance type, include the instance-type statement:

routing-instances {
     routing-instance-name {
           interface interface-name;
           instance-type (forwarding | l2vpn | layer2-control | no-forwarding | virtual-router | virtual-switch | vpls | vrf);
     }
}

Если вы общались с железом от Cisco, то первое что вам бросится в глаза, так это знакомое слово VRF (либо вы уже слышали/настраивали VRF-lite).

В моем случае мне походит тип virtual-router, т.к. VPN`а у меня нет, а все что мне нужно это создать вторую, отдельную от основной, таблицу маршрутизации, которая будет действовать только в пределах данного роутера.

Приступим

Исходные данные для нашего VRF:
VRF апстрим #1:

  • подключен к физическому интерфейсу: ge-0/0/1.0
  • ASN: 100
  • IP-адрес: 1.1.1.1/30

VRF апстрим #2:

  • подключен к физическому интерфейсу: ge-0/0/2.0
  • ASN: 200
  • IP-адрес: 2.2.2.1/30

VRF клиент #1:

  • подключен к физическому интерфейсу: ge-0/1/0.0
  • ASN: 300
  • IP-адрес: 3.3.3.2/30

Назовем наш VRF именем test, а наш номер AS будет 400.

Обращаю ваше внимание так это на то, что конфигурацию протокола BGP у основного роутера мы не трогаем, т.е. никаких изменений туда вносить не надо.
Подмечу, что конфигурацию самих физических интерфейсов и policy-statement (роут мапов) для пиров в нашем VRF нужно производить в режиме конфигурирования основного роутера, а не в routing-instances test.

Заходим в режим конфигурирования:

root@juniper> configure

Затем перейдем в уровень routing-instances:

root@juniper# edit routing-instances

После чего нам нужно задать имя нашего routing-instance (допустим test) и задать в нем остальные настройки, в том числе настройки протокола BGP.

[edit routing-instances]
root@juniper#
set test description «test routing table»

Зададим тип  routing-instance:

[edit routing-instances]
root@juniper#
set test instance-type virtual-router

Затем укажем какие интерфейсы роутера помещать в данный instance (в моем случае это будет три интерфейса, т.к. три пира и каждый в своем интерфейсе, это могут быть как целиком физические интерфейсы, так и вланы):

[edit routing-instances]
root@juniper#
set test  interface ge-0/0/1.0
root@juniper# set test  interface ge-0/0/2.0
root@juniper# set test  interface ge-0/1/0.0

Дальнейшая настройка routing-instance ничем не отличается от настройки основного роутера. Те же секции, те же команды. Не буду далее описывать каждую команду и покажу что мы должны получить на выходе по нашему routing-instance test:
[edit]
root@juniper#
show routing-instances test

test {
    description "test routing table";
    instance-type virtual-router;
    interface ge-0/0/1.0;
    interface ge-0/0/2.0;
    interface ge-0/1/0.0;
    routing-options {
        router-id 1.1.1.2;
        autonomous-system 400;
    }

    protocols {
        bgp {
            path-selection always-compare-med;
            traceoptions {
                file bgp_vrf.log size 1m files 10;
            }
            log-updown;
            remove-private;
            local-as 400;
            group upstreams {
                type external;
                no-advertise-peer-as;
                neighbor 1.1.1.1 {
                    description VRF_Upstream_1;
                    import vrf-upstream-1-in;
                    export vrf-customer;
                    remove-private;
                    peer-as 100;
                }
                neighbor 2.2.2.1 {
                    description VRF_Upstream_2;
                    import vrf-upstream-2-in;
                    export vrf-customer;
                    peer-as 200;
                }
            }
            group customers {
                neighbor 3.3.3.2 {
                    description VRF_client_1;
                    import vrf-client-in;
                    export vrf-client-out;
                    peer-as 300;
                }
            }
        }
    }
}

Собственно на этом конфигурация VRF и закончена. Как видно из конфига мы настроили BGP протокол внутри VRF`а где апстримов поместили в группу upstreams, а нашего клиента в группу customers.

Теперь остается настроить сами физические интерфейсы и создать полиси-мапы (vrf-upstream-1-in, vrf-customer, vrf-upstream-2-in, vrf-customer, vrf-client-in, vrf-client-out).

Напоминаю, что это делается в режиме «глобального» конфигурирования роутера, а не в routing-instance test.

Что мы должны увидеть после коммита данного конфига ?

По команде:

[edit]
root@juniper#
run show bgp summary

мы увидим что появилась ещё одна роутинг таблица, в которой перечислены наши VRF пиры.

Так же можно посмотреть что там с маршрутами в нашей routing-instance test:

[edit]
root@juniper#
run show route table test.inet.0

Несколько заметок, например запустив пинг до нашего VRF клиента командой:

[edit]
root@juniper#
run ping 3.3.3.2

не удивляйтесь что пинга нет, даже при наличии линка на физическом интерфейсе и не торопитесь с выводами, что физика не работает или с той стороны не настроен IP-адрес, просто вы забыли о том, что вы выполняете эту команду из основного роутера, а ведь физический интерфейс в сторону VRF-клиента принадлежит routing-instance test и основной роутер действительно не знает маршрут в эту подсеть.

Меняем команду на:

[edit]
root@juniper#
run ping 3.3.3.2 routing-instance test
и вот он наш пинг:

PING 3.3.3.2 (3.3.3.2): 56 data bytes
64 bytes from 3.3.3.2: icmp_seq=0 ttl=255 time=0.660 ms
64 bytes from 3.3.3.2: icmp_seq=1 ttl=255 time=0.647 ms
^C
--- 3.3.3.2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.647/0.653/0.660/0.007 ms

т.е. мы явно сказали роутеру какой instance использовать для отправки пакетов до хоста 3.3.3.2.

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

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

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 3, среднее: 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)
Загрузка...
Отправить на почту Отправить на почту

Думаю многим из вас знаком сайт http://www.robtex.com на котором много полезных вещей и одна из них это графическое отображение связей заданной AS.

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

Но есть вещи которых нет в графическом отображении  www.robtex.com. Например он не показывает даунстримов (клиентов) для заданной AS. Соответственно нет инфы, которая нужна админу транзитного оператора, который настраивает фильтры под клиентов. Инфа бы помогла увидеть «кольца» в маршрутизации его клиентов через другие связанные с ним AS.

Так же что-то непонятное творится с кешированием. Много раз замечал на AS`ках, которых обслуживаю, что инфа на www.robtex.com не соответствует текущей ситуации иногда даже через месяц после изменений. Т.е. ты что-то поменял, но измений не видно… и долго не видно.

На просторах «тырнета» была обнаружена либа «JavaScript Graph Library» -> Dracula Graph Library, которая отображает связности между объектами.

Dracula Graph Library работает на векторной библиотеке Raphaël, разработанной  Дмитрием  Барановским.

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

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

Итак, готовы вам представить первую версию собственного скрипта отображающий инфу по AS в графическом виде —>  «Построение графа связанности AS по ее номеру«.

Где можно указать номер AS, а так же:

  • тип выводимой информации: апстримы/даунстримы
  • выбрать глубину рекурсии

Вся информация берется из БД RIPE, которая доступна в выводе информации по номеру AS: http://www.db.ripe.net/whois?ASXXXXX (где XXXXX номер AS).

Пример вывода скрипта по нашей AS:

AS graph example

AS graph example

  • Красные стрелочки -> Апстримы
  • Зеленые стрелочки -> Даунстримы

Как вы понимаете автономка автономке рознь, т.е. кол-во апстримов и даунстримов у крупного оператора может быть большим, поэтому во избежание зависания вашего браузера выставлен лимит по кол-ву отображаемых на экране объектов, в 200 шт.

RIPE ессно не в восторге если каждый раз при выводе обращаться к их БД и они могут заблочить IP, если он будет обращаться к их БД очень часто.

Посему кеш у нашей тулзы тоже есть, но он не такой «жестокий» и составляет не более 3-х суток.

Не всегда расположение объектов на странице вывода является оптимальным, для этого в конце страницы есть кнопка «перерисовать», либо вы сами можете  таскать любой объект (круг с номером AS) на экране и расставить их так, как нравится вам.

Информация заносимая админами в описание их AS в БД RIPE может различаться, т.к. способов написания import/export несколько. Мы постарались учесть самые распространенные из них, но мы предполагаем, что вы, уважаемые посетители, можете найти AS, картинка по которой может отображаться не совсем правильно. Если это так, то просим Вас сообщить нам о такой через форму «обратной связи» у нас на сайте.

И опережая вопросы: ДА, мы думали над тем, что бы брать информацию не из БД RIPE, а непосредственно из таблицы маршрутизации (full-view) BGP роутеров. Возможно, мы сделаем это в следующих версиях скрипта когда руки дойдут 🙂

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

Надеемся, что эта тулза поможет не только нам, поэтому и решили разместить её на нашем сайте в свободном доступе 🙂

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

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 4, среднее: 4,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)
Загрузка...
Отправить на почту Отправить на почту