Сервер с tun интерфейсом в одной подсети с хостами. Не удается настроить NAT.

[alexgamber]

Помогите пожалуйста решить задачку.

Дано: LAN (192.168.102.0/24, GW: 192.168.102.1), внутри которой отдельный сервер на Debian (192.168.102.6), на котором поднят tun интерфейс (172.16.0.1/24) до зарубежного VPS, для Debian этот tun является default route (условный curl 2ip.ru отдает IP VPS).
Маршрутизатор получает список подсетей по BGP, которые необходимо завернуть на данный tun интерфейс для всех хостов в LAN, остальные пустить на шлюз RU провайдера.

Ранее, когда сервер с туннелем располагался не в одной сети с остальными хостами, у меня проблем с такой задачей не возникало. Пробрасывал до сервера GRE или WG туннель, на маршрутизаторе прописывал masquerade для этого GRE/WG интерфейса, в filter rule для BGP указывал в качестве шлюза IP GRE/WG интерфейса на стороне сервера. Все работало.

Здесь попробовал проделать подобное, поднял GRE туннель до сервера внутри LAN и также настроил для GRE на маршрутизаторе NAT. Вначале все работает, условный 2ip на любом хосте в LAN отдает зарубежный IP, но стоит открыть еще пару тройку сайтов, как это NAT правило начинает генерировать огромное количество соединений и трафика, по итогу все заканчивается падением tun интерфейса на сервере (sing-box клиент уходит в 100% загрузку).

Понимаю, что допускаю какую-то глупую ошибку, но как именно ее поправить пока понять не могу. Буду признателен за любую подсказку или помощь.

[gmx]

Схема связи не совсем понятна со слов. И не совсем понятна проблема.
Само по себе правило nat не может ничего генерировать. Искать надо петлю в сети, в первую очередь.

[alexgamber]

Постараюсь детальнее (адресация на схеме).



Есть две локальных сети (филиала) соединенных друг с другом Wireguard туннелем.
На маршрутизаторах с обеих сторон прописаны маршруты в локальные сети каждого филиала.

Филиал 1 получает от провайдера "серый" IP, Филиал 2 - публичная статика.
В Филиал 2 размещен Debian сервер c клиентом sing-box, средствами которого строится туннель до зарубежного VPS.
На сервере создана отдельная таблица маршрутизации для tun интерфейса sing-box, где он является шлюзом по умолчанию.
На эту таблицу завернуты подсети GRE туннеля с Филиал 1 и DHCP пул для ПК в Филиал 2.

ip rule:

Код: Выделить всё

0:      from all lookup local
32764:  from 192.168.102.16/28 lookup sing-rt
32765:  from 192.168.22.0/24 lookup sing-rt
32766:  from all lookup main
32767:  from all lookup default

ip route:

Код: Выделить всё

default via 192.168.102.1 dev ens18 onlink
172.16.0.0/30 dev tun1 proto kernel scope link src 172.16.0.1
192.168.22.0/24 dev gre101 proto kernel scope link src 192.168.22.1
192.168.102.0/24 dev ens18 proto kernel scope link src 192.168.102.6

iptables пустой, только NAT на tun:

Код: Выделить всё

-A POSTROUTING -o tun1 -j MASQUERADE

Филиал 1 подключается напрямую к этому серверу через GRE туннель (внутри WG туннеля), на маршрутизаторе этого филиала для GRE интерфейса настроен маскарадинг. В этом филиале все работает адекватно. Условно, добавляем маршрут до 2ip.ru через 192.168.22.1, ресурс отдает IP NL VPS, все открывается быстро.

Tracert этого филиала:

Код: Выделить всё

Трассировка маршрута к 2ip.ru [195.201.201.32]
с максимальным числом прыжков 30:
  1    <1 мс    <1 мс    <1 мс  router.lan [192.168.101.1]
  2     2 мс     2 мс     2 мс  192.168.22.1
  3     *        *        *     Превышен интервал ожидания для запроса.
  4     *        *        *     Превышен интервал ожидания для запроса.
  5     2 мс     2 мс     2 мс  2ip.ru [195.201.201.32]

Проблемы начинаются в Филиал 2.
На данный момент отказался тут от GRE (как в Филиал 1), следовательно нет и NAT правил для GRE интерфейса на маршрутизаторе.

На маршрутизаторе этого филиала, для того же 2ip.ru я прописываю маршрут сразу через шлюз 192.168.102.6. С ПК, в локальной сети этого филиала, ресурс открывается, отдает IP зарубежного VPS, но открытие ресурса происходит с задержкой секунд в 5-7 и так с любым другим сайтом, который идет по этому маршруту. Через шлюз провайдера эти же ресурсы работают адекватно.
Более того, если в настройках сетевого адаптера на ПК я заменяю адрес шлюза с 192.168.102.1 на 192.168.102.6, все так же начинает работать хорошо и быстро, но тут уже весь трафик, само-собой, идет через зарубежный VPS.

Tracert (шлюз на сетевом адаптере ПК - 192.168.102.1):

Код: Выделить всё

Трассировка маршрута к 2ip.ru [195.201.201.32]
с максимальным числом прыжков 30:
  1    <1 мс    <1 мс    <1 мс  [192.168.102.1]
  2    <1 мс    <1 мс    <1 мс  [192.168.102.6]
  3     *        *        *     Превышен интервал ожидания для запроса.
  4     <1 мс     <1 мс     <1 мс  2ip.ru [195.201.201.32]

Tracert (шлюз на сетевом адаптере ПК - 192.168.102.6):

Код: Выделить всё

Трассировка маршрута к 2ip.ru [195.201.201.32]
с максимальным числом прыжков 30:
  1    <1 мс    <1 мс    <1 мс  [192.168.102.6]
  2     *        *        *     Превышен интервал ожидания для запроса.
  3     <1 мс     <1 мс     <1 мс  2ip.ru [195.201.201.32]

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

[alexgamber]

Отдельно допишу.
Правила на маршрутизаторе в Филиал 2.

Filter:

Код: Выделить всё

 0    ;;; defconf: accept established,related,untracked
      chain=input action=accept connection-state=established,related,untracked 
      
 1    ;;; defconf: drop invalid
      chain=input action=drop connection-state=invalid log=no log-prefix="" 
      
 2    ;;; defconf: accept to local loopback (for CAPsMAN)
      chain=input action=accept dst-address=127.0.0.1 log=no log-prefix="" 
      
 3    ;;; accept connections to Wireguard server
      chain=input action=accept protocol=udp in-interface-list=WAN dst-port=27492 log=no log-prefix="" 
      
 4    ;;; accept connections from OVPN
      chain=input action=accept in-interface=ovpn-inferno log=no log-prefix="" 
      
 5    ;;; accept connections from and through Wireguard
      chain=input action=accept in-interface=wg-sirius log=no log-prefix="" 
      
 6    chain=forward action=accept src-address=192.168.21.0/24 dst-address=10.0.0.0/8 in-interface=wg-sirius log=no log-prefix="" 
 
 7    chain=forward action=accept src-address=192.168.21.0/24 dst-address=192.168.21.0/24 in-interface=wg-sirius log=no log-prefix="" 
 
 8    chain=forward action=accept src-address=192.168.21.0/24 dst-address=192.168.105.0/24 in-interface=wg-sirius log=no log-prefix="" 
 
 9    chain=forward action=accept src-address=192.168.21.0/24 dst-address=192.168.102.0/24 in-interface=wg-sirius log=no log-prefix="" 
 
10    chain=forward action=accept src-address=192.168.21.0/24 dst-address=192.168.101.0/24 in-interface=wg-sirius log=no log-prefix="" 

11    chain=forward action=accept src-address=192.168.21.0/24 dst-address=192.168.103.0/24 in-interface=wg-sirius log=no log-prefix="" 

12    chain=forward action=accept src-address=192.168.21.0/24 dst-address=192.168.104.0/24 in-interface=wg-sirius log=no log-prefix="" 

13    ;;; defconf: drop all not coming from LAN
      chain=input action=drop in-interface-list=!LAN log=no log-prefix="" 
      
14    ;;; defconf: accept in ipsec policy
      chain=forward action=accept log=no log-prefix="" ipsec-policy=in,ipsec 
      
15    ;;; defconf: accept out ipsec policy
      chain=forward action=accept ipsec-policy=out,ipsec 
      
16    ;;; defconf: accept established,related, untracked
      chain=forward action=accept connection-state=established,related,untracked 
      
17    ;;; defconf: drop invalid
      chain=forward action=drop connection-state=invalid log=no log-prefix="" 
      
18    ;;; deny access to Internet through Wireguard
      chain=forward action=drop in-interface=wg-sirius log=no log-prefix="" 
      
19    ;;; defconf:  drop all from WAN not DSTNATed
      chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN log=no log-prefix="" 

NAT:

Код: Выделить всё

 0    ;;; defconf: masquerade
      chain=srcnat action=masquerade out-interface-list=WAN ipsec-policy=out,none 
      
 1    chain=srcnat action=masquerade out-interface=all-ppp log=no log-prefix="" 
 
 2    chain=srcnat action=masquerade out-interface=wg-sirius log=no log-prefix="" 

Mangle:

Код: Выделить всё

 0    chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=yes tcp-flags=syn protocol=tcp log=no log-prefix="" 

UPD:
Поправил

Код: Выделить всё

17    ;;; defconf: drop invalid
      chain=forward action=drop connection-state=invalid src-address=!192.168.102.16/28 log=no log-prefix="" 

Заработало нормально. Теперь бы понять, почему маршрут до 192.168.102.6 попадает в Invalid.