Онлайн
Alvaros
.
- Регистрация
- 14.05.16
- Сообщения
- 21.452
- Реакции
- 101
- Репутация
- 204
Привет! В
Начать стоит с того, что у нас как у оператора связи есть своя огромная MPLS-сеть, которая для клиентов фиксированной связи поделена на два основных сегмента — тот, что используется непосредственно для доступа в сеть Интернет, и тот, что используется для создания изолированных сетей — и именно через этот сегмент MPLS ходит трафик IPVPN (L3 OSI) и VPLAN (L2 OSI) для наших корпоративных клиентов.
Обычно подключение клиента происходит следующим образом.
До офиса клиента прокладывается линия доступа от ближайшей Точки Присутствия сети (узла MEN, РРЛ, БССС, FTTB и т.д.) и далее, канал прописывается по транспортной сети до соответствующего РЕ-MPLS-маршрутизатора, на котором мы выводим ее в специально создаваемый для клиента VRF c учетом профиля трафика, который необходим клиенту (метки профиля выбираются для каждого порта доступа, основываясь на значениях ip precedence 0,1,3,5).
Если по каким-то причинам мы не можем полноценно организовать у клиента последнюю милю, например, офис клиента находится в бизнес-центре, где в приоритете другой провайдер, или рядом просто нет нашей точки присутствия, то раньше клиентам приходилось создавать несколько IPVPN-сетей у разных провайдеров (не самая выгодная по цене архитектура) или самостоятельно решать вопросы с организацией доступа к с своему VRF поверх сети Интернет.
Многие делали это с помощью установки IPVPN-интернет шлюза — устанавливали граничный маршрутизатор (аппаратный или какое-либо решение на базе Linux), подключали к нему одним портом IPVPN-канал, а другим — Интернет-канал, запускали на нём свой VPN-сервер и подключали пользователей через свой собственный VPN-шлюз. Естественно, такая схема порождает и обременения: подобную инфраструктуру нужно уметь строить и, что самое неудобное — эксплуатировать и развивать.
Чтобы упростить нашим клиентам жизнь, мы установили централизованный VPN-хаб и организовали поддержку включений поверх интернета с использованием IPSec, то есть теперь клиентам, нужно только настроить свой роутер для работы с нашим VPN-хабом по IPSec-туннелю через любой публичный интернет, и мы выпустим трафик этого клиента в его VRF.
Кому пригодится
Если развернуть всё у нас, то клиенты получают и полноценный саппорт по VPN, и серьезное резервирование инфраструктуры, и типовые настройки, которые заработают на любом привычном для него роутере (будь то хоть Cisco, хоть Mikrotik, главное, чтобы умел нормально поддерживать IPSec/IKEv2 со стандартизованными методами аутентификации). Кстати, про IPSec — прямо сейчас мы поддерживаем только его, но в планах запустить полноценную работу и OpenVPN, и Wireguard, чтобы клиенты могли не зависеть от протокола и еще проще взять и перенести все к нам, а также хотим начать подключать клиентов с компьютеров и мобильных устройств (встроенные в ОС решения, Cisco AnyConnect и strongSwan и подобные). При таком подходе де-факто построение инфраструктуры можно смело отдать оператору, оставив только настройку СРЕ или хоста.
Как происходит процесс подключения для режима IPSec:
Получающаяся схема связи выглядит примерно вот так:
Если каких-то примеров базовой конфигурации нет у клиента — то мы обычно помогаем с их формированием и делаем доступными для всех остальных.
Осталось подключить СРЕ в Интернет, сделать ping до ответной части VPN-туннеля и какого-либо хоста внутри VPN, и всё, можно считать, что подключение состоялось.
В следующей статье расскажем, как мы скомбинировали эту схему с IPSec и MultiSIM Резервированием с помощью CPE Huawei: ставим клиентам наше CPE Huawei, в котором может использоваться не только проводной интернет канал, но и 2 разных SIM-карты, и CPE автоматически перестраивает IPSec-туннель либо через проводной WAN, либо через радио (LTE#1/LTE#2), реализуя высокую отказоустойчивость итогового сервиса.
Отдельное спасибо за подготовку этой статьи (и, собственно, авторам этих техрешений) коллегам из нашего RnD!
You must be registered for see links
я описал работу нашего сервиса MultiSIM в части
You must be registered for see links
и
You must be registered for see links
каналов. Как было упомянуто, клиентов к сети мы подключаем через VPN, и сегодня я расскажу немного больше про VPN и наши возможности в этой части.Начать стоит с того, что у нас как у оператора связи есть своя огромная MPLS-сеть, которая для клиентов фиксированной связи поделена на два основных сегмента — тот, что используется непосредственно для доступа в сеть Интернет, и тот, что используется для создания изолированных сетей — и именно через этот сегмент MPLS ходит трафик IPVPN (L3 OSI) и VPLAN (L2 OSI) для наших корпоративных клиентов.
You must be registered for see links
Обычно подключение клиента происходит следующим образом.
До офиса клиента прокладывается линия доступа от ближайшей Точки Присутствия сети (узла MEN, РРЛ, БССС, FTTB и т.д.) и далее, канал прописывается по транспортной сети до соответствующего РЕ-MPLS-маршрутизатора, на котором мы выводим ее в специально создаваемый для клиента VRF c учетом профиля трафика, который необходим клиенту (метки профиля выбираются для каждого порта доступа, основываясь на значениях ip precedence 0,1,3,5).
Если по каким-то причинам мы не можем полноценно организовать у клиента последнюю милю, например, офис клиента находится в бизнес-центре, где в приоритете другой провайдер, или рядом просто нет нашей точки присутствия, то раньше клиентам приходилось создавать несколько IPVPN-сетей у разных провайдеров (не самая выгодная по цене архитектура) или самостоятельно решать вопросы с организацией доступа к с своему VRF поверх сети Интернет.
Многие делали это с помощью установки IPVPN-интернет шлюза — устанавливали граничный маршрутизатор (аппаратный или какое-либо решение на базе Linux), подключали к нему одним портом IPVPN-канал, а другим — Интернет-канал, запускали на нём свой VPN-сервер и подключали пользователей через свой собственный VPN-шлюз. Естественно, такая схема порождает и обременения: подобную инфраструктуру нужно уметь строить и, что самое неудобное — эксплуатировать и развивать.
Чтобы упростить нашим клиентам жизнь, мы установили централизованный VPN-хаб и организовали поддержку включений поверх интернета с использованием IPSec, то есть теперь клиентам, нужно только настроить свой роутер для работы с нашим VPN-хабом по IPSec-туннелю через любой публичный интернет, и мы выпустим трафик этого клиента в его VRF.
Кому пригодится
- Тем, у кого уже существует большая IPVPN-сеть и возникают потребности в новых подключениях в сжатые сроки.
- Всем, кто по каким-то причинам хочет перенести часть трафика с публичного интернета в IPVPN, но раньше сталкивался с техническими ограничениями, связанными с несколькими провайдерами услуг.
- Тем, у кого сейчас есть несколько разрозненных VPN-сетей у разных операторов связи. Существуют клиенты, у которых успешно организованы IPVPN и от Билайн, и от Мегафон, и от Ростелеком и т.д. Чтобы стало проще, можно остаться только на нашем едином VPN, все остальные каналы других операторов переключить на интернет, после чего подключаться к IPVPN Билайн через IPSec и интернет от этих операторов.
- Тем, у кого уже есть IPVPN-сеть, наложенная на Интернет.
Если развернуть всё у нас, то клиенты получают и полноценный саппорт по VPN, и серьезное резервирование инфраструктуры, и типовые настройки, которые заработают на любом привычном для него роутере (будь то хоть Cisco, хоть Mikrotik, главное, чтобы умел нормально поддерживать IPSec/IKEv2 со стандартизованными методами аутентификации). Кстати, про IPSec — прямо сейчас мы поддерживаем только его, но в планах запустить полноценную работу и OpenVPN, и Wireguard, чтобы клиенты могли не зависеть от протокола и еще проще взять и перенести все к нам, а также хотим начать подключать клиентов с компьютеров и мобильных устройств (встроенные в ОС решения, Cisco AnyConnect и strongSwan и подобные). При таком подходе де-факто построение инфраструктуры можно смело отдать оператору, оставив только настройку СРЕ или хоста.
Как происходит процесс подключения для режима IPSec:
- Клиент оставляет заявку своему менеджеру в которой указывает необходимую скорость подключения, профиль трафика и параметры IP адресации для туннеля (по умолчанию подсеть с маской /30) и тип маршрутизации(статика или BGP). Для передачи маршрутов до локальных сетей клиента в подключаемом офисе используются механизмы IKEv2 фазы протокола IPSec с помощью соответствующих настроек на клиентском маршрутизаторе, либо анонсируются по BGP в MPLS из указанного в заявке клиентом частного BGP AS. Таким образом информация о маршрутах клиентских сетей полностью контролируется клиентом через настройки клиентского маршрутизатора.
- В ответ от своего менеджера клиент получает аккаунтинговые данные для включения в свой VRF вида:
- IP-адрес VPN-HUB
- Логин
- Пароль аутентификации
- Настраивает СРЕ, ниже, для примера два варианта базовой конфигурации:
Вариант для Сisco:
crypto ikev2 keyring BeelineIPsec_keyring
peer Beeline_VPNHub
address 62.141.99.183 –VPN концентратор Билайн
pre-shared-key
!
Для варианта со статической маршрутизацией маршруты до сетей, доступных через Vpn-hub могут быть заданы в настройке IKEv2 и они автоматически появятся как статические маршруты в таблице маршрутизации СЕ. Данные настройки возможно произвести также и стандартным способом задания статических маршрутов (см.ниже).
crypto ikev2 authorization policy FlexClient-author
Маршрут до сетей за СЕ маршрутизатором – обязательная настройка при статической маршрутизации между СЕ и PE. Передача данных маршрутов на РЕ производится автоматически при поднятии тоннеля через IKEv2 взаимодействие.
route set remote ipv4 10.1.1.0 255.255.255.0 –Локальная сеть офиса
!
crypto ikev2 profile BeelineIPSec_profile
identity local < логин >
authentication local pre-share
authentication remote pre-share
keyring local BeelineIPsec_keyring
aaa authorization group psk list group-author-list FlexClient-author
!
crypto ikev2 client flexvpn BeelineIPsec_flex
peer 1 Beeline_VPNHub
client connect Tunnel1
!
crypto ipsec transform-set TRANSFORM1 esp-aes 256 esp-sha256-hmac
mode tunnel
!
crypto ipsec profile default
set transform-set TRANSFORM1
set ikev2-profile BeelineIPSec_profile
!
interface Tunnel1
ip address 10.20.1.2 255.255.255.252 –Адрес тоннеля
tunnel source GigabitEthernet0/2 –Интерфейс доступа в Интернет
tunnel mode ipsec ipv4
tunnel destination dynamic
tunnel protection ipsec profile default
!
Маршруты до частных сетей клиента, доступных через VPN концентратор Билайн, можно задать статически.
ip route 172.16.0.0 255.255.0.0 Tunnel1
ip route 192.168.0.0 255.255.255.0 Tunnel1
Вариант для Huawei (ar160/120) :
ike local-name < логин >
#
acl name ipsec 3999
rule 1 permit ip source 10.1.1.0 0.0.0.255 –Локальная сеть офиса
#
aaa
service-scheme IPSEC
route set acl 3999
#
ipsec proposal ipsec
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-256
#
ike proposal default
encryption-algorithm aes-256
dh group2
authentication-algorithm sha2-256
authentication-method pre-share
integrity-algorithm hmac-sha2-256
prf hmac-sha2-256
#
ike peer ipsec
pre-shared-key simple
local-id-type fqdn
remote-id-type ip
remote-address 62.141.99.183 –VPN концентратор Билайн
service-scheme IPSEC
config-exchange request
config-exchange set accept
config-exchange set send
#
ipsec profile ipsecprof
ike-peer ipsec
proposal ipsec
#
interface Tunnel0/0/0
ip address 10.20.1.2 255.255.255.252 –Адрес тоннеля
tunnel-protocol ipsec
source GigabitEthernet0/0/1 –Интерфейс доступа в Интернет
ipsec profile ipsecprof
#
Маршруты до частных сетей клиента, доступных через VPN концентратор Билайн, можно задать статически
ip route-static 192.168.0.0 255.255.255.0 Tunnel0/0/0
ip route-static 172.16.0.0 255.255.0.0 Tunnel0/0/0
Получающаяся схема связи выглядит примерно вот так:
Если каких-то примеров базовой конфигурации нет у клиента — то мы обычно помогаем с их формированием и делаем доступными для всех остальных.
Осталось подключить СРЕ в Интернет, сделать ping до ответной части VPN-туннеля и какого-либо хоста внутри VPN, и всё, можно считать, что подключение состоялось.
В следующей статье расскажем, как мы скомбинировали эту схему с IPSec и MultiSIM Резервированием с помощью CPE Huawei: ставим клиентам наше CPE Huawei, в котором может использоваться не только проводной интернет канал, но и 2 разных SIM-карты, и CPE автоматически перестраивает IPSec-туннель либо через проводной WAN, либо через радио (LTE#1/LTE#2), реализуя высокую отказоустойчивость итогового сервиса.
Отдельное спасибо за подготовку этой статьи (и, собственно, авторам этих техрешений) коллегам из нашего RnD!