PREROUTING для туннеля GRE

0

1

Доброго времени!

Есть два сервера с белыми ИП между ними натянут туннель GRE. На стороне моего сервера выглядит это примерно вот так:

3: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN group default qlen 1000
    link/gre 0.0.0.0 brd 0.0.0.0
4: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
5: erspan0@NONE: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
12: qrtun@eth0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue state UNKNOWN group default qlen 1000
    link/gre 192.168.3.5 peer 185.x.x.x
    inet 172.16.0.111 peer 172.16.0.110/32 scope global qrtun
       valid_lft forever preferred_lft forever
    inet6 fe80::5efe:a0a:1705/64 scope link

Туннель поднимается, я пингую ту сторону 172.16.0.110. Из туннеля мне пробрасывают 80 и 443 порты. Это видно если запустить тспдумп на туннелевском интерфейсе qrtun. Если на моем сервере запустить веб-сервер, скажем нжинкс, то пакеты великолепно приземляются и нжинкс отдает трафик. Чтобы отдача в туннель работала сделана дополнительная таблица маршрутов gre и правила в ней:

# ip route show table gre
default dev qrtun scope link

# ip rule
0:      from all lookup local 
...
214:    from 172.16.0.111 to 192.168.23.0/24 lookup main  
215:    from 172.16.0.111 lookup gre 
220:    from all lookup 220 
32766:  from all lookup main 
32767:  from all lookup default

В реальности, мне нужно пробросить трафик по портам 80 и 443 далее - на сервер во внутренней сети 192.168.23.10. Без туннеля гре если пакеты приходят на внешний интерфейс машины, то через правило iptables -t nat -A PREROUTING -p tcp –dport 80 -j DNAT –to-destination 192.168.23.10:80. Но если пакеты приходят через туннель, то пакеты внутрь серой сети не пробрасываются. Можно сделать индивидуальное правило под гре-интерфейс: iptables -t nat -A PREROUTING -p tcp -i qrtun –dport 80 -j DNAT –to-destination 192.168.23.10:80

Добавлял правило:

213: from all to 192.168.23.0/24 iif qrtun lookup main

роли это не играет - все равно не воркает.

Прошу знающих коллег помочь победить проблему.

Ссылка

←	Не виден порт снаружи ubuntu

ProtonVPN WireGuard NetworkManager не работает

→

Отдельными правилами для пакетов проблему не решить. -m connmark/-j CONNMARK/-j MARK в помощь.

Эта ситуация многократно обсуждалась в виде вопроса как обеспечить доступ к одному серверу через разные каналы.

Правило 214 нужно заменить на

from all lookup main suppress_prefixlength 0

Трафик сервера 192.168.23.10 должен обязательно проходить через роутер в обе стороны, т.е. не должно быть асимметричной машрутизации.

vel ★★★★★
(13.11.22 21:44:04 MSK)

Ответ на: комментарий от vel 13.11.22 21:44:04 MSK

Спасибо за ответ.

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

У меня же проблема чуть в другой плоскости - не пойму почему трафик не бросается в подсеть 192.168.23.0/24 посредством PREROUTING’a.

На интерфейс qrtun пакеты точно приходят:

03:49:25.772666 IP 109.x.x.12.41646 > 172.16.0.111.80: Flags [S], seq 3275486611, win 29200.......
03:49:26.790981 IP 109.x.x.12.41646 > 172.16.0.111.80: Flags [S], seq 3275486611, win 29200........
03:49:28.838944 IP 109.x.x.12.41646 > 172.16.0.111.80: Flags [S], seq 3275486611, win 29200.......
.....

alex-123 ★
(13.11.22 22:24:03 MSK) автор топика

Ссылка

Ответ на: комментарий от vel 13.11.22 21:44:04 MSK

Правило 214 заменил на

from all lookup main suppress_prefixlength 0

Ожидаемо перестал пинговаться ип-ник 172.16.0.111 из подсети 192.168.23.0/24 (проверяю с 192.168.23.10)

alex-123 ★
(13.11.22 22:51:28 MSK) автор топика

Ответ на: комментарий от alex-123 13.11.22 22:51:28 MSK

Здесь мне тоже придется возвращать меченный трафик в туннель и я примерно понимаю как.

Именно так. Ты правильно догадался про

iptables -t nat -A PREROUTING -p tcp -i qrtun –dport 80 -j DNAT –to-destination 192.168.23.10:80

потому, что правило «iptables -t nat -A PREROUTING -p tcp –dport 80 -j DNAT –to-destination 192.168.23.10:80» будет применятся к любым пакетам, что может приводить к казусам.

Ожидаемо перестал пинговаться ип-ник 172.16.0.111 из подсети 192.168.23.0/24

Это совсем не ожидаемый результат т.к.

from 172.16.0.111 to 192.168.23.0/24 main

это частный случай

from all lookup main suppress_prefixlength 0

У тебя 192.168.23.0/24 нет в main? А почему? Это может быть причиной неработоспособности правил в nat/preroute

vel ★★★★★
(13.11.22 23:12:32 MSK)

Ответ на: комментарий от vel 13.11.22 23:12:32 MSK

Так точно, 192.168.23.0/24 нет в main

#ip route show table main
default via 192.168.3.1 dev eth0 proto dhcp src 192.168.3.5 metric 100 
192.168.3.0/24 dev eth0 proto kernel scope link src 192.168.3.5 
192.168.3.1 dev eth0 proto dhcp scope link src 192.168.3.5 metric 100 
172.16.0.110 dev qrtun proto kernel scope link src 172.16.0.111

Почему? Потому что этот сервер виртуалка в клауде. Это видно из первого поста - когда туннель поднимается через серый адрес 192.168.3.5. У виртуалки один интерфейс eth0 и белый адрес к нему прибит «провайдером». И сущности сеть/подсеть несут чуть другое значение. Все маршрутизируется через вирт. маршрутизатор с ип 192.168.3.1. Это не мой выбор - это данность. Можно сделать кучу подсетей и все натить в инет через единственную машину 192.168.3.5. Вот подсеть 192.168.23.0/24 - одна из таких подсетей. Тем не менее - еще раз повторюсь. Проблемы с пробросом портов в обычных условиях нет. Если сделать правило:

iptables -t nat -A PREROUTING -p tcp –dport 80 -j DNAT –to-destination 192.168.23.10:80

и прийти на белый ИП граничной машины, то пакеты нормально приземляться на 192.168.23.10. Но пакеты приходящие через туннель мне так приземлить не удается. Я даже не вижу тспдумпом, что они приходят на 192.168.23.10. О возвращении их в туннель пока речи не идет.

alex-123 ★
(13.11.22 23:51:44 MSK) автор топика

Ответ на: комментарий от alex-123 13.11.22 23:51:44 MSK

К слову сказать, пакеты на правило PREROUTING залетают:

Chain PREROUTING (policy ACCEPT 49 packets, 2860 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        5   300 DNAT       tcp  --  qrtun  *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80 to:192.168.23.10:80

Это после очистки счетчиков. Очевидно ядро после этого правила не понимает куда кидать пакеты

alex-123 ★
(14.11.22 01:40:14 MSK) автор топика

Ответ на: комментарий от alex-123 14.11.22 01:40:14 MSK

В качестве эксперимента поднял рядом виртуалку 192.168.3.6. На ней нжинкс. Порт 80 слушается. Запись о 192.168.3.0/24 есть в таблице майн:

192.168.3.0/24 dev eth0 proto kernel scope link src 192.168.3.5

Пытаюсь прероутингом кинуть пакеты на 192.168.3.6 - ноль на массу. Пакеты в правило залетают и далее нифига.

Также мечу пакеты на входе:

iptables -t mangle -A PREROUTING -p tcp -i qrtun --dport 80 -j MARK --set-mark 0x1

Добавляю правило:

ip rule add fwmark 0x1/0x1 lookup main

Также без результата.

Этот результат может быть следствием использования туннеля ГРЕ?

alex-123 ★
(14.11.22 02:16:48 MSK) автор топика

Ссылка

Ответ на: комментарий от alex-123 14.11.22 01:40:14 MSK

Если вы такой умный, что знаете про счётчики, :) то поставьте первым в остальные цепочки, в том числе в filter/FORWARD, правила счётчики (без цели) и смотрите, идут ли эти пакеты дальше по цепочкам. Или включайте в iptaable трассировку для этих пакетов.

mky ★★★★★
(14.11.22 06:31:46 MSK)

Ответ на: комментарий от mky 14.11.22 06:31:46 MSK

Это все уже было давно сделано - в форвард не попадает вообще. Т.е. не выбирается нужный/доступный/разрешенный роут. Хоть что-то начинает двигаться если сделать вот что: сделать тестовую таблицу и направить трафик весь с интерфейса гре

210:    from all iif qrtun lookup testtable

в таблице сделать что-то вроде

ip route add default via qrtun table testtable

# ip route show table testtable
default via 172.16.0.111 dev qrtun

Трафик попадает в форвард и по ходу выбрасывается обратно в qrtun. Направить трафик во внутреннюю подсеть так и не получается.

alex-123 ★
(14.11.22 10:02:10 MSK) автор топика

Ответ на: комментарий от alex-123 13.11.22 23:51:44 MSK

Я тебе говорил про асимметричный роутиниг, что он не совместим с NAT?

Обеспечь прохождение ответных пакетов через твой роутер. Как это сделать (SNAT или настройка маршрутизации в локальной сети) - это тебе решать.

vel ★★★★★
(14.11.22 11:00:27 MSK)

Ответ на: комментарий от vel 14.11.22 11:00:27 MSK

Погодите, давайте разберемся. О каких ответных пакетах речь, если до цели пакеты не доходят? Нет на интерфейсе целевой машины 192.168.23.10 никаких пакетов со стороны маршрутизатора 192.168.3.5. Мне и надо хотя бы выбросить их в подсеть.

172.16.0.110 —> Туннель –> 172.16.0.111 (qrtun) —> eth0 —> внутренняя подсеть

alex-123 ★
(14.11.22 12:37:48 MSK) автор топика

Какая дичь… удали к уям всю эту херню. Все что тебе надо это -A POSTROUTING -o eth0 -j SNAT –to-source <eth0_ip>. Какие-то pbrы mark lookupы dnatы, что за каша в голове.

Anoxemian ★★★★★
(14.11.22 16:45:45 MSK)

Ответ на: комментарий от alex-123 14.11.22 12:37:48 MSK

172.16.0.110 —> Туннель –> 172.16.0.111 (qrtun) —> eth0 —> внутренняя подсеть

Ага, и 192.168.23.0/24 во внутреннюю сеть через шлюз по умолчанию. Охрененное уточнение....

Если ответ из внутренней сети не возвращается на eth0, то не видать тебе удачи.

У тебя 2 пути: либо сделать snat на все что с 172.16.0.110 попадает во внутреннюю сеть через eth0, либо во внутренней сети сделать маршрут до 172.16.0.110.

vel ★★★★★
(14.11.22 16:47:35 MSK)

Ссылка

Ответ на: комментарий от Anoxemian 14.11.22 16:45:45 MSK

Какая каша? Вы почитайте задачу хотя бы. Поразмыслите малехо. Мне нужно пробросить 2 порта внутрь сети? Зачем мне маскировать трафик? А в логах веб сервера вы что увидите? все приходит 172.16.0.111? Этого не надо. Приходит трафик из инета падает на просто на eth0. Стоит правило

iptables -t nat -A PREROUTING -p tcp -i eth0 –dport 80 -j DNAT –to-destination 192.168.23.10:80

В итоге мы великолепно попадаем на веб-сервер 192.168.23.10.

Аналогичное правило для туннеля и мы НЕ попадаем на 192.168.23.10. Мне не понятно почему при включенной маршрутизации с одного интерфейса машины пакет не попадает на другой и не уходит во внутреннюю подсеть хотя все предпосылки к этому есть.

alex-123 ★
(14.11.22 16:58:18 MSK) автор топика

Ответ на: комментарий от alex-123 14.11.22 16:58:18 MSK

потому что твой сервис внутренней сети нефейхуя не знает о твоем гре-туннеле, блэт.

UPD. 172.16.0. немаршрутизируемое адресное пространство.

UPD2. ну а про логи и один ip это просто интеллектуальная катастрофа.

Anoxemian ★★★★★
(14.11.22 17:02:52 MSK)
Последнее исправление: Anoxemian 14.11.22 17:09:23 MSK (всего исправлений: 1)

Ответ на: комментарий от alex-123 14.11.22 16:58:18 MSK

еще раз. удали все. тебе нужно 1 snat и все

Anoxemian ★★★★★
(14.11.22 17:03:36 MSK)

Ссылка

Ответ на: комментарий от Anoxemian 14.11.22 17:02:52 MSK

UPD. 172.16.0. немаршрутизируемое адресное пространство.

У вас что - обострение? Немаршрутизируемое в сети Интернет по рфк 1918. Внутри себя - маршрутизируй как хочешь. Откройте любой букварь по циске - половина примеров из этого пространства.

alex-123 ★
(14.11.22 17:33:35 MSK) автор топика

Ответ на: комментарий от alex-123 14.11.22 17:33:35 MSK

Хорошо, попробуем с другой стороны. Что 192.168.23.10 знает о 172.16.0.111? Как там, пинги ходят, все норм?

Anoxemian ★★★★★
(14.11.22 18:01:32 MSK)

Ссылка

Ответ на: комментарий от alex-123 14.11.22 10:02:10 MSK

в форвард не попадает вообще.

А куда попадает? В mangel/FORWARD или mangel/INPUT?

rp_filter отключен?

mky ★★★★★
(15.11.22 05:23:46 MSK)

Ответ на: комментарий от mky 15.11.22 05:23:46 MSK

Писал выше - по данным трассировки не попадает никуда.

Это пример проблемного проброса из туннеля. Видно, что все оставливается на прероуте.

Nov 15 01:40:33 proxy01 kernel: [10790817.786422] TRACE: raw:PREROUTING:policy:2 IN=qrtun OUT= MAC= SRC=109.х.х.х DST=172.16.0.111 LEN=60 ... 
Nov 15 01:40:33 proxy01 kernel: [10790817.786455] TRACE: mangle:PREROUTING:rule:1 IN=qrtun OUT= MAC= SRC=109.х.х.х  DST=172.16.0.111 LEN=60 ....
Nov 15 01:40:33 proxy01 kernel: [10790817.786461] TRACE: mangle:PREROUTING:policy:2 IN=qrtun OUT= MAC= SRC=109.х.х.х DST=172.16.0.11 LEN=60 ... MARK=0x1 
Nov 15 01:40:33 proxy01 kernel: [10790817.786467] TRACE: nat:PREROUTING:rule:1 IN=qrtun OUT= MAC= SRC=109.х.х.х DST=172.16.0.111 LEN=60 ... MARK=0x1

Как видно нет перехода в форвард. И нет подмены адреса назначения. Я считаю, что это свойство поднятого туннеля. Надо копаться в настройках гре.

А это пример успешного проброса, если пакеты приходят на интерфейс eth0

Nov 15 01:58:38 proxy01 kernel: [10791903.208946] TRACE: raw:PREROUTING:policy:2 IN=eth0 OUT= MAC=d0:0d:16:08:31:75:00:00:5e:00:01:00:08:00 SRC=109.х.х.х DST=192.168.3.5 LEN=60 ....
Nov 15 01:58:38 proxy01 kernel: [10791903.208982] TRACE: mangle:PREROUTING:policy:2 IN=eth0 OUT= MAC=d0:0d:16:08:31:75:00:00:5e:00:01:00:08:00 SRC=109..х.х.х DST=192.168.3.5 LEN=60 ....
Nov 15 01:58:38 proxy01 kernel: [10791903.208990] TRACE: nat:PREROUTING:rule:5 IN=eth0 OUT= MAC=d0:0d:16:08:31:75:00:00:5e:00:01:00:08:00 SRC=109.х.х.х DST=192.168.3.5 LEN=60 .... 
Nov 15 01:58:38 proxy01 kernel: [10791903.209017] TRACE: mangle:FORWARD:policy:1 IN=eth0 OUT=eth0 MAC=d0:0d:16:08:31:75:00:00:5e:00:01:00:08:00 SRC=109.х.х.х DST=192.168.23.10 LEN=60

alex-123 ★
(16.11.22 12:05:19 MSK) автор топика

Ответ на: комментарий от alex-123 16.11.22 12:05:19 MSK

Почему на вопрос про rp_filter ответа нет?

mky ★★★★★
(16.11.22 20:16:56 MSK)

Сделай проброс всего GRE.

call-monster
(16.11.22 22:08:43 MSK)

Ответ на: комментарий от mky 16.11.22 20:16:56 MSK

Почему на вопрос про rp_filter ответа нет?

Потому что это чушь. rp_filter это история про возврат пакетов. В любом случае пробовал выставлять в 0 и для eth0 и для qrtun - ноль на массу и эффекта 0.

alex-123 ★
(17.11.22 01:00:32 MSK) автор топика