LINUX.ORG.RU

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

 , , , ,


0

1

Здравствуйте. Возникла задача поднятия GRE туннеля между двумя серверами. Задача состоит в том, чтобы один из адресов, зароученных на первый сервер, «телепортировать» на второй сервер с целью защиты его от DDoS-атак на первом сервере. В интернете есть мануал, как сделать это методом ip-ip туннеля, но tun модуль не отличается производительностью, вследствие чего я решил прибегнуть к GRE. OS на обоих серверах Debian Wheezy. Это abstract, а для начала я хотел бы просто поднять gre между этими серверами без телепортирования внешних ip-адресов. Но и эта задача у меня не удалась. Итак, модуль ip_gre загружен на обеих машинах. На первой машине в /etc/network/interfaces следующее:

auto tun0
iface tun0 inet static
address 10.10.10.1
netmask 255.255.255.0
pointopoint 10.10.10.2
pre-up modprobe ip_gre
pre-up iptunnel add tun0 mode gre local $server1_ip remote $server2_ip ttl 255
up ifconfig tun0 multicast
post-down iptunnel del tun0
И соответственно на второй:
auto tun0
iface tun0 inet static
address 10.10.10.2
netmask 255.255.255.0
pointopoint 10.10.10.1
pre-up modprobe ip_gre
pre-up iptunnel add tun0 mode gre local $server2_ip remote $server1_ip ttl 255
up ifconfig tun0 multicast
post-down iptunnel del tun0
При выполнении команды ifup tun0 на первой машине ip tu появляется:
tun0: gre/ip  remote $server2_ip  local $server1_ip  ttl 255
gre0: gre/ip  remote any  local any  ttl inherit  nopmtudisc
И в ip ro:
10.10.10.2 dev tun0  proto kernel  scope link  src 10.10.10.1
С этим по аналогии и на второй машине появляются записи точно такого же вида. При выполнении ifconfig выдается информация, что tun0 интерфейс поднят:
tun0 Link encap:UNSPEC  HWaddr 1F-D6-8A-45-30-30-3A-30-00-00-00-00-00-00-00-00
inet addr:10.10.10.1  P-t-P:10.10.10.2  Mask:255.255.255.255
Но, конечно же, туннель не работает. При попытке пинга 10.10.10.1 со второй машины и 10.10.10.2 с первой машины никакие пинги не идут. До своих адресов 10.10.10.* пинги идут нормально. При этом в ifconfig tun0 появляется что-то вроде этого: На первой машине -
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:37 errors:0 dropped:0 overruns:0 carrier:0
И на второй:
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:3 dropped:0 overruns:0 carrier:3
Собственно различные ошибки, говорящие о неработающем интерфейсе. Прошу помощи разобраться в этой проблеме. Спасибо.


Ответ на: комментарий от vel

В 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

Wheely
() автор топика
Ответ на: комментарий от Wheely

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

Wheely
() автор топика
Ответ на: комментарий от vel

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

Wheely
() автор топика
Ответ на: комментарий от Wheely

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

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
Но на eth0 глухо. О чем это может говорить?

Wheely
() автор топика
Ответ на: комментарий от vel

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

Wheely
() автор топика
Ответ на: комментарий от vel

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

Wheely
() автор топика
Ответ на: комментарий от vel

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

Wheely
() автор топика
Ответ на: комментарий от Wheely

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

Wheely
() автор топика
Ответ на: комментарий от Wheely

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

Wheely
() автор топика
Ответ на: комментарий от vel

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

Wheely
() автор топика
Ответ на: комментарий от Wheely

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

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

vel ★★★★★
()
Ответ на: комментарий от vel

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

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

Wheely
() автор топика
Ответ на: комментарий от vel

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

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

Wheely
() автор топика
Ответ на: комментарий от Wheely

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

vel ★★★★★
()
Ответ на: комментарий от vel

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

Wheely
() автор топика
Ответ на: комментарий от vel

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

Wheely
() автор топика
Ответ на: комментарий от vel

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

Wheely
() автор топика
Ответ на: комментарий от vel

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

Wheely
() автор топика
Ответ на: комментарий от Wheely

включение 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

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

vel ★★★★★
()
Ответ на: комментарий от vel

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

Wheely
() автор топика
Ответ на: комментарий от vel

Маршруты на сервере А: $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

Wheely
() автор топика
Ответ на: комментарий от vel
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  * * *

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

Wheely
() автор топика
Ответ на: комментарий от Wheely

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

Wheely
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.