GRE-туннель через промежуточный хост не работает с включенным файрволлом

показывай

1) iptables -vn -L FORWARD с ISP
2) iptables -vn -L INPUT с L-SRV

https://i.imgur.com/Jehu83k.png — ISP

https://i.imgur.com/ReTB58i.png — L-SRV

Если L-SRV не находится за virbr0 на ISP, то ничего криминального не вижу.

Дай еще выхлопы ip tunnel с L-SRV и R-SRV

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

https://i.imgur.com/ofaY2nj.png

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

iptables -I FORWARD 1 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Хотя сам отлуп приходит с L-SRV и почему-то направлен на ISP(как будто это другой конец туннеля, а не R-SRV).

У тебя там нигде NAT на ISP не делается?

iptables -t nat -vn -L

с ISP что кажет?

Правило не сработало. Вставлял и через firewall-cmd –direct, и через /etc/sysconfig/iptables, для того чтобы правило находилось выше всяких REJECT.

NAT делается через firewall-cmd, если речь о маскараднике. Задал маскарадник между R-SRV и L-SRV, и просто включённым оставил. На скрине выше с firewall-cmd на ISP это отображено.

В ip route конфликтов нет.

https://i.imgur.com/5TXqm7z.png

Задал маскарадник между R-SRV и L-SRV, и просто включённым оставил

Ну так естественно оно работать НЕ будет. Убирай NAT между L-SRV и R-SRV и убедись что он действительно убран(с помощью tcpdump)

Снёс ISP после того, как сделал yum update (после обновы перестал работать пинг через туннель даже с отключенным firewall-cmd).

Поставил заново и перенастроил до рабочего состояния. Маскарадники не ставил. Ситуация снова такая, какая была описана в шапке темы.

К слову, очень странно, что при этом работает openvpn от R-SRV через ISP до левой хостовой машины в другой сети (в примере не приводилась, потому что не связана с проблемой). И это при том, что для пропуска трафика через ISP в firewall-cmd должен быть включён только общий маскарадник.

очень странно, что при этом работает openvpn от R-SRV через ISP до левой хостовой машины в другой сети

Потому что openvpn - это клиент-серверный протокол, подразумевающий возможность смены IP-адреса клиентом(опция float). В большинстве конфигураций там имеет значение только адрес сервера.

GRE - это двусторонний туннельный протокол со статическими адресами туннеля. Там имеет значение адрес КАЖДОЙ стороны туннеля. Если один конец GRE-туннеля находится за NAT-ом сразу всплывает куча неприятных ограничений, которых лучше избегать. TL;DR - если можно убрать NAT между точками, объединенными GRE-туннелем, его лучше убрать.

По теме:
1) пусти пинг;
2) на ISP на интерфейсе в сторону источника ping-а сделай tcpdump;
3) на ISP на интерфейсе в сторону назначения ping-а сделай tcpdump;

Сравни IP-адреса пакетов(снаружи туннеля, не внутри) в обоих случаях. Они НЕ должны меняться при прохождении через ISP.

На всех машинах, где включен файрвол, убедись в том, что модуль ядра nf_conntrack_proto_gre загружен.

Пинг исправно переходил от интерфейса к интерфейсу, не меняя ip-адреса туннелей (10.10.1.1 -> 10.10.1.2). Но только до конечной остановки. На скрине видно, что обратно не хочет добираться.

На R-SRV и ISP модуль этот есть. На L-SRV (Debian) модуль отсутствует. Но там из заградительных служб только отключенный selinux, статичные списки в iptables и работающий apparmor.

https://i.imgur.com/hRp7m4P.png

Неа, ты всё неправильно понял. Я спрашивал как раз про ВНЕШНИЕ IP, а не те, что внутри туннеля.

На ISP должны быть пакеты от L-SRV к R-SRV, а там у тебя не так. Там от ISP к R-SRV(и ответные отлупы).

Значит пакет с туннельным адресом 10.10.1.1 и ВНЕШНИМ адресом L-SRV НАТИТСЯ в адрес ISP на самом ISP.

Если нат у тебя не симметричный, то обратные пакеты по коннтраку могут идти в обход NAT и, таки да, пинг в одну сторону будет, а в другую - нет.

Показывай еще раз текущие правила для NAT-а на ISP:

iptables -t nat -vn -L

Эм… У меня по факту локалка. Внешние, которые смотрят в интернет, я вырубил, потому что они конфликтуют с внутренними днсками. Врубаю выход в интернет нечасто, когда требуется установить или обновить пакеты.

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

https://i.imgur.com/f5oYAAS.png

Хм, странно, никаких правил NAT-а, под которые могут подпадать GRE-пакеты с l-srv нет.

Других идей у меня больше нет

Опишу свои попытки.

В firewall-cmd вставлял в источник и назначение разные адреса, в том числе 0.0.0.0/0 с диапазоном портов 1-65000. Разрешал tcp, udp, gre, адреса с маскарадниками и без. Форвардинги портов разрешал. С разных ресурсов вставлял правила из iptables через –direct. И ничего не помогло.

Печально конечно, что разобраться не получилось. Даже узнать по логам не получилось, по какому признаку firewall-cmd обратный ответ блокирует.

Если мне таки удастся найти решение проблемы — напишу в тему и отмечу как решённую.

Проблема решена. Пропуску трафика мешала зона public, которая установлена в firewall-cmd по умолчанию. Видимо, в строке target предустановка default (firewall-cmd –list-all) имеет приоритет над записанными поверх неё правилами, иначе я не могу найти другого объяснения, почему новые разрешающие правила посылались лесом.

Поменял на зону trusted с предустановкой ACCEPT и трафик по GRE пошёл. В описании к зоне сказано, что он разрешает вообще любой трафик. Но и это даже лучше, чем иметь отключенный файрволл, потому что ничто не мешает дописать правила на дроп левого трафика.