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

()

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

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

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

  • eth0: Смотрит в интернет. В центральном офисе адрес 1.1.1.1, в филиале - 1.1.2.2;
  • eth1: Смотрит в локальную сеть офиса. В центральном офисе: 192.168.101.1/24, в филиале - 192.168.102.1/24.

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

  1. Настроить GRE-туннель;
  2. Настроить маршрутизацию;
  3. Настроить 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="eth1"
# Интерфейс 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-туннель, iptables, vpn.

Комментарии:

Anonymous 2010-12-28 10:28:43 (#)

Можете показать вывод ifconfig для интерфейса tun0?

MooSE 2010-12-28 16:06:58 (#)

Цитата:

Можете показать вывод ifconfig для интерфейса tun0?

# ifconfig tun0
tun0      Link encap:UNSPEC  HWaddr 4E-8A-94-0B-FF-FF-00-00-00-00-00-00-00-00-00-00  
          inet addr:172.17.254.2  P-t-P:172.17.254.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1476  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Anonymous 2010-12-29 01:09:20 (#)

A чем оно лучше VPN ?

MooSE 2010-12-29 03:00:12 (#)

Цитата:

A чем оно лучше VPN ?

Дурацкий вопрос. GRE фактически и есть VPN-туннель. Хотя и самый простой.

Anonymous 2010-12-29 14:53:39 (#)

А чем оно лучше OpenVPN?

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

Anonymous 2010-12-29 15:08:56 (#)

Цитата:

А чем оно лучше OpenVPN?

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


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

MooSE 2010-12-29 17:07:58 (#)

Цитата:

А чем оно лучше OpenVPN?

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


Тем что поднимается чуточку проще и быстрее. Как временное решение на коленке - более чем.

Цитата:


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


Ммм... Первый раз слышу про периодический пинг. Рекомендую почитать про GRE. Ничего никто не пингует. Вообще даже доступность второй точки не проверяется. Пакет просто шлётся и никто не проверяет приняли его там или нет. Соответственно туннель и не падает при отсутствии трафика. А вот у OpenVPN не зря есть опция "ping-restart" ;)

Anonymous 2011-02-19 13:48:56 (#)

Здравствуйте, проблема такова настроил шлюз с помощью Arno's iptables fitewall прописал gre, порт открыл, клиенты цепляются, но в локалку зайти не могут, грешу на роуты.

MooSE 2011-02-19 18:20:25 (#)

1. Никогда не пользовал Arno и не знаю что он там настраивает
2. Не распарсил фразу "прописал GRE"
3. "порт открыл" - какой порт? GRE это протокол четвёртого уровня и для него не применимо понятие портов.
4. если грешишь на роуты - ну так проверяй их:) не можешь сам - покажи что уже есть. телепатов тут нет:)

Anonymous 2016-01-05 18:32:14 (#)

> eth0: Смотрит в интернет. В центральном офисе адрес 1.1.1.1, в филиале - 1.1.2.2;
> eth1: Смотрит в локальную сеть офиса. В центральном офисе: 192.168.101.1/24, в филиале - 192.168.102.1/24
...
>В файл /etc/network/interfaces в головном офисе добавим следующие строки:
> post-up ip route add 192.168.102.0/24 dev tun0

>В филиале в этот файл нужно добавить строки:
> post-up ip route add 192.168.101.0/24 dev tun0
=====
Мне кажется, что настройках интерфейсов 192.168.101.0/24 и 192.168.102.0/24 нужно поменять местами, ведь мы перенаправляем трафик локальных сетей на туннели каждую на своих концах. А так получается, что мы в головном офисе задаём маршрут локальной сети филиала, а в филиале - марштрутизируем локалку главного офиса.

MooSE 2016-01-06 16:25:15 (#)

Нет. Всё указано правильно. Маршрут до своей локальной сети каждый филиал итак знает. А вот где искать чужую - ему надо подсказать.
Новый комментарий



© 2006-2016 Вадим Калинников aka MooSE

Брелки для ключей студия дизайна www.megasilver.ru;редуктор Ц2-250 цена;Фабрики школьной одежды тут;Фреймлайт, bd5c. Фреймлайт, 898c.