Linux gre tunnel key

How to create a GRE tunnel on Linux

Question: I want to connect to remote networks by using a GRE tunnel. How can I create a GRE tunnel between two end points on Linux?

GRE tunnels are IP-over-IP tunnels which can encapsulate IPv4/IPv6 and unicast/multicast traffic. To create a GRE tunnel on Linux, you need ip_gre kernel module, which is GRE over IPv4 tunneling driver.

So first make sure that ip_gre is loaded.

$ sudo modprobe ip_gre $ lsmod | grep gre

ip_gre 22432 0 gre 12989 1 ip_gre

Here, we assume that you want to create a GRE tunnel between two interfaces with the following IP addresses.

On host A, run the following command.

$ sudo ip tunnel add gre0 mode gre remote 172.168.10.25 local 192.168.233.204 ttl 255 $ sudo ip link set gre0 up $ sudo ip addr add 10.10.10.1/24 dev gre0

In the above, we create a GRE-type tunnel device called gre0 , and set its remote address to 172.168.10.25 . Tunneling packets will be originating from 192.168.233.204 (local IP address), and their TTL field will be set to 255 . The tunnel device is assigned IP address 10.10.10.1 with netmask 255.255.255.0 .

Now verify that route for the GRE tunnel is set up correctly:

default via 135.112.29.1 dev eth0 proto static 10.10.10.0/24 dev gre0 proto kernel scope link src 10.10.10.1

On host B, run similar commands as follows.

$ sudo ip tunnel add gre0 mode gre remote 192.168.233.204 local 172.168.10.25 ttl 255 $ sudo ip link set gre0 up $ sudo ip addr add 10.10.10.2/24 dev gre0

At this point, a GRE tunnel should be established between host A and host B.To verify that, from one tunneling end point, ping the other end point.

PING 10.10.10.2 (10.10.10.2) 56(84) bytes of data. 64 bytes from 10.10.10.2: icmp_req=1 ttl=64 time=0.619 ms 64 bytes from 10.10.10.2: icmp_req=2 ttl=64 time=0.496 ms 64 bytes from 10.10.10.2: icmp_req=3 ttl=64 time=0.587 ms

If you want to tear down the existing GRE tunnel, run the following command from either end.

$ sudo ip link set gre0 down $ sudo ip tunnel del gre0

Support Xmodulo

This website is made possible by minimal ads and your gracious donation via PayPal or credit card

Please note that this article is published by Xmodulo.com under a Creative Commons Attribution-ShareAlike 3.0 Unported License. If you would like to use the whole or any part of this article, you need to cite this web page at Xmodulo.com as the original source.

Источник

Настройка Linux для туннеля GRE

Если вы видите что-то еще, возможно, ваше ядро не поддерживает GRE.
Для пересылки всего трафика в туннель GRE и из него мы будем использовать iptables и iproute2, которые уже должны быть установлены во всех основных дистрибутивах Linux. Если они не установлены, используйте следующую команду
для дистрибутивов на основе Debian:

sudo apt install iptables iproute2

sudo yum install iptables iproute2

Шаг 2 — Настройка туннеля

Сначала мы должны настроить наш туннель.
На сервере A выполните этот код, чтобы включить пересылку ip:

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

sudo ip tunnel add gre1 mode gre local 198.51.100.1 remote 203.0.113.1 ttl 255 sudo ip addr add 10.0.0.1/30 dev gre1 sudo ip link set gre1 up

sudo ip tunnel add gre1 mode gre local 203.0.113.1 remote 198.51.100.1 ttl 255 sudo ip addr add 10.0.0.2/30 dev gre1 sudo ip link set gre1 up

Шаг 2.1 — Тест Ping

Шаг 3 — Добавить новые маршруты

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

sudo echo '100 GRE' >> /etc/iproute2/rt_tables sudo ip rule add from 10.0.0.0/30 table GRE sudo ip route add default via 10.0.0.1 table GRE

Шаг 4 — Настройте NAT

iptables -t nat -A POSTROUTING -s 10.0.0.0/30 ! -o gre+ -j SNAT --to-source 198.51.100.1

Чтобы проверить исходящее соединение, выполните на сервере B следующие команды:
для дистрибутивов на основе Debian:

curl http://www.cpanel.net/showip.cgi --interface 10.0.0.2

Шаг 5 — Порты пересылки

На сервере A выполните следующие команды, чтобы разрешить все данные, поступающие на сервер B и поступающие с него:

sudo iptables -A FORWARD -d 10.0.0.2 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT sudo iptables -A FORWARD -s 10.0.0.2 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

sudo iptables -t nat -A PREROUTING -d 198.51.100.1 -p PROTO -m PROTO --dport PORT -j DNAT --to-destination 10.0.0.2

замена PROTO и PORT вашими фактическими.
Например, чтобы переслать все данные на веб-сервер (порт TCP 80), нам нужно выполнить:

sudo iptables -t nat -A PREROUTING -d 198.51.100.1 -p TCP -m TCP --dport 80 -j DNAT --to-destination 10.0.0.2

Шаг 6 — Сделай постоянным

На сервере перезагрузите все, что мы сделали, будут уничтожены. Чтобы убедиться, что туннель GRE и все остальное будет работать после перезапуска, мы должны отредактировать файл /etc/rc.local и добавить все команды, которые мы сделали (кроме эхо!) Перед exit 0 .

Заключение

Теперь, если мы подключаемся к серверу A, используя настроенные порты (например, порт TCP 80), мы вместо этого собираемся подключиться к серверу B, не зная об этом.
Примечание: если вы используете CSF для управления iptables, вам, возможно, придется поместить все команды iptables в свой /etc/csf/csfpost.sh и вставить IP-адрес обоих серверов (также GRE) в свой /etc/csf/csf.allow

Источник

Создание point-to-multipoint тоннелей на базе инкапсуляции GRE в Linux 2.6

В ОС Linux встроена поддержка двух типов тоннелей: ipip и gre. В том виде, в котором тоннели традиционно используются в системе, без разницы, какой из них использовать: они оба дают в точности одинаковые накладные расходы к пакетам, посылаемым в тоннель IPv4-in-IPv4 (специально проверял), одинаково защищаются средствами IPsec и занимают одинаковое процессорное время для обработки. Однако, это разные типы тоннелей, и возможности gre значительно более широкие.
К сожалению, нигде в интернете не описывается очень удобная и замечательная особенность gre-тоннелей, и большинство (если не все) администраторов Linux не знают о такой возможности, как mGRE-тоннели. К счастью, мы намереваемся восполнить этот недостаток 🙂

Итак, имеем три машины, все три имеют запущенный Linux версии 2.6 (я не уверен, возможно, и 2.4 тоже поддерживает). Также нам потребуется пакет iproute2 — это стандарт для современных Linux-систем (кстати, давно уже пора забыть про морально устаревшие утилиты ifconfig, route и прочие). Внешние ip-адреса систем: 1.1.1.1, 2.2.2.2 и 3.3.3.3; между ними есть маршрутизация.

Обойдёмся пока без шифрования и аутеникации пакетов — это всё несложно к нашему примеру добавить, «просто» настроив IPsec между нашими хостами в транспортном режиме. Это тема за рамками темы 😉

1. Создаём GRE-тоннель:
(на всех трёх)

ip tunnel add mgre0 mode gre key 0xfffffffe ttl 255

Заметьте, мы не указали здесь адрес пира. Это значит, что в принципе он может быть расположен по любому адресу. key в данном случае идентифицирует конкретную mGRE-сеть — это 32-битное число, одинаковое для всех нод.

2. Назначаем ему адрес:
(на 1.1.1.1)

ip addr add 10.0.0.1/24 dev mgre0

ip addr add 10.0.0.2/24 dev mgre0

ip addr add 10.0.0.3/24 dev mgre0

Для интерфейсов Ethernet этого было бы достаточно. В Ethernet есть Adress Resolution Protocol (ARP), который позволяет системам самостоятельно найти MAC-адрес, зная IP-адрес хоста назначения. Ethernet является средой Broadcast Multiple Access, и протокол ARP заключается в создании запроса ко всем станциям сети (по MAC-адресу FF:FF:FF:FF:FF:FF): «Эй, кто из вас имеет IP-адрес x.x.x.x?». Если станция с таким IP-адресом имеется, она уже в приватном порядке сообщает, что «x.x.x.x расположен по адресу yy:yy:yy:yy:yy:yy».

В нашей сети (Internet) нет такого средства, как ARP, а роль адресов «второго уровня», которые в случае Ethernet — MAC-адреса, здесь исполняют… внешние IP-адреса систем. Мы работаем со средой Non-Broadcast Multiple Access (NBMA), мы не можем крикнуть на весь интернет, как сделал бы ARP: «Эй, кто в GRE-сети 0xfffffffe имеет адрес 10.0.0.2?».

Для разрешения этой проблемы адресов предназначен протокол Next Hop Resolution Protocol (NHRP, аналог ARP для NBMA-сред), но мы на на первый раз сделаем работу за него — заодно разберёмся, как вообще сеть в Linux работает 🙂

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

ip neigh add 10.0.0.2 lladdr 2.2.2.2 dev mgre0 ip neigh add 10.0.0.3 lladdr 3.3.3.3 dev mgre0

ip neigh add 10.0.0.1 lladdr 1.1.1.1 dev mgre0 ip neigh add 10.0.0.3 lladdr 3.3.3.3 dev mgre0

ip neigh add 10.0.0.1 lladdr 1.1.1.1 dev mgre0 ip neigh add 10.0.0.2 lladdr 2.2.2.2 dev mgre0

Здесь каждая команда говорит: «соседняя станция с адресом сетевого уровня IP x.x.x.x имеет физический адрес (link layer address, lladdr) y.y.y.y, который доступен через устройство M». Если бы мы настраивали статический Ethernet (без ARP), вместо y.y.y.y стоял бы MAC-адрес соответствующей станции. (Кстати, если посмотреть ip neigh show dev ethN в работающей Ethernet-сети, мы увидим результаты работы ARP — динамически полученные адреса соседей).

Всё. На этом наш тоннель заработает: каждая из станций сможет пинговать любую другую. Если ядро собрано с поддержкой GRE multicast, то мы вообще получаем полнофункциональную «локалку» — в нашей вирутальной сети будут работать в полную силу протоколы динамической маршрутиации, типа RIP и OSPF!

Вот так это выглядит со второй станции (2.2.2.2):

linux2 # ping 10.0.0.1 PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data. 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=4.41 ms 64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.429 ms ^C --- 10.0.0.1 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1013ms rtt min/avg/max/mdev = 0.429/2.419/4.410/1.991 ms linux2 # ping 10.0.0.2 PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. 64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.027 ms 64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.020 ms ^C --- 10.0.0.2 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 0.020/0.023/0.027/0.006 ms linux2 # ping 10.0.0.3 PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data. 64 bytes from 10.0.0.3: icmp_seq=1 ttl=64 time=8.47 ms 64 bytes from 10.0.0.3: icmp_seq=2 ttl=64 time=0.164 ms ^C --- 10.0.0.3 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1018ms rtt min/avg/max/mdev = 0.164/4.318/8.472/4.154 ms linux2 # ip addr show dev mgre0 5: mgre0@NONE: mtu 1472 qdisc noqueue link/gre 0.0.0.0 brd 0.0.0.0 inet 10.0.0.2/24 brd 10.0.0.255 scope global mgre0 linux2 # ip neigh show dev mgre0 10.0.0.1 lladdr 1.1.1.1 PERMANENT 10.0.0.3 lladdr 3.3.3.3 PERMANENT

Конечно, если станций много, такой подход не годится — не прописывать же на каждой станции всех соседей! Но вполне понятно, как решать этй проблему. Но об этом как-нибудь потом.

Источник