LINUX.ORG.RU
решено ФорумAdmin

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

 , , , ,


0

1

Здравствуйте!

Ранее в этой теме ( GRE-туннель без отключения файрволла не пингуется ) я расписывал возникшую проблему пинга между двумя хостами, соединёнными друг с другом и находящимися в одной подсети. Теперь задача изменилась. Два хоста (R-SRV на CentOS 8 и L-SRV на Debian 10) находятся в разных подсетях и соединены через промежуточный хост (ISP на CentOS 8) обычным соединением и GRE-туннелем поверх. R-SRV имеет локальный адрес 192.168.1.10/24 и 10.10.1.2/30 туннельный. Второй – L-SRV – локальный адрес 172.16.1.10/25 и 10.10.1.1/30 туннельный. Проблема та же — при отключенном firewalld на ISP (локальные адреса 192.168.1.1 и 172.16.1.1) пинг есть в обе стороны, с GRE и без него, с включённым — только в одну сторону по GRE, в обратную нет. По обычному соединению пинг так и так имеется.

https://gist.github.com/hapylestat/1a57cc7ef88357b2fad4bc470f287a7f - сайт, по которому настраивался GRE-туннель. Правила в iptables оттуда пробовал применять на ISP — не помогает. Также не помогает то решение по включению GRE сервиса из решённой темы выше.

https://i.imgur.com/VJHVH9b.png - показания nmcli на L-SRV.

https://i.imgur.com/n3XFkJN.png - показания nmcli на ISP.

https://i.imgur.com/LViPg0g.png - показания nmcli на R-SRV.

https://i.imgur.com/KdoKJIe.png - вывод iptables на L-SRV.

https://i.imgur.com/Lt9V52Q.png - данные с firewall-cmd на ISP.

https://i.imgur.com/pgV1nt1.png - данные с firewall-cmd на R-SRV.

https://i.imgur.com/bcnzg3X.png - вывод с tcpdump на ISP (включенный firewall-cmd), при пинге L-SRV от R-SRV.

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

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

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

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

Настройки выглядят верно. Ну, могу посоветовать только добавить в самое начало разрешающее правило для уже установленных соединений на 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 что кажет?

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 2)
Ответ на: комментарий от Pinkbyte

Правило не сработало. Вставлял и через 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

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

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

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

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

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

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

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

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

очень странно, что при этом работает 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 загружен.

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 6)
Ответ на: комментарий от Pinkbyte

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

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

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

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

Неа, ты всё неправильно понял. Я спрашивал как раз про ВНЕШНИЕ 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

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 3)
Ответ на: комментарий от Pinkbyte

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

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

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

Serpentary ()
Ответ на: комментарий от Pinkbyte

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

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

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

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

Serpentary ()
Ответ на: комментарий от Pinkbyte

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

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

Serpentary ()