Vpn gre: Сети для самых маленьких. Часть седьмая. VPN / Хабр

Содержание

GRE — пример настройки и описание

GRE (Generic Routing Encapsulation) – протокол инкапсуляции, который широко применяется как сам по себе, так и в совокупности с IPSec для создания туннелей. Перед прочтением данной статьи рекомендуется ознакомиться со статьёй «Принципы организации VPN».

В этой статье мы будем настраивать GRE туннель. Сам по себе GRE не обеспечивает никакой безопасности передаваемых данных – это site-to-site VPN туннель в чистом виде. Используется обычно такой туннель, когда есть специфичные задачи, связанные с маршрутизацией и нет требований к безопасности. Не стоит забывать, что чистый GRE туннель – не нагружает оборудование, а нагрузка при шифровании большого объёма данных весьма существенна.

Протокол GRE инкапсулируется напрямую в IP, минуя TCP или UDP, в IP пакете есть специальное поле «Protocol type», в котором содержится число, обозначающее протокол, инкапсулированный в данный IP пакет, для GRE protocol type равен 47. В связи с этим, если в сети есть GRE туннели, то стоит внимательно относиться к написанию расширенных списков контроля доступа (ACL), так как permit tcp any any и permit udp any any приведут к запрету на GRE из-за того, что он инкапсулируется напрямую в пакет, надо писать либо permit ip any any либо permit gre any any.

Схема инкапсуляции GRE выглядит следующим образом:

Как видно, IP инкапсулируется в GRE, который инкапсулируется в IP. При этом заголовок GRE и заголовок внешнего IP пакета добавляют 24 байта, соответственно, уменьшая размер пакета на эту величину. В данном примере мы настраиваем IPv4 в GRE в IPv4, тем не менее, GRE может успешно работать с другими инкапсулируемыми и транспортными протоколами, например, IPv6.

Рассмотрим работающую топологию. Есть две локальный сети: LAN1 за маршрутизатором R1 с адресацией 192.168.0.0/24 и LAN2 – за маршрутизатором R3, с адресацией 192.168.1.0/24. В каждой сети есть по одному компьютеру. Между маршрутизаторами есть сети 1.0.0.0/8 и 2.0.0.0/8, а также маршрутизатор R2 – это в нашем примере интернет. Маршрутизация для простоты настроена с помощью протокола RIP.

Выполним трассировку с компьютера PC1 до компьютера PC2:

Tracing route to 192.168.1.2 over a maximum of 30 hops: 
  1   0 ms      0 ms      0 ms      192.168.0.1
  2   0 ms      0 ms      0 ms      1.1.1.2
  3   0 ms      0 ms      0 ms      2.2.2.2
  4   1 ms      0 ms      0 ms      192.168.1.2

Как видно, пакет проходит через все маршрутизаторы последовательно, вплоть до компьютера адресата. Теперь создадим GRE туннель между R1 и R3 со внутренней адресацией 10.10.10.0/24.

R1(config)#interface tunnel 0
R1(config-if)#
%LINK-5-CHANGED: Interface Tunnel0, changed state to up
R1(config-if)#tunnel mode gre ip
R1(config-if)#ip address 10.10.10.1 255.255.255.0
R1(config-if)#tunnel source FastEthernet0/1
R1(config-if)#tunnel destination 2.2.2.2
R1(config-if)#
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R1(config-if)#exit

Мы создали интерфейс Tunnel0, в нём указали с помощью ip address внутреннюю адресацию туннеля – тот есть это адреса инкапсулированного IP, а с помощью команд tunnel source и tunnel destination мы указали параметры транспортного протокола IP (внешнего). У нас появилась новая сеть, которая виртуально соединяет напрямую два маршрутизатора R1 и R3 (без лишнего хопа на R2). Настроим вторую сторону туннеля – на R3. Для примера создадим интерфейс Tunnel99:

R3(config)#interface tunnel 99
R3(config-if)#
%LINK-5-CHANGED: Interface Tunnel99, changed state to up
R3(config-if)#tunnel mode gre ip
R3(config-if)#ip address 10.10.10.2 255.255.255.0
R3(config-if)#tunnel source FastEthernet0/0
R3(config-if)#tunnel destination 1.1.1.1
R3(config-if)#
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel99, changed state to up
R3(config-if)#exit

Теперь выполним трассировку с маршрутизатора R1 противоположного конца туннеля – на R3:

R1#traceroute 10.10.10.2
Type escape sequence to abort.
Tracing the route to 10.10.10.2
  1   10.10.10.2      1 msec    0 msec    0 msec

Как видно, трассировка проходит внутри туннеля и мы не видим лишнего хопа в виде R2. Посмотрим таблицу маршрутизации на R1:

R1#show ip route 
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route
Gateway of last resort is not set
C    1.0.0.0/8 is directly connected, FastEthernet0/1
R    2.0.0.0/8 [120/1] via 1.1.1.2, 00:00:12, FastEthernet0/1
     10.0.0.0/24 is subnetted, 1 subnets
C       10.10.10.0 is directly connected, Tunnel0
C    192.168.0.0/24 is directly connected, FastEthernet0/0
R    192.168.1.0/24 [120/2] via 1.1.1.2, 00:00:12, FastEthernet0/1

Видно, что новая сеть отображается, как непосредственно подключенная к интерфейсу Tunnel 0. Если сейчас попробовать сделать трассировку с компьютера 1 до компьютера 2, то она не пойдёт по туннелю. Это связано с тем, что на маршрутизаторе R1 нет соответствующего маршрута. Просматривая свою таблицу маршрутизации, R1 отправит пакеты на PC2 по маршруту «R 192.168.1.0/24 [120/2] via 1.1.1.2, 00:00:12, FastEthernet0/1», то есть как и раньше – в обход туннеля. Чтобы исправить ситуацию пропишем с двух сторон на R1 и R3 статические маршруты, в которых явно укажем, что в сети 192.168.0.0 и 192.168.1.0 надо доставлять трафик через туннель. На R1:

R1(config)#ip route 192.168.1.0 255.255.255.0 10.10.10.2

На R3:

R3(config)#ip route 192.168.0.0 255.255.255.0 10.10.10.1
R3#show ip route 
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route
Gateway of last resort is not set
R    1.0.0.0/8 [120/1] via 2.2.2.1, 00:00:05, FastEthernet0/0
C    2.0.0.0/8 is directly connected, FastEthernet0/0
     10.0.0.0/24 is subnetted, 1 subnets
C       10.10.10.0 is directly connected, Tunnel99
S    192.168.0.0/24 [1/0] via 10.10.10.1
C    192.168.1.0/24 is directly connected, FastEthernet0/1

Теперь, как видно из таблицы маршрутизации, трафик пойдёт через GRE туннель. Проверим это, выполнив трассировку с PC1 до PC2, как и в начале этой статьи:

tracert 192.168.1.2
Tracing route to 192.168.1.2 over a maximum of 30 hops: 
  1   0 ms      0 ms      0 ms      192.168.0.1
  2   0 ms      0 ms      0 ms      10.10.10.2
  3   1 ms      0 ms      1 ms      192.168.1.2
Trace complete.

Как видно, из результатов трассировки, теперь на пути всего два хопа: 192.168.0.1 – R1, шлюз PC1, который заворачивает трафик в туннель. Далее, транспортный (внешний) IP пакет с GRE внутри проходит на R2, затем на R3 и только тут из пакета декапсулируется внутренний IP – это и есть наш второй хоп – 10.10.10.2, затем пакет по локальной сети идёт адресату – на 192.168.1.2, если добавить в интернете ещё несколько маршрутизаторов, то трассировка не изменится, в ней по-прежнему будет два хопа до адресата. Пример конфигурации доступен в формате pkt.

Настройка VPN сервера (GRE/IPSec StrongSwan, OSPF Quagga) / Хабр

Кто бы мог подумать, что развернуть часть серверов компании в Amazon было плохой идеей.

В итоге поставленная задача — сделать дополнительный VPN-туннель между Amazon и инфраструктурой в РФ.

Кроме простого how-to опишу несколько особенностей в настройке, с которыми можно столкнуться.

Настройка файрвола и роутинга

Покупаем у пока еще не заблокированного хостера VPS за сумму, эквивалентную 10 000 монгольских тугриков в месяц, ставим CentOS 7, включаем пересылку пакетов
```
echo net.ipv4.ip_forward=1 >>/etc/sysctl.d/ipv4.forward.enable.conf
sysctl -a
```
Добавляем в файрволе правила для приема пакетов IPsec
```
firewall-cmd --zone=dmz --permanent --add-rich-rule='rule protocol value="esp" accept'
firewall-cmd --zone=dmz --permanent --add-port=500/udp
firewall-cmd --zone=dmz --permanent --add-port=4500/udp
firewall-cmd --permanent --add-service="ipsec"
firewall-cmd --reload
firewall-cmd --list-all
```

Настройка StrongSwan

Устанавливаем демон IPsec StrongSwan:

yum install -y epel-release
yum install -y strongswan

Делаем предварительные настройки в /etc/strongswan.d/charon.conf:

charon {
    # Понадобится при использовании с Cisco IKEv2
    make_before_break = yes
    # Необходимо для работы с туннелями
    install_routes = no
}

Настройка Strongswan может быть проведена двумя способами.

Старый способ, использующий демон strongswan, уже достаточно хорошо описан:

Файл конфигурации
/etc/strongswan/ipsec.conf
Файл с паролями и сертификатами:
/etc/ipsec.secrets
Остановка службы:
```
systemctl stop strongswan
```

Новый способ, использующий демон charon, появившийся в версии 5.2.0:

Вся конфигурация хранится в /etc/strongswan/swanctl/swanctl.conf

Рассмотрим два варианта настройки демона charon:

Одинаковые настройки аутентификации и шифрования для всех. Сделаем разными только PSK:

connections {
 ToWorld {
  local_addrs = 10.3.3.1
  version = 1
  proposals = aes256-sha1-modp1536
  reauth_time = 1440m
  local {
   auth = psk
  }
  remote {
   auth = psk
  }
  children {
   ToWorld-1 {
    local_ts = dynamic[gre]
    remote_ts = dynamic[gre]
    mode = transport
    esp_proposals = aes128-sha1-modp1536
    rekey_time = 60m
    start_action = trap
    dpd_action = restart
   }
  }
 }
}
secrets {
 ike-To-2951
 {
  id = 1.1.1.1
  secret = "etokto2ttakoimohnatenkyi"
 }
 ike-To-CSR1000V
 {
  id = 2.2.2.2
  secret = "zdorovkakzhiznkasamзpro100klass"
 }
}

Индивидуальные настройки аутентификации и шифрования:

connections {
 To2951 {
  encap = no
  remote_addrs = 1.1.1.1
  version = 1
  proposals = aes256-sha1-modp1536
  reauth_time = 1440m
  fragmentation = yes
  local-1 {
   auth = psk
   id = 10.3.3.1
  }
  remote-1 {
   auth = psk
  }
  children {
   To2951-1 {
    local_ts = 10.3.3.1/32[gre]
    remote_ts = 1.1.1.1/32[gre]
    mode = transport
    esp_proposals = aes128-sha1-modp1536
    rekey_time = 60m
    start_action = start
    dpd_action = restart
   }
  }
 }
 ToCSR1000V {
  encap = no
  remote_addrs = 2.2.2.2
  version = 1
  proposals = aes256-sha1-modp1536
  reauth_time = 1440m
  fragmentation = yes
  local-1 {
   auth = psk
   id = 10.3.3.1
  }
  remote-1 {
   auth = psk
  }
  children {
   ToCSR1000V-1 {
    local_ts = 10.3.3.1/32[gre]
    remote_ts = 2.2.2.2/32[gre]
    mode = transport
    esp_proposals = aes128-sha1-modp1536
    rekey_time = 60m
    start_action = start
    dpd_action = restart
   }
  }
 }
}
secrets {
 ike-To-2951 
 {
  id-1 = 1.1.1.1
  secret = "etokto2ttakoimohnatenkyi"
 }
 ike-To-CSR1000V
 {
  id-1 = 2.2.2.2
  secret = "zdorovkakzhiznkasamзpro100klass"
 }
}

Включаем службу

sudo systemctl enable strongswan-swanctl
sudo systemctl start strongswan-swanctl

Поднятие туннелей с маршрутизаторами Cisco

Настраиваем GRE-туннели в CentOS

Создаем /etc/sysconfig/network-scripts/ifcfg-Tunnel13
```
NAME=Tunnel13
DEVICE=Tunnel13
ONBOOT=yes
STARTMODE=onboot
BOOTPROTO=none
TYPE=GRE
PEER_OUTER_IPADDR=1.1.1.1
PEER_INNER_IPADDR=172.16.130.2/30
MY_INNER_IPADDR=172.16.130.1/30
MY_OUTER_IPADDR=10.3.3.1
ZONE=trusted
TTL=30
MTU=1400
```
Создаем /etc/sysconfig/network-scripts/ifcfg-Tunnel23
```
NAME=Tunnel23
DEVICE=Tunnel23
ONBOOT=yes
STARTMODE=onboot
BOOTPROTO=none
TYPE=GRE
PEER_OUTER_IPADDR=2.2.2.2
PEER_INNER_IPADDR=172.16.230.2/30
MY_INNER_IPADDR=172.16.230.1/30
MY_OUTER_IPADDR=10.3.3.1
ZONE=trusted
TTL=30
MTU=1400
```
В настройке GRE-интерфейсов есть пара особенностей.
Первая — необходимо уменьшить MTU для корректного прохождения пакетов.
Второе — указать TTL, это понадобится в будущем, когда будем настраивать OSPF. Если этого не сделать, пакеты OSPF будут приходить на удаленный хост с TTL, равным единице (из-за GRE over IPsec), оставаясь без ответа. Соответственно устройства будут висеть в состоянии INIT/DROTHER, связности мы не дождемся. При этом корректные ответы ICMP могут сбить с толку.
Поднимаем интерфейсы
```
ifup Tunnel13
ifup Tunnel23
```

Создаем туннель на Cisco 2951

crypto keyring StrongSwanKeyring
  pre-shared-key address 3.3.3.1 key etokto2ttakoimohnatenkyi

crypto isakmp policy 60
 encr aes 256
 authentication pre-share
 group 5

crypto isakmp identity address

crypto isakmp profile StrongSwanIsakmpProfile
   keyring StrongSwanKeyring
   match identity address 3.3.3.1
 
crypto ipsec transform-set StrongSwanTransformSet esp-aes esp-sha-hmac
 mode transport

crypto ipsec profile StrongSwanIpsecProfile
 set transform-set StrongSwanTransformSet
 set pfs group5
 set isakmp-profile StrongSwanIsakmpProfile

interface Tunnel13
 ip address 172.16.130.2 255.255.255.252
 tunnel source GigabitEthernet2
 tunnel destination 3.3.3.1
 tunnel protection ipsec profile StrongSwanIpsecProfile

Создаем туннель на Cisco CSR1000V

crypto keyring StrongSwanKeyring
  pre-shared-key address 3.3.3.1 key etokto2ttakoimohnatenkyi

crypto isakmp policy 60
 encr aes 256
 authentication pre-share
 group 5

crypto isakmp identity address

crypto isakmp profile StrongSwanIsakmpProfile
   keyring StrongSwanKeyring
   match identity address 3.3.3.1
 
crypto ipsec transform-set StrongSwanTransformSet esp-aes esp-sha-hmac
 mode transport

crypto ipsec profile StrongSwanIpsecProfile
 set transform-set StrongSwanTransformSet
 set pfs group5
 set isakmp-profile StrongSwanIsakmpProfile

interface Tunnel23
 ip address 172.16.230.2 255.255.255.252
 tunnel source GigabitEthernet2
 tunnel destination 3.3.3.1
 tunnel protection ipsec profile StrongSwanIpsecProfile

Проверяем, что туннели поднялись, шифрование работает.

На CentOS

strongswan statusall

На Cisco

show crypto session detail

Настройка динамической маршрутизации на Quagga

Если вы используете динамическую маршрутизацию на основе OSPF, то следующим шагом логично было бы поднять демон OSPF на CentOS, настроив новые туннели в качестве резервного маршрута.
- Настройка OSPF на CentOS
  
  В качестве демона установим Quagga:
```
yum install -y quagga
```
  Создаем конфигурационный файл демона /etc/quagga/zebra.conf
```
hostname StrongSwanServer
log file /var/log/quagga/quagga.log
!
interface Tunnel13
 ip address 172.16.130.1/30
!
interface Tunnel23
 ip address 172.16.230.1/30
!
```
  Вес пути можно регулировать параметрами cost либо bandwidth, устанавливая их на нужных интерфейсах.
  Устанавливаем права и включаем службу
```
chown quagga:quaggavt /etc/quagga/zebra.conf
systemctl enable zebra.service 
systemctl start zebra.service
```
  Создаем конфигурационный файл демона /etc/quagga/ospfd.conf
```
log file /var/log/quagga/ospfd.log
!
router ospf
 ospf router-id 10.3.3.1
 passive-interface default
 no passive-interface Tunnel13
 no passive-interface Tunnel23
 network 172.16.130.0/30 area 0.0.0.0
 network 172.16.230.0/30 area 0.0.0.0
```
  Устанавливаем права и включаем службу
```
chown quagga:quaggavt /etc/quagga/ospfd.conf
systemctl enable ospfd.service 
systemctl start ospfd.service
```
  Далее можем запустить терминал vtysh и работать с Quagga в циско-подобном интерфейсе, например:
```
vtysh
show running-config
```
- Настройка OSPF на Cisco 2951
```
router ospf 1
 passive-interface default
 no passive-interface Tunnel12
 no passive-interface Tunnel13
 no passive-interface GigabitEthernet1
 network 192.168.1.0 0.0.0.255 area 0
 network 172.16.120.0 0.0.0.3 area 0
 network 172.16.130.0 0.0.0.3 area 0
```
- Настройка OSPF на Cisco CSR1000V
```
 router ospf 1
 passive-interface default
 no passive-interface Tunnel12
 no passive-interface Tunnel23
 no passive-interface GigabitEthernet1
 network 192.168.2.0 0.0.0.255 area 0
 network 172.16.120.0 0.0.0.3 area 0
 network 172.16.230.0 0.0.0.3 area 0
```
Проверяем видимость соседей и пришедшие маршруты на CentOS:
```
vtysh
show ospf neighbor
show ip ospf route
```
и на Cisco:
```
show ospf neighbor
show ip ospf route
```

Что осталось нерассмотренным

Я описал самый простой вариант. Конечно же, вы настроите обмен ключами, используя IKE v2, авторизацию по сертификату, добавите в файрвол дополнительную фильтрацию по адресам, сделаете OSPF с авторизацией и, при большом количестве маршрутизаторов, с разделением на area, измените значения hello-interval и dead-interval на интерфейсах.
Буду рад советам в комментариях, а информации об опечатках — в личку. Спасибо за внимание.

(MikroTikUbuntu) * GRE / IPsec / Хабр

Позволю себе опубликовать свой опыт применения сетевых технологий в меру моей испорченности для выхода в интернет из-за пределов РФ. Не будем рассуждать о том, зачем это нужно. Надеюсь, что все всем и так понятно.

Итак, у нас есть статический публичный IP адрес, который приходит Ethernet шнуром в MikroTik RouterBOARD 750G r3 (hEX). Пробуем собрать вот такую конструкцию.

Настройку L2tp линка в рамках этой статьи я не описываю, а на схеме он нарисован только потому, что в ней упоминается.

Как вы уже догадались, нужна система, которая включена в интернет за пределами РФ. Большие деньги на это тратить не хотелось, и я остановился на Aruba Cloud. Здесь всего за 1 евро в месяц дается VM в локациях Италия, Чехия, Германия, Франция и Великобритания. Я свой выбор остановил на Чехии, потому что ping до наших ресурсов оказался на 20ms меньше, чем с Итальянского (50ms против 70ms). Ubuntu 16.04 LTS поднялась очень быстро. Войти в нее удалось раньше, чем «позеленел» статус в интерфейсе «облака».

Сервер устанавливается в минимальной конфигурации. Не помешает установить утилитку traceroute.

$ sudo apt install traceroute

Выбор в пользу GRE был сделан по нескольким причинам:

просто и понятно настраивается;

легко траблешутится;

маршрутизация проще некуда;

элементарно отрисовывается график загрузки интерфейса в MikroTik.

Итак, на стороне Ubuntu описываем интерфейс tun1 в /etc/network/interfaces

$ sudo cat << EOF >> /etc/network/interfaces
 iface tun1 inet static
    address 192.168.10.1
    netmask 255.255.255.0
    pre-up iptunnel add tun1 mode gre local 80.211.x.x remote 188.x.x.x ttl 255
    up ifconfig tun1 multicast
    pointopoint 192.168.10.2
    post-down iptunnel del tun1
EOF

Здесь все просто:

80.211.x.x — адрес VM с Ubuntu в Чехии;

188.x.x.x — внешний адрес MikroTik;

192.168.10.1 — адрес на туннельном интерфейсе tun1 на стороне Ubuntu;

192.168.10.2 — адрес туннельного интерфейса на MikroTik;

Активацию этой части конфигурации я по-старинке делаю так:

$ sudo service networking restart

Получил конструктивную критику такого метода активации настроек сети.

У нас получился вот такой интерфейс:

$ ifconfig tun1
tun1      Link encap:UNSPEC  HWaddr 10-D3-29-B2-00-00-B0-8A-00-00-00-00-00-00-00-00
          inet addr:192.168.10.1  P-t-P:192.168.10.2  Mask:255.255.255.255
          inet6 addr: fe80::200:5ffa:50d3:c9c2/64 Scope:Link
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1476  Metric:1
          RX packets:379 errors:0 dropped:0 overruns:0 frame:0
          TX packets:322 errors:4 dropped:7 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:103387 (103.3 KB)  TX bytes:159422 (159.4 KB)

Со стороны MikroTik настройка тоже несложная. Я делал это из Web-интерфейса.

Обращаю внимание на то, что не сконфигурирован keepalive. Мне так и не удалось включить ответную часть на Ubuntu. Если не будет трафика, то интерфейс на MikroTik будет «уходить» из running и подниматься, только если пойдет трафик со стороны Ubuntu.

Устанавливаем IP адрес на туннельный интерфейс на стороне MikroTik 192.168.10.2

На этом этапе у нас должны подняться туннельные интерфейсы с двух сторон. Проверить это просто. Достаточно запустить ping c Ubuntu в сторону MikroTik.

$ ping 192.168.10.2
PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data.
64 bytes from 192.168.10.2: icmp_seq=1 ttl=64 time=56.0 ms
64 bytes from 192.168.10.2: icmp_seq=2 ttl=64 time=59.9 ms
64 bytes from 192.168.10.2: icmp_seq=3 ttl=64 time=56.3 ms
64 bytes from 192.168.10.2: icmp_seq=4 ttl=64 time=56.1 ms
--- 192.168.10.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 56.091/57.137/59.936/1.618 ms
user@vps:~$

Настраиваем маршрутизацию в сторону абонентских сетей в туннельный интрефейс

Приватные IP адреса локальной сети, из которой осуществляется выход в интернет — 192.168.1.0/24. Сеть 192.168.6.0/24 — это сеть, выделенная для подключения к MikroTik по L2TP из «внешнего мира». Для того, чтобы работали компьютеры локальной сети и удаленные устройства, добавляем маршруты на обе сети в конец файла /etc/network/interfaces

$ sudo cat << EOF >> /etc/network/interfaces
#static route"
up ip ro add 192.168.1.0/24 via 192.168.10.2
up ip ro add 192.168.6.0/24 via 192.168.10.2
EOF

Еще раз просим систему обновить сетевые настройки

$ sudo service networking restart

Включаем ip_forward

$ sudo echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
$ sudo sysctl -p

Прописываем SNAT.
Для статического внешнего IP он должен работать быстрее чем MASQUERADE за счет того, что не нужно каждый раз выяснять IP адрес интерфейса.

$ sudo iptables -t nat -A POSTROUTING -j SNAT --to-source 80.211.x.x -o eth0

Настаиваем маршрутизацию на MikroTik

Поскольку у меня не стоит задача «развернуть» весь трафик в интернет через другую страну, то в туннельный интерфейс я буду маршрутизировать только интересующие меня ресурсы. В качестве такого ресурса я выбрал Linkedin.

Итак, добавляем маршруты на MikroTik (через терминалку):

/ip route
add comment=linkedin distance=1 dst-address=91.225.248.0/22 gateway=gre-tunnel1
add comment=linkedin distance=1 dst-address=108.174.0.0/20 gateway=gre-tunnel1
add comment=linkedin distance=1 dst-address=185.63.144.0/22 gateway=gre-tunnel1

К этому моменту у меня начал открываться заветный ресурс и на этом можно было бы и закончить, поскольку, даже несмотря на то что GRE трафик не шифрован и его прекрасно видно в Wireshark, далеко не все провайдеры DPI-ят трафик (а если и DPI-ят, то точно не заглядывают внутрь туннелей для отслеживания трафика от запрещенных ресурсов), да и АПК «Ревизор» не интересуется тем, какой реально абонентами потребляется трафик.

На дальнейшие эксперименты меня натолкнул тот факт, что в настройках GRE интерфейса MikroTik есть опция IPsec Secret. Неужели действительно все так просто?!

В качестве шифровальщика на стороне Ubuntu я выбрал strongSwan. Пример конфигурации я взял из материала Configure GRE over IPSec secured private channel, но сразу не заработало и пришлось внести некоторые правки.

Устанаваливаем

$ apt install strongswan

Вносим в основной конфигурационный файл strongSwan вот это:

$ cat << EOF > /etc/ipsec.conf 
# ipsec.conf - strongSwan IPsec configuration file

config setup
    charondebug="ike 2, knl 2, cfg 2, net 2, esp 2, dmn 2,  mgr 2"

conn %default
#    keyexchange=ikev2

conn mikrotik
    # Try connect on daemon start
    auto=start

    # Authentication by PSK (see ipsec.secret)
    authby=secret

    # Disable compression
    compress=no

    # Re-dial setings
    closeaction=clear
    dpddelay=30s
    dpdtimeout=150s
    dpdaction=restart

    # ESP Authentication settings (Phase 2)
    esp=aes128-sha1-modp2048,aes256-sha1-modp2048

    # UDP redirects
    forceencaps=no

    # IKE Authentication and keyring settings (Phase 1)
    ike=aes128-sha1-modp2048,aes256-sha1-modp2048
    ikelifetime=86400s
    keyingtries=%forever
    lifetime=3600s

    # Internet Key Exchange (IKE) version
    # Default: Charon - ikev2, Pluto: ikev1
    keyexchange=ikev1

    # connection type
    type=transport

    # Peers
    left=188.x.x.x
    right=80.211.x.x

    # Protocol type. May not work in numeric then need set 'gre'
    leftprotoport=47
    rightprotoport=47
EOF

Прописываем pre-shared-key (PSK) в /etc/ipsec.secrets

$ echo "80.211.x.x 188.x.x.x : PSK VeryBigSecret" >> /etc/ipsec.secrets

Перезапускаем strongSwan

$ ipsec restart

На этом настройка Ubuntu практически завершена. Приступаем к настройке MikroTik.

Я выставил вот такие настройки дефалтового proposal

Настало время вписать в поле IPsec Secret тот же PSK, что был указан в /etc/ipsec.secrets на сервере (VeryBigSecret).

Если все получилось, то выполняем диагностику на обоих концах туннеля.

MikroTik

Если «провалиться» глубже, то должно быть вот так:

Ubuntu

$ ipsec status
Security Associations (1 up, 0 connecting):
        mikrotik[2]: ESTABLISHED 60 minutes ago, 80.211.x.x[80.211.x.x]...188.x.x.x[188.x.x.x]
        mikrotik{2}:  INSTALLED, TRANSPORT, reqid 1, ESP SPIs: cc075de3_i 07620dfa_o
        mikrotik{2}:   80.211.x.x/32[gre] === 188.x.x.x/32[gre]

Теперь GRE (protocol 47) между MikroTik и Ubuntu шифруется IPseс (ESP). Анализ pcap файла, снятого tcpdump-ом, это подтвердил.

Вроде бы, все работает и заветный ресурс открывается. Однако после того, как я направил в туннель еще несколько ресурсов, оказалось, что не все так хорошо, как казалось изначально. Удалось выяснить, что перестали проходить пакеты большого размера (вернее, они перестали правильно фрагментироваться).

Решение нашлось быстро. Оказалось, что достаточно уменьшить MTU до 1435 на обоих концах туннеля.

MikroTik

Ubuntu — добавляем mtu 1435 в описание интерфейса.

auto tun1
iface tun1 inet static
    address 192.168.10.1
    netmask 255.255.255.0
    pre-up iptunnel add tun1 mode gre local 80.211.x.x remote 188.x.x.x ttl 255
    up ifconfig tun1 multicast
    pointopoint 192.168.10.2
    mtu 1435
    post-down iptunnel del tun1

Диагностика установления IPsec соединения не тривиальна. На Ubuntu логи читаются значительно проще, чем на MikroTik. По умолчанию на MikroTik выключено логирование IPsec. Включается просто, но проводить анализ проще через терминалку.

Мне удалось добиться скорости скачивания 25 Мбит/с и отдачи 50 Мбит/с. На мой взгляд, этого вполне хватает для комфортной работы с ресурсом. Почему не разгоняется больше — это пока загадка. Загрузка процессоров на обоих концах туннеля не высока. Основная версия — это ограничение скорости на стороне облака. Как-нибудь на досуге погоняю файлы между серверами без шифрования.

UPD 1: настройки iptables

Устанавливаем пакет netfilter-persistent

$ sudo apt install netfilter-persistent

Я писал правила командами, а потом записал их в /etc/iptables/rules.v4 командой iptables-save > /etc/iptables/rules.v4

В итоге, у меня получился вот такой набор:

$ cat /etc/iptables/rules.v4
# Generated by iptables-save v1.6.0 on Thu Sep 14 20:36:19 2017
*nat
:PREROUTING ACCEPT [17:3042]
:INPUT ACCEPT [2:92]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o eth0 -j SNAT --to-source 80.211.x.x
COMMIT
# Completed on Thu Sep 14 20:36:19 2017
# Generated by iptables-save v1.6.0 on Thu Sep 14 20:36:19 2017
*filter
:INPUT DROP [29:4527]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT
# TCP/4022 - это нестандартный порт для ssh (я всегда меняю порт, чтобы было меньше port-scan-а)
# !!! если ssh на стандартном порту, замена может нарушить вход на сервер
-A INPUT -p tcp -m tcp --dport 4022 -j ACCEPT
-A INPUT -p udp -m udp --dport 500 -j ACCEPT
-A INPUT -p gre -j ACCEPT
-A INPUT -p esp -j ACCEPT
# Forwarding
-A FORWARD -j ACCEPT
COMMIT
# Completed on Thu Sep 14 20:36:19 2017

В /etc/rc.local я добавил активацию правил при старте машины (другим способом мне это сделать пока не удалось).

$ echo "iptables-restore < /etc/iptables/rules.v4" >> /etc/rc.local

После перезагрузки сервера проверяем, что все правила на месте.

$ iptables -L -n -v
Chain INPUT (policy DROP 185 packets, 28847 bytes)
 pkts bytes target     prot opt in     out     source               destination
    4   344 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
   32   896 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0
  948 66063 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:3022
  172 21504 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:500
 2864  454K ACCEPT     47   --  *      *       0.0.0.0/0            0.0.0.0/0
 2864  582K ACCEPT     esp  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 4572 3303K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT 1820 packets, 2974K bytes)
 pkts bytes target     prot opt in     out     source               destination
 4797 6544K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED

UPD 2: рекомендую отключить MikroTik Neighbor discovery на интерфейсе gre-tunnel1.

Если этого не сделать, то при вышеописанных настройках iptables будут отбрасываться пакеты на UDP/5678.

Sep 15 19:25:33 vps kernel: [42049.805599] IN=tun1 OUT= MAC= SRC=192.168.10.2 DST=255.255.255.255 LEN=133 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=36233 DPT=5678 LEN=113

P.S.: В планах настроить IKEv2 туннель с моих устройств (я использую технику Apple) непосредственно на сервер с использованием сертификатов. Пока мне не удалось это сделать. Apple-девайсы почему-то не отвечают на запросы установления защищенного соединения со стороны сервера. Можно, конечно, сделать L2tp, но это уже не интересно: такой опыт у меня уже был.

Туннелирование GRE в Windows Server 2016

07.08.2020

Чтение занимает 4 мин

В этой статье

Область применения. Windows Server (Semi-Annual Channel), Windows Server 2016Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016

Windows Server 2016 предоставляет обновления для шлюза RAS с универсальной маршрутизацией ( GRE ) .Windows Server 2016 provides updates to Generic Routing Encapsulation (GRE) tunnel capability for the RAS Gateway.

GRE — это упрощенный протокол туннелирования, который может инкапсулировать разнообразные протоколы сетевого уровня внутри виртуальных каналов «точка-точка» в IP-сети.GRE is a lightweight tunneling protocol that can encapsulate a wide variety of network layer protocols inside virtual point-to-point links over an Internet Protocol internetwork. Реализация Microsoft GRE может инкапсулировать IPv4 и IPv6.The Microsoft GRE implementation can encapsulate IPv4 and IPv6.

Туннели GRE полезны во многих сценариях, поскольку:GRE tunnels are useful in many scenarios because:

Они являются упрощенными и совместимыми с RFC 2890, что делает их совместимыми с различными устройствами поставщика.They are lightweight and RFC 2890 compliant, making it interoperable with various vendor devices
(Для динамической маршрутизации можно использовать протокол BGP BGP. )You can use Border Gateway Protocol (BGP) for dynamic routing
Вы можете настроить многоклиентские шлюзы GRE для использования с программно определяемой сетью ( Sdn.)You can configure GRE multitenant RAS Gateways for use with Software Defined Networking (SDN)
System Center Virtual Machine Manager можно использовать для управления — шлюзами RAS на основе GREYou can use System Center Virtual Machine Manager to manage GRE-based RAS Gateways
Можно достичь до 2,0 Гбит/с на виртуальной машине с 6 ядрами, настроенной в качестве шлюза RAS GRE.You can achieve up to 2.0 Gbps throughput on a 6 core virtual machine that is configured as a GRE RAS Gateway
Один шлюз поддерживает несколько режимов подключения.A single gateway supports multiple connection modes

Туннели на основе GRE обеспечивают подключение между виртуальными сетями клиентов и внешними сетями.GRE based tunnels enable connectivity between tenant virtual networks and external networks. Поскольку протокол GRE является легковесным и поддержка GRE доступна на большинстве сетевых устройств, она становится идеальным выбором для туннелирования, где шифрование данных не требуется.Since the GRE protocol is lightweight and support for GRE is available on most of network devices it becomes an ideal choice for tunneling where the encryption of data is not required.

Поддержка GRE в туннельах типа «сеть — сеть» (S2S) решает проблему переадресации между виртуальными сетями клиента и внешними сетями клиента с помощью шлюза с несколькими клиентами, как описано далее в этом разделе.GRE support in Site to Site (S2S) tunnels solves the problem of forwarding between tenant virtual networks and tenant external networks using a multi-tenant gateway, as described later in this topic.

Функция туннелирования GRE предназначена для решения следующих требований:The GRE tunnel feature is designed to address the following requirements:

Поставщик услуг размещения должен иметь возможность создавать виртуальные сети для перенаправления без изменения конфигурации физического коммутатора.A hosting provider must be able to create virtual networks for forwarding without modifying the physical switch configuration.
Поставщик услуг размещения должен иметь возможность добавлять подсети к внешним сетям, не изменяя конфигурацию физических коммутаторов в своей инфраструктуре.A hosting provider must be able to add subnets to their externally facing networks without modifying the configuration of the physical switches within their infrastructure.
Функция туннелирования GRE включает или расширяет несколько ключевых сценариев для поставщиков услуг размещения, использующих технологии Майкрософт для реализации программно определяемых сетей в своих предложениях услуг.The GRE tunnel feature enables or enhances several key scenarios for hosting service providers using Microsoft technologies to implement Software Defined Networking in their service offerings.

Ниже приведены некоторые примеры сценариев.The following are some example scenarios:

Ключевые сценарииKey scenarios

Ниже приведены основные сценарии, в которых используется функция туннелирования GRE.The following are key scenarios that the GRE tunnel feature addresses.

Доступ из виртуальных сетей клиента к физическим сетям клиентаAccess from tenant virtual networks to tenant physical networks

Этот сценарий обеспечивает масштабируемый способ предоставления доступа из виртуальных сетей клиента физическим сетям клиента, расположенным в локальной организации поставщика услуг размещения.This scenario enables a scalable way to provide access from tenant virtual networks to tenant physical networks located on the hosting service provider premises. Конечная точка туннеля GRE установлена в многоклиентский шлюз, другая конечная точка туннеля GRE устанавливается на устройстве стороннего производителя в физической сети.A GRE tunnel endpoint is established on the multitenant gateway, the other GRE tunnel endpoint is established on a third-party device on the physical network. Трафик уровня 3 направляется между виртуальными машинами в виртуальной сети и устройством стороннего производителя в физической сети.Layer-3 traffic is routed between the virtual machines in the virtual network and the third-party device on the physical network.

Высокая скорость подключенияHigh speed connectivity

Этот сценарий позволяет масштабировать способ обеспечения высокоскоростного подключения из локальной сети клиента к их виртуальной сети, расположенной в сети поставщика услуг размещения.This scenario enables a scalable way to provide high speed connectivity from the tenant on-premises network to their virtual network located in the hosting service provider network. Клиент подключается к сети поставщика услуг с помощью многопротокольного переключения меток (MPLS), где между граничным маршрутизатором поставщика услуг размещения и многоклиентским шлюзом устанавливается туннель GRE для виртуальной сети клиента.A tenant connects to the service provider network via multiprotocol label switching (MPLS), where a GRE tunnel is established between the hosting service provider’s edge router and the multitenant gateway to the tenant’s virtual network.

Интеграция с изоляцией на основе VLANIntegration with VLAN based isolation

Этот сценарий позволяет интегрировать изоляцию на основе виртуальной ЛС с виртуализацией сети Hyper-V.This scenario allows you to integrate VLAN based isolation with Hyper-V Network Virtualization. Физическая сеть в сети поставщика услуг размещения содержит балансировщик нагрузки, использующий изоляцию на основе виртуальной ЛС.A physical network on the hosting provider network contains a load balancer using VLAN-based isolation. Многоклиентский шлюз устанавливает туннели GRE между подсистемой балансировки нагрузки в физической сети и многоклиентским шлюзом в виртуальной сети.A multitenant gateway establishes GRE tunnels between the load balancer on the physical network and the multitenant gateway on the virtual network.

Между источником и назначением можно установить несколько туннелей, а ключ GRE используется для различения туннелей.Multiple tunnels can be established between the source and destination, and the GRE key is used to discriminate between the tunnels.

Доступ к общим ресурсамAccess shared resources

Этот сценарий позволяет получить доступ к общим ресурсам в физической сети, расположенной в сети поставщика услуг размещения.This scenario allows you to access shared resources on a physical network located on the hosting provider network.

У вас может быть общая служба, расположенная на сервере в физической сети, расположенной в сети поставщика услуг размещения, к которой вы хотите предоставить общий доступ с несколькими виртуальными сетями клиента.You may have a shared service located on a server on a physical network located in the hosting provider network that you want to share with multiple tenant virtual networks.

Клиентские сети с непересекающимися подсетями получают доступ к общей сети через туннель GRE.The tenant networks with non-overlapping subnets access the common network over a GRE tunnel. Один маршрут шлюза клиента между туннелями GRE, что приводит к маршрутизации пакетов в соответствующие клиентские сети.A single tenant gateway routes between the GRE tunnels, thus routing packets to the appropriate tenant networks.

В этом сценарии один шлюз клиента можно заменить аппаратными устройствами сторонних производителей.In this scenario, the single tenant gateway can be replaced by third-party hardware appliances.

Службы сторонних устройств для клиентовServices of third party devices to tenants

Этот сценарий можно использовать для интеграции сторонних устройств (таких как аппаратные подсистемы балансировки нагрузки) в поток трафика виртуальной сети клиента.This scenario can be used to integrate third party devices (such as hardware load balancers) into the tenant virtual network traffic flow. Например, трафик, исходящий от корпоративного сайта, проходит через туннель S2S с многоклиентским шлюзом.For example, traffic originating from an enterprise site passes through a S2S tunnel to the multitenant gateway. Трафик направляется в подсистему балансировки нагрузки через туннель GRE.The traffic is routed to the load balancer over a GRE tunnel. Балансировщик нагрузки направляет трафик на несколько виртуальных машин в виртуальной сети предприятия.The load balancer routes traffic to multiple virtual machines on the enterprise’s virtual network. То же самое происходит для другого клиента с потенциально перекрывающимися IP-адресами в виртуальных сетях.The same thing happens for another tenant with potentially overlapping IP addresses in the virtual networks. Сетевой трафик изолируется подсистемой балансировки нагрузки с помощью виртуальных ЛС и применяется ко всем устройствам уровня 3, поддерживающим виртуальные ЛС.The network traffic is isolated on the load balancer using VLANs, and is applicable to all layer 3 devices that support VLANs.

Конфигурация и развертываниеConfiguration and deployment

Туннель GRE предоставляется в качестве дополнительного протокола в интерфейсе S2S.A GRE tunnel is exposed as an additional protocol within a S2S interface. Он реализуется аналогично туннелю IPSec S2S, описанному в следующем блоге по сети: VPN-шлюз типа «сеть-сеть» с несколькими клиентами (S2S) с Windows Server 2012 R2It is implemented in a similar fashion as an IPSec S2S tunnel described in the following Networking Blog: Multi-tenant Site-to-Site (S2S) VPN Gateway with Windows Server 2012 R2

Пример развертывания шлюзов, включая туннельные шлюзы GRE, см. в следующем разделе:See the following topic for an example that deploys gateways, including GRE tunnel gateways:

Развертывание инфраструктуры программно-конфигурируемой сети с помощью скриптовDeploy a Software Defined Network infrastructure using scripts

Дополнительные сведенияMore information

Дополнительные сведения о развертывании шлюзов S2S см. в следующих разделах:For more information about deploying S2S gateways, see the following topics:

Урок 47. Настройка GRE IPSec туннеля на Cisco

Краткая теория

GRE (Generic Routing Encapsulation) — проприетарный протокол Cisco для организации VPN соединений. Работает он по такому же принципу, что и IPSec, то есть к исходному пакету данных добавляет свой заголовок, за которым следует новый IP заголовок с новыми IP адресами. Выглядит этот так:

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

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

GRE также идеален для передачи IPv6 поверх IPv4 и наоборот.

При настройке GRE туннеля следует учитывать тот факт, что при добавлении GRE заголовка увеличивается MTU всего пакета. Это может привести к тому, что некоторые маршрутизаторы уничтожат пакеты, если не настроены на передачу с увеличенным MTU. Фрагментация GRE пакетов также запрещена, поэтому в идеале лучше уменьшить MTU в самом начале туннеля.

Настройка GRE

Итак, приступим к настройке протокола. Схема сети выглядит так:

В данном примере мы рассматриваем конфигурацию GRE типа IPv4-over-IPv4 с использованием NAT.

Настраиваем туннельный интерфейс:

Headquarter(config)# interface Tunnel 10

Теперь нужно указать IP адрес данного интерфейса. Делается это для того, чтобы указать GRE какой сетевой протокол будет инкапсулироваться, IPv4 или IPv6 либо какой-нибудь другой протокол:

Headquarter(config-if)# ip address 100.0.0.1 255.255.255.0

Указываем начало туннеля:

Headquarter(config-if)# tunnel source 1.1.1.1

А также конец туннеля:

Headquarter(config-if)# tunnel destination 2.2.2.1

Осталось теперь пустить весь трафик, идущий в сеть 192.168.2.0/24 в наш туннель:

Headquarter(config)# ip route 192.168.2.0 255.255.255.0 interface tunnel 10

То же самое с учетом адресов проделываем и на противоположном конце. Вот как выглядят настройки на обоих маршрутизаторах:

Убедимся в работе туннеля запустив Ping на одном из компьютеров:

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

Keepalive

Что произойдет с туннелем, если интерфейс на конечном маршрутизаторе отключится интерфейс либо оборвется кабель на промежуточном участке связи?

Отключим интерфейс Tunnel 10 на маршрутизаторе Branch:

Если запустим Ping с главного офиса, то результат будет отрицательный. Взглянем на состояние интерфейсов на Headquarter:

Все интерфейсы и линейные протоколы связи в состоянии UP. Проверим сам интерфейс Tunnel в деталях:

Здесь тоже все в порядке. Попробуем “пингануть” туннельный интерфейс на противоположном конце с роутера Headquarter:

Данная информация косвенно подтверждает тот факт, что на противоположном конце не все гладко, конечно, при условии, что маршрутизация в целом и WAN интерфейс на Branch работают как надо.

Чтобы избежать такой ситуации в GRE предусмотрена отправка пакетов Keepalive. Давайте настроим ее на интерфейсе Tunnel 10:

Headquarter(config-if)# keepalive 10 3

Здесь мы указываем отправлять пакеты keepalive каждые 10 с. Если ответ не будет получен после 3-х попыток, то перевести туннель в состояние Down.

Loopback или реальный интерфейс

В официальной документации сказано, что качестве начала и конца туннеля можно указывать либо реальный интерфейс либо Loopback. Давайте разберемся в чем разница. Добавим к нашей сети еще один роутер для резервирования маршрута:

Если мы отключим роутер ISP, то туннель автоматически перекинется через резервный маршрутизатор и будет прекрасно работать. Однако, если мы отключим интерфейс Fa0/1 на Headquarter, то туннель перейдет в состояние Down. Это связано с тем, что в качестве начала туннеля указан адрес интерфейса Fa0/1 и теперь при отключении данного порта отключается и сам туннель.

Чтобы избежать подобной ситуации рекомендуется использовать Loopback интерфейс в качестве начала и конца туннеля, причем он должен иметь маршрутизируемый адрес. То есть порт должен быть доступен по сети.

Конечно, если у вас один uplink, то достаточно указать реальный WAN интерфейс, но если 2 и более, то лучше воспользоваться Loopback.

Настройка GRE over IPSec

GRE не поддерживает шифрование, однако, если необходимо организовать защищенный канал связи, то можно построить туннель GRE поверх IPSec. Организация защищенного канала IPSec состоит из 2-х фаз. В первой фазе мы определяем политику безопасности (ISAKAMP IKE) для создания служебного туннеля, а во второй — параметры туннеля (IPSec) для передачи данных.

Для начала настроим политику безопасности ISAKMP на маршрутизаторе Headquarter:

Headquarter(config)# crypto isakmp policy 1

Headquarter(config-iakmp)# encryption aes — метод шифрования aes

Headquarter(config-isakmp)# authentication pre-share — метод аутентификации pre-share

Headquarter(config-isakmp)# group 2 — метод обмена секретными ключами (метод Диффи-Хеллмана)

Headquarter(config-isakmp)# lifetime 10000 — время жизни сессии 10 000 с

Определим IP адрес конечной точки туннеля, то есть IP адрес Branch, а также их общий ключ pre-share для аутентификации:

Headquarter(config)# crypto isakmp key 6 PASSWORD address 2.2.2.1

Настроим параметры туннеля IPSec:

Headquarter(config)# crypto ipsec transform-set GRE-IPSEC esp-3des esp-sha-hmac

Теперь создадим профиль подключения и назовем его GRE. В нем мы укажем параметры туннеля:

Headquarter(config)# crypto ipsec profile GRE

Headquarter(ipsec-profile)# set security-association lifetime seconds 10000

Headquarter(ipsec-profile)# set transform-set GRE-IPSEC

И наконец заключительный этап — мы привяжем наш профиль к туннельному интерфейсу:

Headquarter(config-if)# tunnel protection ipsec profile GRE

Теперь запустим Ping и проверим работоспособность туннеля. Однако почему-то он не работает. Дело в том, что у нас включена отправка Keepalive. Маршрутизатор отправляет keepalive пакеты по незащищенному каналу и поэтому IPSec туннель не устанавливается. Если отключить keepalive, то туннель сразу установится и начнет работать.

Комментарии для сайта Cackle

Yellow Leaf — Статьи — Объединение сетей двух офисов с помощью GRE-туннеля

Допустим некоторая организация открывает свой первый филиал и нужно быстро решить проблему связи локальных сетей головного офиса и филиала. В случае если доступ в интернет в обоих офисах осуществляется через шлюз под управлением Debian и оба офиса имеют реальные IP-адреса можно организовать GRE-туннель.

Протокол GRE создавался для организации туннелей и главным его достоинством является простота. Из недостатков стоит отметить отсутствие какого-либо шифрования, невозможность работать через NAT и необходимость использования постоянных IP-адресов по обе стороны туннелей. Однако если эти недостатки не являются критичными то можно приступать к настройке туннеля. Она не займёт много времени.

Допустим что в обоих офисах стоит шлюз под управлением Debian. На кажом сервере по две сетевые карты:

eth0: Смотрит в интернет. В центральном офисе адрес 1.1.1.1, в филиале — 1.1.2.2;

eth2: Смотрит в локальную сеть офиса. В центральном офисе: 192.168.101.1/24, в филиале — 192.168.102.1/24.

Установка необходимого ПО и настройка sysctl хорошо описаны в одной из предыдущих статей. Нас остаётся только:

Настроить GRE-туннель;

Настроить маршрутизацию;

Настроить iptables.

На обоих серверах будет создан интерфейс tun0. В головном офисе он будет иметь адрес 172.17.254.1 а в филиале — 172.17.254.2. Маршрут на сеть другого офиса будет идти через этот интерфейс.

В файл /etc/network/interfaces в головном офисе добавим следующие строки:


auto tun0
iface tun0 inet static
    address 172.17.254.1
    netmask 255.255.255.255
    up ifconfig tun0 multicast
    pre-up iptunnel add tun0 mode gre local 1.1.1.1 remote 1.1.2.2 ttl 255
    pointopoint 172.17.254.2
    post-down iptunnel del tun0
    post-up ip route add 192.168.102.0/24 dev tun0

В филиале в этот файл нужно добавить строки:


auto tun0
iface tun0 inet static
    address 172.17.254.2
    netmask 255.255.255.255
    up ifconfig tun0 multicast
    pre-up iptunnel add tun0 mode gre remote 1.1.1.1 local 1.1.2.2 ttl 255
    pointopoint 172.17.254.1
    post-down iptunnel del tun0
    post-up ip route add 192.168.101.0/24 dev tun0

Далее нужно поднять на обоих серверах туннель командой:


ifup tun0

При поднятии интерфейса автоматически будут добавлять нужные маршруты (параметр post-up). Остаётся настроить iptables. Скрипт конфигурации на сервере головного офиса будет выглядеть примерно так:


#!/bin/sh

# Минимальные настройки скрипта
# Внешний интерфейс
IF_EXT="eth0"
# Внутренний интерфейс
IF_INT="eth2"
# Интерфейс GRE-туннеля
IF_VPN="tun0"
# Локальная сеть
NET_INT="192.168.101.0/255.255.255.0"
# Локальная сеть второго филиала
NET_REMOTE="192.168.102.0/255.255.255.0"

# На всякий случай сбрасываем все правила
iptables -F
iptables -F -t nat

# Устанавливаем политики по умолчанию:
# Никого не пускать
iptables -P INPUT DROP
# Всех выпускать
iptables -P OUTPUT ACCEPT
# Мимо нас никто не ходит
iptables -P FORWARD DROP

# Впускаем ответы на запросы, которые сами отправили
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# Разрешаем весь трафик на внутреннем интерфейсе
iptables -A INPUT -i lo -j ACCEPT

# Разрешаем весь трафик со стороны локальной сети
iptables -A INPUT -i ${IF_INT} -s ${NET_INT} -j ACCEPT

# Разрешаем GRE-трафик
iptables -A INPUT -p gre -j ACCEPT

# Разрешаем пересылку трафика из локальной сети через GRE-туннель в другой офис и обратно
iptables -A FORWARD -i ${IF_INT} -s ${NET_INT} -o ${IF_VPN} -d ${NET_REMOTE} -j ACCEPT
iptables -A FORWARD -i ${IF_VPN} -s ${NET_REMOTE} -o ${IF_INT} -d ${NET_INT} -j ACCEPT

# NAT для локальной сети на внешнем интерфейсе
iptables -t nat -A POSTROUTING -s ${NET_INT} -j MASQUERADE -o ${IF_EXT}
# Разрешаем пересылку пакетов из локальной сети наружу
iptables -A FORWARD -i ${IF_INT} -o ${IF_EXT} -s ${NET_INT} -j ACCEPT
# Разрешаем пересылку в локальную сеть ответов на исходящие запросы
iptables -A FORWARD -i ${IF_EXT} -o ${IF_INT} -d ${NET_INT} -m state --state RELATED,ESTABLISHED -j ACCEPT

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

На этом всё. Приятной работы!

Создание туннелей с помощью GRE протокола

GRE – Сетевой протокол от компании CISCO Systems для туннелирования соединений, путем инкапсуляции пакетов сетевого уровня в IP пакеты. С помощью протокола GRE создается непрерывное соединение между двумя узлами ( маршрутизаторами ), через общедоступную сеть. Протокол GRE может быть использован для создания простой частной сети (VPN), между пользователями, подключенными через сеть провайдера, или между пограничными маршрутизаторами с среде провайдера, для обмена обновлениями таблиц маршрутизации.

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

Операционная система FreeBSD, полностью поддерживает создание и управление туннелями, протокола GRE.

Поддержка GRE, осуществляется на уровне ядра, соответствующую опцию можно включить в конфигурации ядра на стадии конфигурирования и последующей компиляции, если-же по каким-либо причинам это не сделано, при попытке активировать GRE устройство, в ядро динамически будет загружен необходимый модуль ( if_gre.ko ).

Самый простой способ создать GRE интерфейс, использовать программу ifconfig, например командой:

# ifconfig gre0 create

будет создан интерфейс с именем gre0, если при создании интерфейса, не указывать номер устройства, будет назначен первый свободный, например, gre0 у нас уже есть, теперь, командой:

# ifconfig gre create

будет создан интерфейс с именем gre1, как видите команда ifconfig назначила первый свободный номер.

С помощью той-же команды ifconfig, можно удалить не используемый интерфейс:

# ifconfig gre1 destroy

Теперь, когда интерфейс GRE создан, нужно настроить всех участников соединения, делается это с помощью все той-же команды ifconfig. Предположим, нам нужно настроить туннель между хостами А и Б, схема выглядит следующим образом:

Для начала создаем интерфейс gre0 на хосте А и назначаем конечные точки туннеля:

# ifconfig gre0 create
# ifconfig gre0 192.168.10.1 192.168.10.2 netmask 255.255.255.0 
# ifconfig gre0 tunnel 10.0.2.1 10.0.1.1

На хосте Б делаем то-же самое, используя соответствующие адреса:

# ifconfig gre0 create
# ifconfig gre0 192.168.10.2 192.168.10.1 netmask 255.255.255.0
# ifconfig gre0 tunnel 10.0.1.1 10.0.2.1

Первой строкой, вышеприведенных команд, мы создаем интерфейс gre0.
Второй, назначаем интерфейсу IP адреса, для текущего хоста и для другого конца туннеля.
И наконец в третьей строке устанавливаем туннель между хостами, здесь нужно использовать реальные IP адреса сетевых интерфейсов.

Посмотрим настройки туннеля на хосте А:

# ifconfig gre0
gre0: flags=9051metric
0 mtu 1476
tunnel inet 10.0.2.1 --> 10.0.1.1
inet 192.168.10.1 --> 192.168.10.2 netmask 0xffffff00

Значение MTU, будет высчитано и назначено автоматически с учетом GRE протокола.

Теперь, когда интерфейсы туннеля подняты ( запущены, приведены в состояние UP ), можно проверить соединение пропинговав с хоста А, командой ping, IP адрес туннеля, хоста Б:

# ping -c3 192.168.10.2PING 192.168.10.2 (192.168.10.2): 56 data bytes
64 bytes from 192.168.10.2: icmp_seq=0 ttl=128 time=0.359 ms
64 bytes from 192.168.10.2: icmp_seq=1 ttl=128 time=2.512 ms
64 bytes from 192.168.10.2: icmp_seq=2 ttl=128 time=0.196 ms
--- 192.168.10.2 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.196/1.022/2.512/1.055 ms

Итак, мы довольно быстро подняли туннель, с помощью протокола GRE, между хостом А и Б. Тоже самое можно проделать и на маршрутизаторах ( CISCO или Juniper ). В данном примере мы создавали туннель вручную, этого вполне достаточно что-бы «потренироваться на кошках», но что-бы соединение было постоянным, то есть, после перезагрузки настраивалось автоматически, нужно дописать в стартовый скрипт /etc/rc.d следующие строчки:

cloned_interfaces=»gre0″
ifconfig_gre0=»inet inet 192.168.10.1 192.168.10.2 netmask 255.255.255.0 tunnel 10.0.2.1 10.0.1.1″

Таким образом, с помощью переменной cloned_interfaces можно назначить столько туннелей, сколько вам нужно, и обратите внимание, во второй строке мы объединили 2 команды в одну, то-же самое можно сделать и через командную строку.

Настройка сервера VPN (GRE / IPSec StrongSwan, OSPF Quagga) / Хабр

Кто бы мог подумать, что развернуть часть серверов компании в Amazon было плохой идеей.

В итоге поставленная задача — сделать дополнительный VPN-туннель между Amazon и инфраструктурой в РФ.

Кроме простого опишу несколько вариантов настройки, с помощью которой можно столкнуться.

Настройка файрвола и роутинга

Покупаем у пока еще не заблокированного хостера VPS за сумму, эквивалентную 10 000 монгольских тугриков в месяц, ставим CentOS 7, включая пересылку пакетов

  echo net.ipv4.ip_forward = 1 >> / etc / sysctl.d / ipv4.forward.enable.conf
sysctl -a

Добавляем в файрволе правила приема пакетов IPsec

  firewall-cmd --zone = dmz --permanent --add-rich-rule = 'rule protocol value = "esp" accept'
брандмауэр-cmd --zone = dmz --permanent --add-port = 500 / udp
брандмауэр-cmd --zone = dmz --permanent --add-port = 4500 / udp
firewall-cmd --permanent --add-service = "ipsec"
брандмауэр-cmd --reload
брандмауэр-cmd --list-все

Настройка StrongSwan

Устанавливаем демон IPsec StrongSwan:

  yum install -y epel-release
yum install -y strongswan

Делаем предварительные настройки в / etc / strongswan.d / charon.conf :

  charon {
    # Понадобится при использовании с Cisco IKEv2
    make_before_break = да
    # Необходимо для работы с туннелями
    install_routes = нет
}

Настройка Strongswan может быть проведена двумя способами.

Старый способ, использующий демон strongswan, уже достаточно хорошо описан:
Файл конфигурации
/etc/strongswan/ipsec.conf
Файл с паролями и сертификатами:
/ etc / ipsec.секреты
Остановка службы:
```
  systemctl stop strongswan  
```

Новый способ, использующий демон charon, появившийся в версии 5.2.0:

Вся конфигурация хранится в /etc/strongswan/swanctl/swanctl.conf

Рассмотрим два варианта настройки демона charon :

Одинаковые аутентификации и шифрования для всех. Сделаем разными только PSK:

  соединений {
 ToWorld {
  local_addrs = 10.3.3.1
  версия = 1
  предложения = aes256-sha1-modp1536
  reauth_time = 1440 мин.
  местный {
   auth = psk
  }
  удаленный {
   auth = psk
  }
  дети {
   ToWorld-1 {
    local_ts = динамический [gre]
    remote_ts = динамический [gre]
    режим = транспорт
    esp_proposals = aes128-sha1-modp1536
    rekey_time = 60 мин.
    start_action = ловушка
    dpd_action = перезапуск
   }
  }
 }
}
секреты {
 ike-To-2951
 {
  id = 1.1.1.1
  secret = "etokto2ttakoimohnatenkyi"
 }
 ike-To-CSR1000V
 {
  id = 2.2.2.2
  secret = "здоровкакжизнкасамзпро100класс"
 }
}

Индивидуальные настройки аутентификации и шифрования:

  соединений {
 To2951 {
  encap = нет
  remote_addrs = 1.1.1.1
  версия = 1
  предложения = aes256-sha1-modp1536
  reauth_time = 1440 мин.
  фрагментация = да
  local-1 {
   auth = psk
   id = 10.3.3.1
  }
  remote-1 {
   auth = psk
  }
  дети {
   To2951-1 {
    local_ts = 10.3.3.1/32 [gre]
    remote_ts = 1.1.1.1/32 [gre]
    режим = транспорт
    esp_proposals = aes128-sha1-modp1536
    rekey_time = 60 мин.
    start_action = начало
    dpd_action = перезапуск
   }
  }
 }
 ToCSR1000V {
  encap = нет
  remote_addrs = 2.2.2.2
  версия = 1
  предложения = aes256-sha1-modp1536
  reauth_time = 1440 мин.
  фрагментация = да
  local-1 {
   auth = psk
   id = 10.3.3.1
  }
  remote-1 {
   auth = psk
  }
  дети {
   ToCSR1000V-1 {
    local_ts = 10.3.3.1/32 [gre]
    remote_ts = 2.2.2.2/32 [gre]
    режим = транспорт
    esp_proposals = aes128-sha1-modp1536
    rekey_time = 60 мин.
    start_action = начало
    dpd_action = перезапуск
   }
  }
 }
}
секреты {
 ike-To-2951
 {
  id-1 = 1.1.1.1
  secret = "etokto2ttakoimohnatenkyi"
 }
 ike-To-CSR1000V
 {
  id-1 = 2.2.2.2
  secret = "здоровкакжизнкасамзпро100класс"
 }
}

Включаем службу

  sudo systemctl enable strongswan-swanctl
sudo systemctl start strongswan-swanctl

Поднятие туннелей с маршрутизаторами Cisco

Настраиваем GRE-туннели в CentOS
Создаем / etc / sysconfig / network-scripts / ifcfg-Tunnel13
```
  NAME = Tunnel13
УСТРОЙСТВО = Туннель13
ONBOOT = да
STARTMODE = при загрузке
BOOTPROTO = нет
ТИП = GRE
PEER_OUTER_IPADDR = 1.1.1.1
PEER_INNER_IPADDR = 172.16.130.2 / 30
MY_INNER_IPADDR = 172.16.130.1 / 30
MY_OUTER_IPADDR = 10.3.3.1
ZONE = доверенный
TTL = 30
MTU = 1400
  
```
Создаем / etc / sysconfig / network-scripts / ifcfg-Tunnel23
```
  NAME = Tunnel23
УСТРОЙСТВО = Туннель23
ONBOOT = да
STARTMODE = при загрузке
BOOTPROTO = нет
ТИП = GRE
PEER_OUTER_IPADDR = 2.2.2.2
PEER_INNER_IPADDR = 172.16.230.2 / 30
MY_INNER_IPADDR = 172.16.230.1 / 30
MY_OUTER_IPADDR = 10.3.3.1
ZONE = доверенный
TTL = 30
MTU = 1400
  
```
В настройке GRE-интерфейса есть пара исправлений.
Первая — уменьшить MTU для корректного прохождения пакетов.
Второе — указать TTL, это понадобится в будущем, когда будем настраивать OSPF. Если этого не сделать, пакеты OSPF будут приходить на удаленный хост с TTL, равным единице (из-за GRE по IPsec), оставаясь без ответа. Соответственно устройства будут висеть в состоянии INIT / DROTHER, связности мы не дождемся. При этом правильные ответы ICMP могут сбить с толку.
Поднимаем интерфейсы
```
  ifup Tunnel13
ifup Tunnel23
  
```

Создаем туннель на Cisco 2951

  криптографический брелок StrongSwanKeyring
  адрес предварительного общего ключа 3.3.3.1 ключ etokto2ttakoimohnatenkyi

политика крипто isakmp 60
 код 256
 предварительная проверка подлинности
 группа 5

идентификационный адрес крипто isakmp

крипто isakmp профиль StrongSwanIsakmpProfile
   брелок StrongSwanKeyring
   совпадение идентификационного адреса 3.3.3.1
 
крипто-ipsec набор преобразований StrongSwanTransformSet esp-aes esp-sha-hmac
 вид транспорта

Профиль crypto ipsec StrongSwanIpsecProfile
 set transform-set StrongSwanTransformSet
 установить pfs group5
 установить isakmp-profile StrongSwanIsakmpProfile

интерфейс Tunnel13
 IP-адрес 172.16.130.2 255.255.255.252
 источник туннеля GigabitEthernet2
 пункт назначения туннеля 3.3.3.1
 защита туннеля профиль ipsec StrongSwanIpsecProfile

Создаем туннель на Cisco CSR1000V

  криптографический брелок StrongSwanKeyring
  pre-shared-key address 3.3.3.1 key etokto2ttakoimohnatenkyi

политика крипто isakmp 60
 код 256
 предварительная проверка подлинности
 группа 5

идентификационный адрес крипто isakmp

крипто isakmp профиль StrongSwanIsakmpProfile
   брелок StrongSwanKeyring
   сопоставить идентификационный адрес 3.3.3.1
 
крипто-ipsec набор преобразований StrongSwanTransformSet esp-aes esp-sha-hmac
 вид транспорта

Профиль crypto ipsec StrongSwanIpsecProfile
 set transform-set StrongSwanTransformSet
 установить pfs group5
 установить isakmp-profile StrongSwanIsakmpProfile

интерфейс Tunnel23
 IP-адрес 172.16.230.2 255.255.255.252
 источник туннеля GigabitEthernet2
 пункт назначения туннеля 3.3.3.1
 защита туннеля профиль ipsec StrongSwanIpsecProfile

Проверяем, что туннели поднялись, шифрование работает.

На CentOS

  strongswan statusall

На Cisco

  показать детали криптосессии

Настройка динамической маршрутизации на Quagga

Если вы используете динамическую маршрутизацию на основе OSPF, то следующим логически было бы поднять демон OSPF на CentOS, настроив новые туннели в качестве обслуживания маршрута.

Настройка OSPF на CentOS

В качестве демона установим Quagga:

  yum install -y quagga

Создаем конфигурационный файл демона / etc / quagga / zebra.conf

  имя хоста StrongSwanServer
файл журнала /var/log/quagga/quagga.log
!
интерфейс Tunnel13
 IP-адрес 172.16.130.1/30
!
интерфейс Tunnel23
 IP-адрес 172.16.230.1/30
!

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

Устанавливаем права и включаем службу

 
chown quagga: quaggavt /etc/quagga/zebra.conf
systemctl включить zebra.service
systemctl start zebra.service

Создаем конфигурационный файл демона / etc / quagga / ospfd.conf

  файл журнала /var/log/quagga/ospfd.log
!
маршрутизатор ospf
 ospf идентификатор-маршрутизатора 10.3.3.1
 пассивный интерфейс по умолчанию
 нет туннеля с пассивным интерфейсом13
 без пассивного интерфейса Tunnel23
 сеть 172.16.130.0/30 область 0.0.0.0
 сеть 172.16.230.0/30 область 0.0.0.0

Устанавливаем права и включаем службу

 
chown quagga: quaggavt /etc/quagga/ospfd.conf
systemctl включить ospfd.service
systemctl start ospfd.service

Далее запускаем терминал vtysh и работать с Quagga в циско-подобном интерфейсе, например:

  vtysh
показать текущую конфигурацию

Настройка OSPF на маршрутизаторе Cisco 2951

  ospf 1
 пассивный интерфейс по умолчанию
 без пассивного интерфейса Tunnel12
 нет туннеля с пассивным интерфейсом13
 нет пассивного интерфейса GigabitEthernet1
 сеть 192.168.1.0 0.0.0.255 область 0
 сеть 172.16.120.0 0.0.0.3 область 0
 сеть 172.16.130.0 0.0.0.3 область 0

Настройка OSPF на Cisco CSR1000V

  маршрутизатор ospf 1
 пассивный интерфейс по умолчанию
 без пассивного интерфейса Tunnel12
 без пассивного интерфейса Tunnel23
 нет пассивного интерфейса GigabitEthernet1
 сеть 192.168.2.0 0.0.0.255 область 0
 сеть 172.16.120.0 0.0.0.3 область 0
 сеть 172.16.230.0 0.0.0.3 область 0

Проверяем видимость соседей и пришедшие маршруты на CentOS:

  втыш
показать соседа ospf
показать маршрут ip ospf

и на Cisco:

  показать соседа ospf
показать ip ospf route

Что осталось нерассмотренным
Я описал самый простой вариант.Конечно же, вы настроите обмен ключами, используя IKE v2, авторизацию по сертификату, добавите в файрвол дополнительную фильтрацию по адресам, сделаете OSPF авторизацию и, при большом количестве маршрутизаторов, с разделением на область, измените значения hello-interval и dead-interval на интерфейсах.
Буду рад советам в комментариях, а информации об опечатках — в личку. Спасибо за внимание.

GRE — пример и описание

GRE (Generic Routing Encapsulation) — протокол инкапсуляции, который широко применяется как сам по себе, так и в совокупности с IPSec для создания туннелей. Перед прочтением данной статьи рекомендуется ознакомиться со статьёй «Принципы организации VPN».

В этой статье мы будем настраивать GRE туннель. Сам по себе GRE не обеспечивает никакой безопасности передаваемых данных — это VPN типа «сеть-сеть» туннель в чистом виде.Используется обычно такой туннель, когда есть специфичные задачи, связанные с маршрутизацией и нет требований к безопасности. Не стоит забывать, что чистый GRE туннель — не нагружает оборудование, нагрузка при шифровании большого объёма данных весьма существенна.

Протокол GRE инкапсулируется напрямую в IP, минуя TCP или UDP, в IP пакете есть специальное поле « Тип протокола », в котором содержится число, обозначающее, инкапсулированный в данном IP пакете, для протокола GRE с типом равен 47.В связи с этим, если в сети есть GRE туннели, то стоит внимательно относиться к написанию расширенных списков контроля доступа (ACL), так как разрешить tcp любой любой и разрешить udp любой любой приведут к запрету на GRE из-за того , что он инкапсулируется напрямую в пакет, надо либо разрешить ip любой любой либо разрешение gre любой любой .

Схема инкапсуляции GRE выглядит следующим образом:

Как видно, IP инкапсулируется в GRE, который инкапсулируется в IP.При этом заголовок GRE и заголовок внешнего IP-пакета добавить 24 байта, соответственно, уменьшая размер пакета на эту часть. В данном примере мы настраиваем IPv4 в GRE в IPv4, тем не менее, GRE может успешно работать с другими инкапсулируемыми и транспортными протоколами, например, IPv6.

Рассмотрим работающую топологию. Есть две локальные сети: LAN1 за маршрутизатором R1 с адресом 192.168.0.0/24 и LAN2 — за маршрутизатором R3, с адресом 192.168.1.0/24. В каждой сети есть по одному компьютеру.Между маршрутизаторами есть сети 1.0.0.0/8 и 2.0.0.0/8, а также маршрутизатор R2 — это в нашем примере интернет. Маршрутизация для простоты настроена с помощью протокола RIP.

Выполним трассировку с компьютера PC1 до компьютера PC2:

 Трассировка маршрута до 192.168.1.2 максимум на 30 переходах:
  1 0 мс 0 мс 0 мс 192.168.0.1
  2 0 мс 0 мс 0 мс 1.1.1.2
  3 0 мс 0 мс 0 мс 2.2.2.2
  4 1 мс 0 мс 0 мс 192.168.1.2

Как видно, пакет проходит через все адресаторы последовательностей, до компьютера. Теперь создадим GRE туннель между R1 и R3 со внутренней адресацией 10.10.10.0/24.

 R1 (config) # интерфейсный туннель 0
R1 (config-if) #
% LINK-5-CHANGED: Интерфейс Tunnel0, состояние изменено на up
R1 (config-if) # режим туннеля gre ip
R1 (config-if) #ip адрес 10.10.10.1 255.255.255.0
R1 (config-if) #tunnel source FastEthernet0 / 1
R1 (config-if) # место назначения туннеля 2.2.2.2
R1 (config-if) #
% LINEPROTO-5-UPDOWN: линейный протокол на интерфейсе Tunnel0, состояние изменено на up
R1 (config-if) # выход

Мы создали интерфейс Tunnel0, в нём указали с помощью IP-адреса внутренний адрес туннеля — тот есть этот адрес инкапсулированного IP, с помощью команд источника туннеля и назначения туннеля мы указали параметры протокола IP (внешнего).У нас появилась новая сеть, которая виртуально соединяет напрямую два маршрутизатора R1 и R3 (без лишнего хопа на R2). Настроим вторую сторону туннеля — на R3. Для примера создадим интерфейс Tunnel99:

 R3 (config) # интерфейсный туннель 99
R3 (config-if) #
% LINK-5-CHANGED: интерфейс Tunnel99, состояние изменено на "вверх"
R3 (config-if) # режим туннеля gre ip
R3 (config-if) #ip адрес 10.10.10.2 255.255.255.0
R3 (config-if) #tunnel source FastEthernet0 / 0
R3 (config-if) # пункт назначения туннеля 1.1.1.1
R3 (config-if) #
% LINEPROTO-5-UPDOWN: линейный протокол на интерфейсе Tunnel99, состояние изменено на up
R3 (config-if) # выход

Теперь выполним трассировку с маршрутизатора R1 противоположного конца туннеля — на R3:

 R1 # traceroute 10.10.10.2
Для прерывания введите escape-последовательность.
Отслеживание маршрута до 10.10.10.2
  1 10.10.10.2 1 мс 0 мс 0 мс

 R1 # показать IP-маршрут
Коды: C - подключен, S - статический, I - IGRP, R - RIP, M - мобильный, B - BGP.
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - внутренняя область OSPF
       N1 - OSPF NSSA внешний тип 1, N2 - OSPF NSSA внешний тип 2
       E1 - OSPF внешний тип 1, E2 - OSPF внешний тип 2, E - EGP
       i - IS-IS, L1 - IS-IS уровень-1, L2 - IS-IS уровень-2, ia - IS-IS внутри области
       * - кандидат по умолчанию, U - статический маршрут для каждого пользователя, o - ODR
       P - периодически загружаемый статический маршрут
Шлюз последней инстанции не установлен
С 1.0.0.0 / 8 подключен напрямую, FastEthernet0 / 1
R 2.0.0.0/8 [120/1] через 1.1.1.2, 00:00:12, FastEthernet0 / 1
     10.0.0.0/24 разделен на подсети, 1 подсеть
C 10.10.10.0 подключен напрямую, Tunnel0
C 192.168.0.0/24 подключен напрямую, FastEthernet0 / 0
R 192.168.1.0/24 [120/2] через 1.1.1.2, 00:00:12, FastEthernet0 / 1

Видно, что новая сеть отображается, как непосредственно подключенная к интерфейсу туннель 0. Если сейчас попробовать сделать трассировку с компьютера 1 до компьютера 2, то она не пойдёт по туннелю.Это связано с тем, что на маршрутизаторе R1 нет соответствующего маршрута. Просматривая свою таблицу маршрутизации, R1 отправит пакеты на PC2 по системе « R 192.168.1.0/24 [120/2] через 1.1.1.2, 00:00:12, FastEthernet0 / 1 », то есть как и раньше — в обход туннеля. Чтобы исправить ситуацию пропишем с двух сторон на R1 и R3 статические маршруты, которые явно указываются в сети 192.168.0.0 и 192.168.1.0 надо доставлять трафик через туннель. На R1:

 R1 (config) #ip route 192.168.1.0 255.255.255.0 10.10.10.2

На R3:

 R3 (конфигурация) #ip route 192.168.0.0 255.255.255.0 10.10.10.1
R3 # показать IP-маршрут
Коды: C - подключен, S - статический, I - IGRP, R - RIP, M - мобильный, B - BGP.
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - внутренняя область OSPF
       N1 - OSPF NSSA внешний тип 1, N2 - OSPF NSSA внешний тип 2
       E1 - OSPF внешний тип 1, E2 - OSPF внешний тип 2, E - EGP
       i - IS-IS, L1 - IS-IS уровень-1, L2 - IS-IS уровень-2, ia - IS-IS внутри области
       * - кандидат по умолчанию, U - статический маршрут для каждого пользователя, o - ODR
       P - периодически загружаемый статический маршрут
Шлюз последней инстанции не установлен
R 1.0.0.0 / 8 [120/1] через 2.2.2.1, 00:00:05, FastEthernet0 / 0
C 2.0.0.0/8 подключен напрямую, FastEthernet0 / 0
     10.0.0.0/24 разделен на подсети, 1 подсеть
C 10.10.10.0 подключен напрямую, Tunnel99
S 192.168.0.0/24 [1/0] через 10.10.10.1
C 192.168.1.0/24 подключен напрямую, FastEthernet0 / 1

Теперь, как видно из схемы маршрутизации, трафик пойдёт через GRE туннель. Проверим это, выполнив трассировку с PC1 на PC2, как и в начале этой статьи:

 tracert 192.168.1.2
Трассировка маршрута до 192.168.1.2 максимум на 30 переходах:
  1 0 мс 0 мс 0 мс 192.168.0.1
  2 0 мс 0 мс 0 мс 10.10.10.2
  3 1 мс 0 мс 1 мс 192.168.1.2
Трассировка завершена.

Как видно из результатов трассировки, теперь на пути всего два хопа: 192.168.0.1 — R1, шлюз PC1, заворачивает трафик в туннель. Далее, транспортный (внешний) IP-пакет с GRE, внутри проходит на R2, затем на R3 и только тут из пакета декапсулируется внутренний IP — это и есть наш второй хоп — 10.10.10.2, затем пакет по локальной сети идёт адресату — на 192.168.1.2, если добавить в интернете ещё несколько маршрутизаторов, то трассировка не изменится, в ней по-прежнему будет два хопа до адресаата. Пример конфигурации доступен в формате pkt.

(MikroTikUbuntu) * GRE / IPsec / Хабр

Итак, у нас есть статический публичный IP-адрес, с которого приходит Ethernet-шнур в MikroTik RouterBOARD 750G r3 (hEX). Пробуем собрать такую конструкцию.

Настройку L2tp линка в этой статье я не описываю, а на схеме он нарисован только потому, что в ней упоминается.

Как вы уже догадались, нужна система, которая включена в интернет за пределами РФ. Большие деньги на это тратить не хотелось, и я остановился на Aruba Cloud. Здесь всего за 1 евро в месяц дается VM в локациях Италия, Чехия, Германия, Франция и Великобритания. Я свой выбор остановил на Чехии, потому что ping до наших ресурсов оказался на 20 мс меньше, чем с итальянского (50 мс против 70 мс). Ubuntu 16.04 LTS поднялась очень быстро. Войти в нее удалось раньше, чем «позеленел» статус в интерфейсе «облака».

Сервер устанавливается в минимальной конфигурации. Не помешает установить утилитку traceroute.

  $ sudo apt install traceroute

Выбор в пользу GRE сделан по нескольким причинам:

просто и понятно настраивается;
легко траблешутится;
маршрутизация проще некуда;
элементарно отрисовывается график загрузки интерфейса в MikroTik.

Итак, на стороне Ubuntu описываем интерфейс tun1 в / etc / network / interfaces

  $ sudo cat << EOF >> / etc / network / interfaces
 iface tun1 inet статический
    адрес 192.168.10.1
    маска сети 255.255.255.0
    pre-up iptunnel добавить режим tun1 gre local 80.211.x.x удаленный 188.x.x.x ttl 255
    вверх ifconfig tun1 multicast
    пойнтопоинт 192.168.10.2
    пост-вниз iptunnel del tun1
EOF

Здесь все просто:

80.211.x.x — адрес ВМ с Ubuntu в Чехии;
188.x.x.x — внешний адрес MikroTik;
192.168.10.1 — адрес на туннельном интерфейсе tun1 на стороне Ubuntu;
192.168.10.2 — адрес туннельного интерфейса на MikroTik;

Активацию этой части конфигурации я по-старинке делаю так:

  $ sudo service network restart

Получил конструктивную критику такого метода активации настроек сети.

У нас получился вот такой интерфейс:

  $ ifconfig tun1
tun1 Link encap: UNSPEC HWaddr 10-D3-29-B2-00-00-B0-8A-00-00-00-00-00-00-00-00
          inet адрес: 192.168.10.1 P-t-P: 192.168.10.2 Маска: 255.255.255.255
          inet6 адрес: fe80 :: 200: 5ffa: 50d3: c9c2 / 64 Объем: Ссылка
          ТОЧКА ВВЕРХ ТОЧКА РАБОТАЕТ NOARP MULTICAST MTU: 1476 Метрическая система: 1
          Пакеты RX: 379 ошибок: 0 отброшено: 0 переполнений: 0 кадров: 0
          Пакеты TX: 322 ошибки: 4 сброшены: 7 переполнений: 0 Несущая: 0
          коллизии: 0 txqueuelen: 1
          Байт RX: 103387 (103.3 КБ) Байт передачи: 159422 (159,4 КБ)

Со стороны MikroTik настройка тоже несложная. Я делал это из Web-интерфейса.

Обращаю внимание на то, что не сконфигурирован keepalive. Мне так и не удалось включить ответную часть на Ubuntu. Если не будет трафика, то интерфейс на MikroTik будет «уходить» из , запущен и подниматься, только если пойдет трафик со стороны Ubuntu.

Устанавливаем IP-адрес на туннельный интерфейс на стороне MikroTik 192.168.10.2

На этом этапе мы должны подняться туннельные интерфейсы с двух сторон. Проверить это просто. Достаточно запустить запуск c Ubuntu в сторону MikroTik.

  $ пинг 192.168.10.2
PING 192.168.10.2 (192.168.10.2) 56 (84) байтов данных.
64 байта из 192.168.10.2: icmp_seq = 1 ttl = 64 time = 56.0 мс
64 байта из 192.168.10.2: icmp_seq = 2 ttl = 64 time = 59.9 мс
64 байта из 192.168.10.2: icmp_seq = 3 ttl = 64 time = 56,3 мс
64 байта из 192.168.10.2: icmp_seq = 4 ttl = 64 time = 56.1 мс
--- 192.168.10.2 статистика пинга ---
4 пакета передано, 4 получено, потеря пакетов 0%, время 3004 мс
rtt min / avg / max / mdev = 56,091 / 57,137 / 59,936 / 1,618 мс
user @ vps: ~ $

Настраиваем маршрутизацию в сторону абонентских сетей в туннельный интрефейс

Приватные IP адреса локальной сети, из которых осуществляется выход в интернет — 192.168.1.0/24. Сеть 192.168.6.0/24 — это сеть, выделенная для подключения к MikroTik по L2TP из «внешнего мира». Для компьютеров, работающих в рамках локальной сети и удаленных устройств, добавлены маршруты на обе сети в конец файла / etc / network / interfaces

  $ sudo cat << EOF >> / etc / network / interfaces
# статический маршрут "
вверх ip ro добавить 192.168.1.0 / 24 через 192.168.10.2
up ip ro добавить 192.168.6.0/24 через 192.168.10.2
EOF

Еще раз просим обновить сетевые настройки

  $ sudo service network restart

Включаем ip_forward

  $ sudo echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
$ sudo sysctl -p

Прописываем SNAT.
Для статического внешнего IP он должен работать быстрее чем MASQUERADE за счет того, что не нужно каждый раз узнать IP адрес интерфейса.

  $ sudo iptables -t nat -A POSTROUTING -j SNAT --to-source 80.211.xx -o eth0

Настаиваем маршрутизацию на MikroTik

Всегда у меня не стоит задача «развернуть» весь трафик в интернет. страну, то в туннельный интерфейс я буду маршрутизировать только интересующие меня ресурсы. В качестве такого ресурса я выбрал Linkedin.

Итак, добавляем маршруты на MikroTik (через терминалку):

  / ip route
добавить комментарий = linkedin distance = 1 dst-address = 91.225.248.0 / 22 шлюз = gre-tunnel1
добавить комментарий = linkedin distance = 1 dst-address = 108.174.0.0 / 20 gateway = gre-tunnel1
добавить комментарий = linkedin distance = 1 dst-address = 185.63.144.0 / 22 gateway = gre-tunnel1

Этот моменту у меня начал открываться заветный ресурс и на этом можно было бы и закончить, поскольку трафик GRE не шифрован и его прекрасно видно в Wireshark, далеко не все провайдеры DPI-ят трафик (а если и DPI- ят, то точно не заглядывают внутрь туннелей для трафика от запрещенных ресурсов), да и АПК «Ревизор» не интересуется тем, какой реально абонентами потребляется трафик.

На дальнейшие эксперименты меня натолкнул тот факт, что в настройках GRE интерфейса MikroTik есть опция IPsec Secret . Неужели действительно все так просто ?!

В качестве шифровальщика на стороне Ubuntu я выбрал strongSwan. Пример конфигурации я взял из материала Настройте GRE через защищенный частный канал IPSec, но сразу не заработало и пришлось внести некоторые правки.

Устанавливаем

  $ apt install strongswan

Внесим в основной файл strongSwan вот это:

  $ cat << EOF> / etc / ipsec.conf
# ipsec.conf - файл конфигурации strongSwan IPsec

настройка конфигурации
    charondebug = "ike 2, knl 2, cfg 2, net 2, esp 2, dmn 2, mgr 2"

conn% по умолчанию
# keyexchange = ikev2

конн микротик
    # Попробуйте подключиться при запуске демона
    auto = start

    # Аутентификация по PSK (см. Ipsec.secret)
    authby = секрет

    # Отключить сжатие
    сжатие = нет

    # Повторный набор настроек
    closeaction = clear
    dpddelay = 30 с
    dpdtimeout = 150 с
    dpdaction = перезапуск

    # Настройки аутентификации ESP (Фаза 2)
    esp = aes128-sha1-modp2048, aes256-sha1-modp2048

    # UDP редиректы
    forceencaps = нет

    # Настройки аутентификации IKE и связки ключей (Фаза 1)
    ike = aes128-sha1-modp2048, aes256-sha1-modp2048
    ikelifetime = 86400 с
    keyingtries =% навсегда
    время жизни = 3600 с

    # Версия Internet Key Exchange (IKE)
    # По умолчанию: Харон - ikev2, Плутон: ikev1
    keyexchange = ikev1

    # тип соединения
    тип = транспорт

    # Пэров
    слева = 188.x.x.x
    справа = 80.211.x.x

    # Тип протокола. Может не работать в числовом формате, тогда нужно установить gre
    leftprotoport = 47
    rightprotoport = 47
EOF

Прописываем pre-shared-key (PSK) в /etc/ipsec.secrets

  $ echo "80.211.xx 188.xxx: PSK VeryBigSecret" >> /etc/ipsec.secrets

Перезапускаем strongSwan

  $ перезапуск ipsec

На этом настройка Ubuntu практически завершена. Приступаем к настройке MikroTik.

Я выставил вот такие настройки дефалтового предложения

Настало время вписать в поле IPsec Secret тот же PSK, который был указан в /etc/ipsec.secrets на сервере (VeryBigSecret).

Если все получилось, то выполняем диагностику на обоих концах туннеля.

MikroTik

Если «провалиться» глубже, то должно быть вот так:

Ubuntu

  $ статус ipsec
Ассоциации безопасности (1 вверх, 0 подключений):
        mikrotik [2]: УСТАНОВЛЕНО 60 минут назад, 80.211.x.x [80.211.x.x] ... 188.x.x.x [188.x.x.x]
        mikrotik {2}: УСТАНОВЛЕН, ТРАНСПОРТ, reqid 1, SPI ESP: cc075de3_i 07620dfa_o
        mikrotik {2}: 80.211.x.x / 32 [gre] === 188.x.x.x / 32 [gre]

Теперь GRE (протокол 47) между MikroTik и Ubuntu шифруется IPseс (ESP). Анализ pcap файла, снятого tcpdump-ом, это подтвердил.

Вроде бы, все работает и заветный ресурс открывается. Однако после того, как я направил в туннель еще несколько ресурсов, оказалось, что не все так хорошо, как казалось изначально.Удалось выяснить, что перестали проходить пакеты большого размера (вернее, они перестали правильно фрагментироваться).

Решение нашлось быстро. Оказалось, что достаточно уменьшить MTU до 1435 на обоих концах туннеля.

MikroTik

Ubuntu — добавляем mtu 1435 в описание интерфейса.

  авто тюнинг1
iface tun1 inet статический
    адрес 192.168.10.1
    маска сети 255.255.255.0
    pre-up iptunnel добавить режим tun1 gre local 80.211.x.x remote 188.x.x.x ttl 255
    вверх ifconfig tun1 multicast
    пойнтопоинт 192.168.10.2
    MTU 1435
    пост-вниз iptunnel del tun1

Диагностика IPsec соединения не тривиальна. На Ubuntu логи читаются значительно проще, чем на MikroTik. По умолчанию на MikroTik выключено логирование IPsec. Включается просто, но проводить анализ проще через терминалку.

Мне удалось добиться скорости загрузки 25 Мбит / с и отдачи 50 Мбит / с. На мой взгляд, этого вполне хватает для комфортной работы с ресурсом.Почему не разгоняется больше — это пока загадка. Загрузка процессоров на обоих концах туннеля не высока. Основная версия — это ограничение скорости на стороне облака. Как-нибудь на досуге погоняю файлы между серверами без шифрования.

UPD 1: настройка iptables

Устанавливаем пакет netfilter-persistent

  $ sudo apt install netfilter-persistent

Я потом писал правила командами, а записал их в /etc/iptables/rules.v4 командой iptables-save> / etc / iptables / rules.v4

В итоге у меня получился вот такой набор:

  $ cat /etc/iptables/rules.v4
# Создано с помощью iptables-save v1.6.0 в четверг, 14 сентября, 20:36:19 2017
* нац
: PREROUTING ACCEPT [17: 3042]
: ВВОД ПРИНЯТЬ [2:92]
: OUTPUT ACCEPT [0: 0]
: ПРИНЯТИЕ ПОСТРОУТИРОВКИ [0: 0]
-A POSTROUTING -o eth0 -j SNAT --to-source 80.211.x.x
COMMIT
# Завершено чт, 14 сен, 20:36:19 2017
# Создано с помощью iptables-save v1.6.0 в четверг, 14 сентября, 20:36:19 2017
*фильтр
: INPUT DROP [29: 4527]
: FORWARD DROP [0: 0]
: OUTPUT ACCEPT [0: 0]
-A ВВОД -i lo -j ПРИНЯТЬ
-A ВВОД -p icmp -j ПРИНЯТЬ
# TCP / 4022 - это нестандартный порт для ssh (я всегда меняю порт, чтобы было меньше port-scan-а)
# !!! если ssh на стандартном порту, замена может нарушить вход на сервер
-A ВВОД -p tcp -m tcp --dport 4022 -j ПРИНЯТЬ
-A ВВОД -p udp -m udp --dport 500 -j ПРИНЯТЬ
-A ВВОД -p gre -j ПРИНЯТЬ
-A ВВОД -p esp -j ПРИНЯТЬ
# Пересылка
-A ВПЕРЕД -j ПРИНЯТЬ
COMMIT
# Завершено четверг, 14 сен, 20:36:19 2017

В / etc / rc.местный я добавил активацию правил при старте машины (другим способом мне это сделать пока не удалось).

  $ echo "iptables-restore > /etc/rc.local

После перезагрузки сервера проверяем, что все правила на месте.

  $ iptables -L -n -v
Цепочка INPUT (политика DROP: 185 пакетов, 28847 байт)
 pkts bytes target prot opt in source назначение
    4 344 ПРИНЯТЬ все - lo * 0.0.0.0/0 0.0,0.0 / 0
   32 896 ПРИНЯТЬ icmp - * * 0.0.0.0/0 0.0.0.0/0
  948 66063 ПРИНЯТЬ tcp - * * 0.0.0.0/0 0.0.0.0/0 tcp dpt: 3022
  172 21504 ПРИНЯТЬ udp - * * 0.0.0.0/0 0.0.0.0/0 UDP dpt: 500
 2864 454K ПРИНЯТЬ 47 - * * 0.0.0.0/0 0.0.0.0/0
 2864 582K ПРИНЯТЬ esp - * * 0.0.0.0/0 0.0.0.0/0

Цепочка FORWARD (политика DROP 0 пакетов, 0 байтов)
 pkts bytes target prot opt in source назначение
 4572 3303K ПРИНЯТЬ все - * * 0.0,0.0 / 0 0,0.0.0/0

ЦЕПНЫЙ ВЫХОД (политика ПРИНЯТЬ 1820 пакетов, 2974 Кбайт)
 pkts bytes target prot opt in source назначение
 4797 6544K ПРИНЯТЬ все - * * 0.0.0.0/0 0.0.0.0/0 состояние СВЯЗАННО, УСТАНОВЛЕНО

UPD 2: рекомендую отключить MikroTik Neighbor discovery на интерфейсе gre-tunnel1.
Если это не сделать, то при вышеописанных настройках iptables будут отбрасывать пакеты на UDP / 5678.

  Сен 15 19:25:33 ядро vps: [42049.805599] IN = tun1 OUT = MAC = SRC = 192.168.10.2 DST = 255.255.255.255 LEN = 133 TOS = 0x00 PREC = 0x00 TTL = 64 ID = 0 DF PROTO = UDP SPT = 36233 DPT = 5678 LEN = 113

PS: В планах настроить IKEv2 туннель с устройств (я использую технику Apple) непосредственно на сервере с использованием моих сертификатов. Пока мне не удалось это сделать. Apple-девайсы почему-то не требуются требования на защищенное соединение со стороны сервера.Можно, конечно, сделать L2tp, но это уже не интересно: такой опыт у меня уже был. .

Туннелирование GRE в Windows Server 2016

07.08.2020
Чтение занимает 4 мин

В этой статье

Область применения. Windows Server (полугодовой канал), Windows Server 2016 Применимо к: Windows Server (полугодовой канал), Windows Server 2016

Windows Server 2016 предоставляет обновления для шлюза RAS с универсальной маршрутизацией (GRE).Windows Server 2016 предоставляет обновления для возможности туннеля Generic Routing Encapsulation (GRE) для шлюза RAS.

GRE — это упрощенный протокол туннелирования, который может инкапсулировать разнообразные протоколы сетевого уровня внутри виртуальных каналов «точка-точка» в IP-сети. GRE — это облегченный протокол туннелирования, который может инкапсулировать широкий спектр протоколов сетевого уровня внутри виртуальной точки-точки. точечные ссылки по объединенной сети Интернет-протокола. Реализация Microsoft GRE может инкапсулировать IPv4 и IPv6.Реализация Microsoft GRE может инкапсулировать IPv4 и IPv6.

Туннели GRE полезны во многих сценариях, поскольку туннели GRE полезны во многих сценариях, потому что:

Они являются упрощенными и совместимыми с различными устройствами поставщика. Они легкие и совместимы с RFC 2890, что делает их совместимыми с устройствами различных поставщиков
(Для динамической маршрутизации можно использовать протокол BGP BGP.) Вы можете использовать протокол пограничного шлюза (BGP) для динамической маршрутизации
Вы можете настроить многоклиентские программные шлюзы GRE для использования с использованием сетевой определяемой сетью (SDN.) Вы можете настроить многоклиентские шлюзы RAS GRE для использования с программно определяемой сетью (SDN)
System Center Virtual Machine Manager можно использовать для управления — шлюзами RAS на основе GRE Вы можете использовать System Center Virtual Machine Manager для управления шлюзами RAS на основе GRE
Можно достичь до 2,0 Гбит / с на машине с 6 ядрами, настроенной в качестве шлюза RAS GRE.Вы можете достичь пропускной способности до 2,0 Гбит / с на 6-ядерной виртуальной машине, настроенной как шлюз GRE RAS
.
Один шлюз поддерживает несколько режимов подключения. Один шлюз поддерживает несколько режимов подключения.

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

Поддержка GRE в туннельах типа «сеть — сеть» (S2S) решает проблему переадресации между виртуальными сетями клиента и внешними сетями клиента с помощью шлюза с этим клиентом, как описано далее в разделе. Поддержка GRE в туннелях между сайтами (S2S) решает проблема переадресации между виртуальными сетями клиента и внешними сетями клиента с использованием мультитенантного шлюза, как описано далее в этом разделе.

Функция туннелирования GRE предназначена для решения следующих требований: Функция туннеля GRE разработана с учетом следующих требований:

Поставщик услуг размещения должен иметь возможность создавать виртуальные сети для перенаправления без изменения конфигурации физического коммутатора. Хост-провайдер должен иметь возможность создавать виртуальные сети для пересылки без изменения конфигурации физического коммутатора.
Поставщик услуг размещения должен иметь возможность подсети к сетям, не изменяя конфигурацию мобильных коммутаторов в своей инфраструктуре.Хостинг-провайдер должен иметь возможность добавлять подсети в свои внешние сети, не изменяя конфигурацию физических коммутаторов в своей инфраструктуре.
Функция туннелирования GRE включает или расширяет несколько ключевых сценариев для поставщиков размещения, использующих технологии Майкрософт для реализации программно определяемых сетей в своих предложениях услуг. Функция туннеля GRE позволяет или улучшает несколько ключевых сценариев для поставщиков услуг хостинга, использующих технологии Microsoft для реализации программно определяемых сетей в свои предложения услуг.

Ниже приведены некоторые примеры сценариев.

Ключевые сценарии Ключевые сценарии

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

Доступ из виртуальных сетей клиента к физическим сетям клиента Доступ из виртуальных сетей арендатора к физическим сетям арендатора

Этот сценарий масштабируемый способ предоставления доступа из виртуальных сетей клиента локальной сети поставщика услуг размещения.Этот сценарий обеспечивает масштабируемый способ предоставления доступа из виртуальных сетей клиента к физическим сетям клиента, расположенным на территории поставщика услуг размещения. Конечная точка туннеля GRE установлена в многоклиентском шлюзе, другая конечная точка туннеля GRE устанавливается на устройстве стороннего производителя в физической сети. Конечная точка туннеля GRE устанавливается на многопользовательском шлюзе, другая конечная точка туннеля GRE устанавливается на стороннем устройстве на физическом сеть. Трафик 3 направляется между виртуальными машинами в виртуальной сети и уровнем стороннего производителя физической сети.Трафик уровня 3 направляется между виртуальными машинами в виртуальной сети и сторонним устройством в физической сети.

Высокая скорость подключения Высокая скорость подключения

Этот сценарий

позволяет масштабировать способ высокоскоростного подключения из локальной сети клиента в их локальной сети, в локальной сети поставщика услуг размещения. Этот сценарий обеспечивает масштабируемый способ обеспечения высокоскоростного подключения от локальной сети клиента к их виртуальной сети, расположенной в сеть хостинг-провайдеров.Клиент подключается к сети поставщика услуг с помощью многопротокольного переключения меток (MPLS), где между граничным маршрутизатором поставщика услуг размещения и многоклиентским шлюзом устанавливается туннель GRE для сети клиента. Клиент подключается к сети поставщика услуг через многопротокольную коммутацию меток (MPLS), где Туннель GRE устанавливается между граничным маршрутизатором провайдера услуг хостинга и многопользовательским шлюзом к виртуальной сети клиента.

Интеграция с изоляцией на основе VLANИнтеграция с изоляцией на основе VLAN

Этот сценарий позволяет интегрировать изоляцию на виртуальную платформу Hyper-V.Этот сценарий позволяет интегрировать изоляцию на основе VLAN с виртуализацией сети Hyper-V. Физическая сеть в сети поставщика услуг размещения содержит балансировщик нагрузки, использующий изоляцию на основе сети ЛС.Физическая сеть в сети поставщика услуг хостинга содержит балансировщик нагрузки, использующий изоляцию на основе VLAN. Многоклиентный шлюз устанавливает туннели GRE между подсистемой балансировки нагрузки в физической сети и многоклиентским шлюзом в виртуальной сети. Многопользовательский шлюз устанавливает туннели GRE между балансировщиком нагрузки в физической сети и многопользовательским шлюзом в виртуальной сети.

Между установкой и назначением можно установить несколько туннелей, а ключ GRE используется для различения туннелей. Между источником и местом назначения может быть установлено несколько туннелей, а ключ GRE используется для различения туннелей.

Доступ к общим ресурсам Доступ к общим ресурсам

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

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

Клиентские сети с непересекаемыми подсетями получают доступ к общей сети через туннель GRE.Клиентские сети с неперекрывающимися подсетями получают доступ к общей сети через туннель GRE. Один маршрут шлюза клиента между туннелями GRE приводит к маршрутизации пакетов в соответствующих клиентских сетях. Шлюз с одним клиентом маршрутизирует между туннелями GRE, таким образом маршрутизируя пакеты в соответствующие сети клиента.

В этом сценарии один шлюз клиента можно заменить аппаратными средствами сторонних производителей. В этом сценарии шлюз с одним арендатором может быть заменен аппаратными устройствами сторонних производителей.

Службы сторонних устройств для клиентов Услуги сторонних устройств для клиентов

Этот сценарий можно использовать для интеграции сторонних устройств (таких как аппаратные подсистемы балансировки нагрузки) в поток трафика сети клиента. Этот сценарий можно использовать для интеграции сторонних устройств (таких как аппаратные балансировщики нагрузки) в поток трафика виртуальной сети клиента. Например, трафик, исходящий от корпоративного сайта, проходит через туннель S2S с многоклиентским шлюзом.Например, трафик, исходящий от корпоративного сайта, проходит через туннель S2S на многопользовательский шлюз. Трафик направляется в подсистему балансировки нагрузки через туннель GRE. Трафик направляется на балансировщик нагрузки через туннель GRE. Балансировщик нагрузки направляет трафик на несколько виртуальных машин в виртуальной сети предприятия. Балансировщик нагрузки направляет трафик на несколько виртуальных машин в виртуальной сети предприятия. То же самое происходит для другого клиента с закрытого IP-адреса в виртуальных сетях.То же самое происходит с другим клиентом с потенциально перекрывающимися IP-адресами в виртуальных сетях. Сетевой трафик изолируется подсистемой балансировки нагрузки с помощью виртуальных ЛС и используемых ко всем устройствам уровня 3, поддерживающим виртуальные ЛС. Сетевой трафик изолирован на балансировщике нагрузки с помощью виртуальных локальных сетей и применим ко всем устройствам уровня 3, поддерживающим виртуальные локальные сети.

Конфигурация и развертывание Конфигурация и развертывание

Туннель GRE предоставляется в качестве дополнительного протокола в интерфейсе S2S.Туннель GRE предоставляется как дополнительный протокол в интерфейсе S2S. Он реализуется аналогично туннелю IPSec S2S, описанному в следующем блоге в сети: VPN-шлюз типа «сеть-сеть» с использованием клиентов (S2S) с Windows Server 2012 R2 Реализуется аналогично туннелю IPSec S2S, описанному в следующей сети. Блог: Многопользовательский VPN-шлюз Site-to-Site (S2S) с Windows Server 2012 R2

Пример развертывания шлюзов, включая туннельные шлюзы GRE, см. в следующем разделе: В следующем разделе приведен пример развертывания шлюзов, включая шлюзы туннелей GRE:

Развертывание инфраструктуры программно-конфигурируемой сети с помощью скриптов Развертывание программно-конфигурируемой сетевой инфраструктуры с использованием скриптов

Дополнительные сведенияПодробнее

Дополнительные сведения о развертывании шлюзов S2S см.в следующих разделах: Дополнительные сведения о развертывании шлюзов S2S см. в следующих разделах:

Ноябрь 2024
Пн	Вт	Ср	Чт	Пт	Сб	Вс
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30

Vpn gre: Сети для самых маленьких. Часть седьмая. VPN / Хабр

GRE — пример настройки и описание

Настройка VPN сервера (GRE/IPSec StrongSwan, OSPF Quagga) / Хабр

Настройка файрвола и роутинга

Настройка StrongSwan

Старый способ, использующий демон strongswan, уже достаточно хорошо описан:

Новый способ, использующий демон charon, появившийся в версии 5.2.0:

Одинаковые настройки аутентификации и шифрования для всех. Сделаем разными только PSK:

Индивидуальные настройки аутентификации и шифрования:

Поднятие туннелей с маршрутизаторами Cisco

Настраиваем GRE-туннели в CentOS

Создаем туннель на Cisco 2951

Создаем туннель на Cisco CSR1000V

Настройка динамической маршрутизации на Quagga

Настройка OSPF на CentOS

Настройка OSPF на Cisco 2951

Настройка OSPF на Cisco CSR1000V

Что осталось нерассмотренным

(MikroTikUbuntu) * GRE / IPsec / Хабр

Туннелирование GRE в Windows Server 2016

В этой статье

Ключевые сценарииKey scenarios

Доступ из виртуальных сетей клиента к физическим сетям клиентаAccess from tenant virtual networks to tenant physical networks

Высокая скорость подключенияHigh speed connectivity

Интеграция с изоляцией на основе VLANIntegration with VLAN based isolation

Доступ к общим ресурсамAccess shared resources

Службы сторонних устройств для клиентовServices of third party devices to tenants

Конфигурация и развертываниеConfiguration and deployment

Дополнительные сведенияMore information

Урок 47. Настройка GRE IPSec туннеля на Cisco

Yellow Leaf — Статьи — Объединение сетей двух офисов с помощью GRE-туннеля

Создание туннелей с помощью GRE протокола

Настройка сервера VPN (GRE / IPSec StrongSwan, OSPF Quagga) / Хабр

Настройка файрвола и роутинга

Настройка StrongSwan

Старый способ, использующий демон strongswan, уже достаточно хорошо описан:

Новый способ, использующий демон charon, появившийся в версии 5.2.0:

Одинаковые аутентификации и шифрования для всех. Сделаем разными только PSK:

Индивидуальные настройки аутентификации и шифрования:

Поднятие туннелей с маршрутизаторами Cisco

Настраиваем GRE-туннели в CentOS

Создаем туннель на Cisco 2951

Создаем туннель на Cisco CSR1000V

Настройка динамической маршрутизации на Quagga

Настройка OSPF на CentOS

Настройка OSPF на маршрутизаторе Cisco 2951

Настройка OSPF на Cisco CSR1000V

Что осталось нерассмотренным

GRE — пример и описание

(MikroTikUbuntu) * GRE / IPsec / Хабр

Туннелирование GRE в Windows Server 2016

В этой статье

Ключевые сценарии Ключевые сценарии

Доступ из виртуальных сетей клиента к физическим сетям клиента Доступ из виртуальных сетей арендатора к физическим сетям арендатора

Высокая скорость подключения Высокая скорость подключения

Интеграция с изоляцией на основе VLANИнтеграция с изоляцией на основе VLAN

Доступ к общим ресурсам Доступ к общим ресурсам

Службы сторонних устройств для клиентов Услуги сторонних устройств для клиентов

Конфигурация и развертывание Конфигурация и развертывание

Дополнительные сведенияПодробнее

Добавить комментарий Отменить ответ