Не работает GRE туннель

а в iptables пусто ?

«ip ro get» & tcpdump в помощь.

В iptables нет никаких записей, запрещающих общение серверов. ping 10.10.10.1 со второй машины, tcpdump -i tun0 на первой машине молчит. На первой машине:

ip ro get 10.10.10.2 from 10.10.10.1
10.10.10.2 from 10.10.10.1 dev tun0
cache  expires 154sec mtu 8976

ip ro get 10.10.10.1 from 10.10.10.2
10.10.10.1 from 10.10.10.2 dev tun0
cache  ipid 0x9a4a

tcpdump -i eth0 src $server2_ip на первой машине во время ping 10.10.10.1 со второй машины также молчит, и да, молчок и там и там.

про 10.10.10.0/24 это второй момент. а gre между серверами не запрещено ?

DROP в iptables дает ошибки tx/droped

Как это можно проверить?

В iptables на втором сервере вообще пусто. (там показывает ошибки)

«iptables -t raw -A OUTPUT -p gre -j TRACE»

«tcpdump -ni eth0 proto gre» на втором сервере что показывает при попытке сделать пинг на 10.10.10.1?

Впилил правило в фаервол на обоих серверах, попробовал пинг и телнет, и там и там в логах пусто.

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

ip tu add .... dev XXX

Ничего не показывает.

Удалил старую запись, сделал с dev, перезапустил tun0, по прежнему tcpdump на eth0 gre не видит.

Гм, а вот на первом сервере gre на eth0 пошел.

На втором сервере пошло вот что:

tcpdump -ni tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
18:54:38.752247 IP 10.10.10.2 > 10.10.10.1: ICMP echo request, id 23240, seq 8, length 64
18:54:39.752246 IP 10.10.10.2 > 10.10.10.1: ICMP echo request, id 23240, seq 9, length 64
18:54:40.752246 IP 10.10.10.2 > 10.10.10.1: ICMP echo request, id 23240, seq 10, length 64

на втором входящие gre появились ?

Сервера далеко друг от друга ?

что на втором сервере говорит «ip ro get ip_server1» ?

Нет, на втором сервере на eth0 ни вход., ни исход. GRE не проходит. Сервера далеко, первый в Германии, второй в России.

ip ro get ip_server1 ip_server1 via 192.168.0.1 dev eth0 src 192.168.0.24 cache

Уверен, что по пути gre не отрезан ? Я сталкивался (правда давно) что по пути оно было зарезано.

Конечно не уверен. Но странно то что исходящий GRE на внешнем интерфейсе сервера 2 также не виден. Я не уверен, что gre не зарезан, но мне кажется, что проблема в другом.

Перед сервером 2 стоит какой-то роутер zyxel (что можно видеть исходя из серого ip адреса), но я надеюсь что он не будет рубить gre.

Ура! Заработало! :) Последним штрихом было то, что local ip-address туннеля на сервере 2 был внешним, а ip на eth0 был серым - внутренним, как я сказал, белым его уже делал роутер. Сменил local address на 192.168.0.24 и все заработало.

Я извиняюсь но у меня возник еще один вопрос, не хотелось бы новый тред создавать. Я настроил Gre туннель и закинул один из внешних ip-адресов сервера 1 на сервер 2, для чего понадобилось включить ip forward и proxy arp на сервере 1. Но теперь после включения proxy_arp на все интерфейсы сервера 1 льется непонятного вида трафик, для моих IP совсем не предназначающегося. С выключением proxy arp трафик литься перестает. Как можно его зафильтровать, чтоб он ко мне не проходил? Ладно бы 5 мбс, но буквально в течении часа после того , как я включил прокси арп, оно поступало ко мне уже со скоростью 15 мб/с на все интерфейсы!

С ip_forwarding оно понятно. А нафига было включать proxy_arp ? Где ты об этом прочитал ?

IMHO оно нужно только в достаточно экзотических вариантах, когда адрес интерфейса тунеля берется из диапазона физической сети (и тогда нужен GRE_BROADCAST).

Где ты об этом прочитал

Прочитал тут: https://debian.pro/1578 И да, там написана правда - без прокси арп проксирование адреса не работает как надо, на eth0 интерфейс сервера 1 приходит лишь who has от роутера и пакеты не проходят на сервер 2.

IMHO оно нужно только в достаточно экзотических вариантах

А это разве не экзотический вариант? Как часто тебе возникает необходимость пробросить один из ип сервера 1 на сервер 2 через туннель (gre / ip-ip), с целью очистки трафика? И да, несмотря на «экзотичность» решения, я не думаю что придется мириться с дерьмом которое льется на интерфейсы вследствии включенного proxy_arp. Наверняка решение есть.

для одного хоста я бы ограничился «arp -sD xxx.xxx.xxx.xxx eth0 pub» и без proxy_arp. proxy_arp необходим когда нужно много адресов пробрасывать.

Добавляю arp -sD [ipv4 адрес, который хочу пробросить через туннель на 2 сервер] eth0 pub на первом сервере. Этот ipv4 адрес действительно захватывается, тисипидамп выдает син-пакеты на этот адрес заместо whohas'ов, но адрес все равно не проксируется на сервер 2.

а с той стороны куда ответы идут на эти syn? IMHO мимо тунеля.

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

Смотри как я вижу картину. Команда proxy_arp проксировала arp-запрос на сервер-приемник, у которого проксируемый адрес имел gre-туннель как внешний адрес, и сервер-приемник подхватывал эти запросы, и таким образом получал этот адрес. Добавление же этого единственного адреса командой arp заставляет arp-запросы подхватывать сервер-донор, и получается что проксируемый адрес «принадлежит» ему, но его не имеет ни один интерфейс в качестве наружного адреса, вследствии чего пакеты и не доходят на сервер - приемник.

Господин, ваше решение кажется помогло. не знаю почему не сразу заработало, но после пляски с бубном вокруг arp cache кажется все ОК. Спасибо.

включение proxy_arp избавляет от необходимости выполнять «arp -s» для всех «левых» адресов подсети. Все остально работает как на обычном маршрутизаторе. Про маршрутизацию забывать нельзя.

Возможно нужно подкутить rp_filter и может быть arp_filter/arp_accept.

трюк с arp -sD я использовал не один раз. Сейчас проверил на контейнере - все работает без proxy_arp.

eth0(10.0.0.253/24) <-> Система <-> veth(10.0.255.1/24)-veth(10.0.0.255.2/24) <-> контейнер <-> dummy0(10.0.0.66)

Единственное, что нужно было сделать в контейнере - добавить маршрут в сеть 10.0.0.0/24 через veth

root@lve-wifi:~# traceroute -ns 10.0.0.251 10.0.0.66
traceroute to 10.0.0.66 (10.0.0.66) from 10.0.0.251, 30 hops max, 38 byte packets
 1  10.0.0.253  0.246 ms  0.216 ms  0.242 ms
 2  10.0.0.66  0.239 ms  0.231 ms  0.293 ms

с другой стороны

root@lve-m1:~# traceroute -ns 10.0.0.66 10.0.0.251
traceroute to 10.0.0.251 (10.0.0.251), 30 hops max, 60 byte packets
 1  10.0.255.1  0.056 ms  0.037 ms  0.045 ms
 2  10.0.0.251  0.880 ms  0.883 ms  0.989 ms

Тип интерфейса между системами значения не имеет.

Черт. Оно похоже опять сломалось. rp_filter =0, arp_filter = 1, arp_accept = 0 на обоих тазиках. Пробовал всячески изменять параметры, не помогло. На сервер А syn пакеты на проксируемый IP приходят в нормальном виде, а не в arp. Почему они не проходят на сервер Б?

Маршруты на сервере А: $ip_to_proxy dev tun0 proto kernel scope link src 10.10.10.1 На сервере Б: 10.10.10.1 dev tun0 proto kernel scope link src $ip_to_proxy

traceroute -n проксируемый ип
traceroute to проксируемый ип (проксируемый ип), 30 hops max, 60 byte packets
 1  192.168.0.1  0.640 ms  0.687 ms  1.406 ms
 2  172.16.0.10  5.337 ms  5.333 ms  5.331 ms
 3  91.217.5.129  5.302 ms  5.366 ms  5.344 ms
 4  93.183.198.73  22.645 ms  22.619 ms  22.597 ms
 5  80.91.160.158  47.424 ms  47.556 ms  47.558 ms
 6  80.81.194.128  44.343 ms  45.311 ms  44.952 ms
 7  $server1_ip  44.442 ms  42.327 ms  42.380 ms
 8  * * *

Как видим запросы к проксируемому на сервер Б ипу таки проходят через сервер А удачно. Может ли это говорить, что сервер А в порядке и стоит искать проблему на сервере Б?

решилось добавлением arp -sD ... и на сервере Б.