nokogerra Опубликовано 17 марта, 2015 (изменено) Доброго времени суток. debian 7.8 3 машины, (194.135.107.161, 194.135.107.162, 194.135.107.163), между ними построены gre-туннели от каждой к каждой, т.е. по 2 gre интерфейса на каждой. На примере 194.135.107.163: # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 allow-hotplug eth0 iface eth0 inet static address 194.135.107.163 netmask 255.255.255.0 network 194.135.107.0 broadcast 194.135.107.255 gateway 194.135.107.238 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 194.135.107.1 auto gre1 iface gre1 inet static address 10.0.2.3 netmask 255.255.255.248 pre-up ip tunnel add gre1 mode gre local 194.135.107.163 remote 194.135.107.161 post-down ip tunnel del gre1 up route add -host 10.0.2.1 dev gre1 up route del -net 10.0.2.0/29 dev gre1 auto gre2 iface gre2 inet static address 10.0.2.3 netmask 255.255.255.248 pre-up ip tunnel add gre2 mode gre local 194.135.107.163 remote 194.135.107.162 post-down ip tunnel del gre2 up route add -host 10.0.2.2 dev gre2 up route del -net 10.0.2.0/29 dev gre2 Как видно, адрес одинаковый (10.0.2.3), чтобы это работало, удаляю "connect" маршруты и добавляю индивидуальные. На остальных машинах также. Работает нормально. НО при создании правил netfilter получаю проблему: если правило iptables -A INPUT -m conntrack --ctstate INVALID -j DROP поставить до правила iptables -A INPUT -i eth0 -p gre -j ACCEPT то трафик дропается, хотя дальше стоит правило: iptables -A INPUT -i gre1 -j ACCEPT Если правило с определением состояния INVALID вставить после правила с разрешением gre, то работает нормально. При построении туннеля 1 к 1 такой проблемы нет. Если это поможет - то вот tcpdump с машины 194.135.107.163 при попытке пинговать 10.0.2.1 при том, что правило с определением состояния на первом месте: http://pastebin.com/nfg1P4jH Мне желательно сохранить одинаковые адреса на gre интерфейсах одной и той же машины (проблема скорее всего в этом). Изменено 17 марта, 2015 пользователем nokogerra Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MMM Опубликовано 17 марта, 2015 modprobe nf_nat_proto_gre делали? или же у вас нет nat ? UPD. Ой, не тот модуль, имелся в виду nf_conntrack_proto_gre Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nokogerra Опубликовано 17 марта, 2015 Добрый день. Спасибо за ответ. Не совсем понял, что за nf_conntrack_proto_gre, судя по результатами гугла это для ситуации с nat. В моем случае nat нет, интерфейсы 194.135.107.161, *162, *163 в одной подсети, политики netfilter: INPUT, FORWARD - DROP, OUTPUT - ACCEPT. Для ситуации туннель 1 к 1 достаточно правила iptables -A INPUT -i eth0 -p gre -j ACCEPT. Его, собственно, достаточно и в моем случае, но соединения почему-то попадают под правило с определением состояния INVALID. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nokogerra Опубликовано 17 марта, 2015 Тема закрыта. Объяснили что такая схема нормально работать не будет, даже если эту конкретную проблему удастся побороть, в итоге высока вероятность получить множество других. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MMM Опубликовано 17 марта, 2015 nf_conntrack_proto_gre нужен для определения ctstate . Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...