Gre tunnel linux debian

GRE (Generic Routing Encapsulation — общая инкапсуляция маршрутов) — протокол туннелирования сетевых пакетов, разработанный компанией CISCO Systems. Его основное назначение — инкапсуляция пакетов сетевого уровня сетевой модели OSI в IP пакеты. Номер протокола в IP — 47.

Что такое GRE туннель?

GRE туннель представляет собой соединение точка — точка, его можно считать одной из разновидностей VPN туннеля, без шифрования. Основное достоинство GRE это возможность передавать широковещательный трафик, что позволяет пропускать через такой туннель протоколы маршрутизации использующие его, IPSec — протокол защиты сетевого трафика на IP-уровне туннели в чистом виде этого не могут. Причин для организации GRE туннеля может быть множество от банальной необходимости пробросить свою сеть через чужое IP пространство до использования протоколов OSPF, RIPv2, EGRP совместно с IPSec. Так же GRE, в отличии от IPIP, может помочь пробросить немаршрутизируюмые протоколы, такие как NetBios, IPX, AppleTalk.

Различия между туннель GRE или IPIP:

Туннелирование увеличивает нагрузку на систему и сеть, потому что добавляются дополнительные IP-заголовки. Таким образом, если обычный размер пакета (MTU) в сети равен 1500 байтам, то при пересылке по туннелю, пакет будет меньше, 1476 байт для GRE и 1480 байт для IPIP. Задать MTU можно вручную или с помощью PMTUD (path MTU discovery). Основная проблема в ручной настройке MTU и/или MSS состоит в том, что по пути между вашими площадками может оказаться линк с MTU, скажем, 1300. Тут на помощь может прийти PMTUD. Протокол целиком и полностью полагается на ICMP протокол диагностики перегрузки сети unreachable messages, которые должны быть разрешены на всем пути между соседями. Cisco рекомендует устанавливать MTU в 1400 байт вне зависимости от того работает GRE поверх IPSec в туннельном или в транспортном режиме.

Туннелирование подразумевает три протокола:

Как происходит инкапсуляции заголовка GRE в IP-пакет?

GRE-заголовок накладывается «поверх» стандартного IP-пакета. При этом в самом GRE-заголовке содержится так называемый Tunnel IP Header. Именно в нем содержится информация о tunnel source и tunnel destination.

Данные адреса вкладываются в основной пакет, когда он отправляется в публичную сеть. В поле Control Information оригинального IP-пакета содержатся исходные IP-адреса источника и назначения. Таким образом, локальные серые IP-адреса скрыты в пакете, а в маршрутизации участвуют только те адреса которые мы указали в tunnel source и tunnel destination. При передаче пакета в локальную сеть GRE-заголовок отбрасывается и остается «чистый» IP-пакет.

Настройка GRE туннелей в Debian GNU/Linux

Настройка GRE туннелей в FAQ Debian и Хостинг VPS/VDS на Ubuntu одинаковы. Имеется 2 удаленных сервера Debian 7.8 Wheezy с реальными статическими IP адресами.

То же самое только через файл /etc/network/interfaces

В файл /etc/network/interfaces это будет выгладить так

Ниже рабочий пример для ping из локальной сети

Источник

Простой Ethernet-туннель на Linux в четыре-шесть команд

Четыре команды на туннель и две на firewall (не нужны если трафик между своими серверми уже разрешен)
Это всё что нужно, дальше длинное объяснение с подробностями.

Читайте также: Snow blowing in windows

Когда требуется объединить несколько компьютеров в псевдолокальную сеть через интернет часто это решается настройкой OpenVPN.

Решение хорошо работает, но не лишено недостатков:
1. Нужно ставить дополнительный софт и его настраивать. Причем с первого раза настраивается он не очень просто — надо посидеть и поразбираться.
2. Шифрование трафика происходит в пользовательском режиме и вносит дополнительные задержки, это не всегда важно но для IP-телефонии может быть заметно.
3. Шифрование не всегда нужно. Например в моем случае все соединения и так защищенные (ssh), мне нужна просто удобная плоская адресация между несколькими компьютерами так как будто они объединены в локальную сеть.

В Linux GRE-туннели настраиваются до неприличия просто (если не нужно шифрование), из требований Linux и по публичному IP на каждый.
В интернете на эту тему информации как-то исчезающе мало — в основном объясняются IP (а не ethernet) туннели и сразу вкупе с шифрованием трафика (которое нужно не всегда). man ip тоже очень обширный и информацию по

Пусть у нас есть два хоста:
HOST1 с внешним адресом 1.2.3.4
HOST2 с внешним адресом 2.3.4.5

Хочется сделать между ними ethernet-сеть, ну и для примера поверх нее можно настроить IP-адреса 192.168.0.1 192.168.0.2, но можно и любые другие или IPv6 или что угодно еще — получится обычная сеть как через коммутатор.

Все команды выполняются от ROOT, после перезагрузки — теряются. Чтобы не терялись нужно прописать команды в скрипты автозагрузки или в конфиги (у каждого дистрибутива свои).

1. Добавить виртуальную сетевую карту-шлюз на HOST1:

На HOST1 он будет выглядеть как обычная сетевая карта — можно назначать IP-адреса, запускать DHCP-сервер, включать в Bridge и т.п.

2. Включить добавленную карту

2. Если запущен IP-tables — разрешаем GRE-трафик

3. Симметричная настройка на втором хосте:

В этот момент ethernet-сеть уже работает. Для проверки этого можно настроить приватные IP-адреса на каждой стороне туннеля и пустить пинги.

Для пингов возможно тоже придется добавить правила в iptables (или вообще выключить его на время экспериментов).

Туннель спокойно настраивается между разными версиями linux, пока писал этот пост один конец был на ubuntu, второй на centos, разницы в настройке нет абсолютно никакой.

Повторяю — это туннель не дает никакой защиты от прослушивания/внедрения трафика.

Источник

Объединение сетей двух офисов с помощью 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 хорошо описаны в одной из предыдущих статей. Нас остаётся только:

Настроить GRE-туннель;
Настроить маршрутизацию;
Настроить iptables.

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

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

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

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

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

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

Источник

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

Главная
Настройка туннелей GRE и IPIP в Debian и Ubuntu

Настройка туннелей GRE и IPIP в Debian и Ubuntu

Удаленные подключения и объединения сетей остаются в тренде последние полтора года, когда события пандемии заставили пересмотреть многие подходы к работе и вызвали повышенный интерес к различным типам VPN-соединений. Все они имеют свои достоинства и недостатки, поэтому важно выбрать наиболее подходящее из них для решения определенной задачи. Если мы говорим о соединении нескольких площадок, имеющих выделенные IP-адреса, то наибольший интерес здесь представляют GRE и IPIP туннели, как наиболее простые и производительные. Сегодня мы рассмотрим их настройку в среде Linux, в частности в Debian и Ubuntu.

Краткий ликбез для тех, кто никогда не работал с данными протоколами. Это протоколы инкапсуляции, и они очень похожи друг на друга, GRE (Generic Routing Encapsulation — общая инкапсуляция маршрутов) разработан компанией Cisco и предназначен для инкапсуляции протоколов сетевого уровня (L3) в IP-пакеты. IPIP (IP Encapsulation within IP — инкапсуляция IP в IP) — также протокол инкапсуляции, но работает только с IPv4-трафиком. GRE имеет самое широкое распространение и поддержку множеством сетевых устройств и операционных систем, IPIP наиболее прост и имеет минимальные накладные расходы.

Данные протоколы не содержат никаких механизмов аутентификации и защиты данных, поэтому в настоящее время они используются только поверх IPsec и если речь сегодня идет о GRE или IPIP-туннеле, то скорее всего имеется ввиду GRE over IPsec или IPIP over IPSec. Также ни GRE, ни IPIP не используют порты (как и используемый для шифрования полезной нагрузки протокол ESP), поэтому не могут преодолевать NAT, что требует выделенных IP-адресов для каждого узла и ограничивает соединение единственным экземпляром.

Еще одна особенность GRE и IPIP — это протоколы без сохранения состояния соединения (stateless) и понять в каком состоянии находится туннель невозможно. Можно только настроить обе стороны и проверить передачу данных между ними. Но это имеет и свои плюсы — интерфейсы всегда присутствуют в системе, что облегчает настройку маршрутизации, а также отсутствуют проблемы, связанные с необходимостью переподключения и т.п.

В дальнейших примерах мы будем использовать следующую схему, а в качестве узлов будут выступать операционные системы Debian 10 и Ubuntu 20.04:

Сначала мы рассмотрим настройку самих туннелей и только убедившись в их работоспособности перейдем к защите с помощью IPsec.

Настройка туннелей GRE и IPIP в Debian

Для работы с GRE и IPIP туннелями нам потребуется загрузить специальные модули ядра, для этого откроем файл /etc/modules и внесем в него строки:

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

В Debian, как и во многих других основанных на нем дистрибутивах для настройки сети используется ifupdown, несмотря на то что система управляется systemd. Пока что это общепринятая практика и мы будем ее придерживаться. Поэтому откроем файл настроек /etc/network/interfaces и добавим в него следующую секцию:

Где gre30 — имя интерфейса, его можно выбрать произвольно, можно даже дать осмысленное название, скажем gre-office-zavod.

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

Следующая строка указывает на то, что мы создаем туннельное соединение, опции address и netmask задают адрес внутри туннеля с нашей стороны. Обратите внимание, что мы используем сеть /30 (маска 255.255.255.252), потому что туннель — это соединение точка — точка и выделять для него сеть /24 будет расточительством, хотя ничего страшного в этом не будет, поступайте согласно собственной планировке адресного пространства сети.

Опция mode определяет тип туннеля, в нашем случае указано gre, для IPIP следует указать ipip. Внешний адрес нашей стороны туннеля содержится в опции local, endpoint — внешний адрес противоположной стороны.

Еще один важный момент — маршрутизация. С противоположного конца находится сеть 192.168.222.0/24 и нам нужно иметь туда доступ, поэтому в конце секции добавляем еще одну команду:

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

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

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

Для разрешения подключения в брандмауэре следует добавить следующие правила:

Они очень просты и в комментариях не нуждаются.

Настройка туннелей GRE и IPIP в Ubuntu

Начиная с Ubuntu 18.04 для управления сетью используется netplan. Это создает свои особенности настройки туннельного интерфейса, но все остальное остается прежним. Вам точно также потребуется предварительно подключить модули ядра, добавив в /etc/modules строки:

И перезагрузить систему, если это нежелательно, временно загрузите модули с помощью modprobe, по одной команде для каждого модуля, например:

Сетевые настройки netplan хранятся в директории /etc/netplan, в силу сложной структуры yaml-файлов с многочисленными отступами сетевую конфигурацию удобнее хранить в отдельных файлах, которые загружаются в алфавитном порядке. Поэтому создадим новый файл конфигурации:

И внесем в него следующее содержимое (не используйте для отступов табуляцию, только два или четыре пробела):

В этот раз мы настраиваем IPIP-туннель, о чем косвенно говорит его имя ipip30 (может быть любым), но тип туннеля задается параметром mode. Опции remote и local задают внешние адреса туннеля с нашей и противоположной стороны, addresses — внутренний адрес с нашей стороны туннеля. Как более современное и продвинутое решение netplan позволяет сразу указать маршрутную информацию в поле routes, где мы указали путь к сети 192.168.111.0/24 через противоположный конец туннеля.

Сохраняем файл конфигурации и генерируем сетевые параметры:

Затем применим конфигурацию в тестовом режиме:

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

Для самых смелых есть возможность применить конфигурацию без тестирования:

В брандмауэре точно также нужно разрешить подключения по протоколам GRE и IPIP:

Настроив туннель на обоих узлах убедитесь в его работоспособности, после чего можно переходить к следующему шагу — его защите.

Настройка IPsec для туннелей GRE и IPIP

Для работы с IPsec нам потребуется пакет strongSwan, установим его:

Затем откроем файл настроек /etc/ipsec.conf и добавим в него следующие две секции:

Первая секция sts-base задает общие параметры для соединений site-to-site, т.е. всех GRE и IPIP-туннелей, включая набор шифров, протокол обмена ключами (IKEv2) и режим работы (транспортный). При необходимости любой из этих параметров можно переопределить, указав непосредственно в секции соединения.

Читайте также: Provideoplayer �� mac os

Вторая секция gre30 относится к самому соединению и первой строкой загружает параметры из общей секции, а затем уже указывает собственные. Параметры подключения делятся на левые и правые, следует твердо запомнить: левые параметры относятся к локальной системе, а правые — к удаленной. Параметр left задает внешний адрес локальной для IPsec подключения, а параметр leftauth — тип аутентификации с локальной стороны, в нашем случае это psk — предварительный общий ключ. Аналогичные настройки задают внешний адрес противоположной стороны и тип аутентификации удаленной системы.

Третий параметр auto — указывает на тип запуска соединения, в нашем случае используется route, с такой настройкой strongswan производит мониторинг трафика и устанавливает защищенное соедиенение только при наличии целевого трафика между указанными узлами. Таким образом, как только появится трафик от узла left к узлу right — он будет сразу же зашифрован IPsec, а трафик от right к left соотвественно расшифрован.

Сохраним настройки и перейдем к следующему файлу /etc/ipsec.secrets в котором укажем общий ключ для наших узлов:

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

После того, как вы внесли все указанные выше изменения strongSwan следует перезапустить, в Debian используйте команду:

На другой стороне следует выполнить аналогичные настройки, только поменять местами правую и левую стороны, в нашем случае отличаются только внешние адреса узлов.

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

Вот так выглядит незащищенный IPIP — мы видим внешний IP-заголовок, внутренний IP-заголовок и полезную нагрузку (ICMP), все как на ладони:

После включения IPsec картина будет иной, доступны будут только внешние IP-заголовки, остальное содержимое будет надежно зашифровано протоколом ESP, входящим в состав IPsec:

Также следует понимать, что в данном режиме при помощи IPsec будут шифроваться все соединения между узлами, а не только туннели.

Для нормальной работы защищенного соединения потребуется внести в брандмауэр дополнительные разрешающие правила для протоколов IKE и ESP:

Указанные ранее разрешающие правила для протоколов GRE и IPIP более не нужны (так как они находятся теперь внутри IPsec) и их следует убрать.

Особенности настройки туннелей GRE и IPIP между Debian / Ubuntu и Mikrotik

Тему соединений GRE и IPIP для роутеров Mikrotik мы не так давно разбирали в отдельной статье, сегодня же поговорим об особенностях настройки туннелей где с одного конца будет Linux, а с другой RouterOS. Основная проблема кроется в том, что при использовании штатного механизма IPsec для туннельных соединений (и L2TP) политики IPsec создаются динамически, на основе политики по умолчанию и нет никакой возможности это поведение переопределить.

Отсюда следует несколько вариантов. Самый радикальный — не использовать штатные механизмы, а создать отдельное соединение IPsec для нужных узлов и уже поверх него развернуть нужный туннель. Но это требует определенных, причем достаточно глубоких знаний и опыта, в противном случае настроить и отладить такую схему будет затруднительно. Еще один вариант — изменить настройки IPsec по умолчанию, несмотря на то что это несколько проще вам все еще следует четко представлять последствия этого шага, так как изменение настроек по умолчанию может нарушить нормальную работу других служб, использующих IPsес.

Поэтому оставим описанные варианты для опытных пользователей и настроим IPsec так, чтобы была возможность работать с роутерами Mikrotik из коробки. Что нужно учесть в этом случае? Прежде всего протокол обмена ключами — по умолчанию это IKEv1. Затем шифры, их набор существенно отличается от тех, которые мы использовали в настройках выше. Чтобы ознакомиться с ними перейдем в IP — IPsec и изучим данные на закладках Proposals и Profiles:

Таким образом, если отбросить совсем старый и ненадежный 3DES, то для IKE у нас практически не останется выбора: AES-128 — SHA1 — MODP-1024/2048, для ESP выбор немного больше, но только в части алгоритмов шифрования: AES-128/192/256 — SHA1 — MODP-1024. Кроме того, следует учитывать, что многие роутеры Mikrotik имеют достаточно слабый процессор и не поддерживают аппаратное шифрование, поэтому выбор сильных алгоритмов способен привести к высокой нагрузке на CPU и низкой производительности соединения. В большинстве случаев AES-128 будет вполне достаточно.

Вернемся на Linux сервер и добавим в /etc/ipsec.conf секцию для работы с Mikrotik:

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

Каких-либо особенностей создания туннельного соединения со стороны Linux-сервера нет, а вот при создании туннеля в RouterOS следует убрать опцию Keepalive, в противном случае Mikrotik не будет считать соединение активным пока не получит пакет с противоположной стороны туннеля.

В терминале команда будет следующей для GRE:

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

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Источник

Gre tunnel linux debian

Настройка GRE туннелей в Debian Ubuntu FreeBSD Mikrotik