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...