Объединение сетей двух офисов с помощью 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.

Подписаться на обновления: RSS-лента Канал в TamTam Telegram канал Канал в ICQ

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

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 (#)

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

Anonymous 2018-04-17 10:28:09 (#)

Для филиала, локальная сеть центрального офиса, доступна через gw на интерфейсе tun0.
Должно ли что нибудь препятствовать переадресации с внешнего IP филиала (SNAT) на сервер в локальной сети центрального офиса?

MooSE 2018-04-17 17:55:53 (#)

Должно ли что нибудь препятствовать переадресации с внешнего IP филиала (SNAT) на сервер в локальной сети центрального офиса?
Вопрос не понятен:) Вам надо чтобы что-то препятствовало? Или вы спрашиваете можно ли настроить проброс портов?

Anonymous 2018-04-18 10:29:17 (#)

Нужно, чтобы ни что не препятствовало, но пока эта схема никак не работает.
Сети "центрального офиса" и "филиала" прекрасно взаимодействуют, но через проброс (DNAT) снаружи к ресурсам через туннель никак. Tcpdump с хоста за туннелем видит, что пакеты от внешнего, инициирующего подключение, хоста снаружи приходят, но в ответ ничего не отправляется, ожидаемого соединения не происходит.
Полагаю, что нужно придумать правильно таблицу роутинга для такой задачи, но опасаюсь разрушить то что работает.

MooSE 2018-04-19 14:50:53 (#)

Tcpdump с хоста за туннелем видит, что пакеты от внешнего, инициирующего подключение, хоста снаружи приходят, но в ответ ничего не отправляется, ожидаемого соединения не происходит.
Потому что та машина, на которую вы отправляете пакеты, отправляет ответы на маршрут по умолчанию.

Попробуйте на выходе из туннеля поднять NAT. Не уверен что это поможет, но всё же.

100% поможет вместо проброса портов поднимать реверс-прокси. Но я не знаю какой протокол вы пытаетесь так пробросить. Возможно он вообще не предусматривает проксирование.
Новый комментарий

Жирный текстКурсивный текстПодчёркнутый текстЗачёркнутый текстПрограммный кодСсылкаИзображение




© 2006-2024 Вадим Калинников aka MooSE
Политика конфиденциальности

www.vremena-goda.ru/banquet/anniversary/