Хочу ходить на некоторые внешние ресурсы через туннель [SOLVED]

[GreatFoolDad]

Всем желаю доброго здравия и силы духа.
Мне что-то последнее совсем отказывает - неделю бьюсь...

Итак:
есть локалка - 192.168.1.0/24 с шлюзом 192.168.1.1 (некий роутер, не сервер)
все естественно работает
на внутреннем хосте 192.168.1.148 (Ubuntu сервер 22.04) поднимаю впн (openconnect) на реальный адрес 1.1.1.1 - там роутер с OpenWRT
при этом весь траффик хоста 192.168.1.148 ходит в инет через 1.1.1.1 - поднимается интерфейс tun0 c адресацией 192.168.193.0/24
у хоста (192.168.1.148) при этом адрес 192.168.193.100, у роутера соответственно 192.168.193.1
тут вопросов нет, тоже все работает
есть адрес 2.2.2.2 (некий ресурс, который к нашему офису отношения не имеет, например, это сайт компании MS), на который ВЕСЬ ОФИС (192.168.1.0/24) должен ходить через 1.1.1.1
на все остальные адреса офис ходит через обычный шлюз (192.168.1.1).

А вот теперь вопрос, который  не могу решить неделю...
Как завернуть трафик офиса (192.168.1.0/24) в этот самый Tun0 сервера (192.168.1.148)?
Чтобы весь офис не трогать, я взял одну машину (192.168.1.9) и на ней ставлю опыты.

Итак:
на сервере (192.168.1.148) поднят ВПН

Код: [Выделить]

x# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 1a:29:69:50:fa:48 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.148/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::f819:e9ff:fe59:af48/64 scope link
       valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1434 qdisc fq state UNKNOWN group default qlen 500
    link/none
    inet 192.168.193.220/32 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::5a1e:618c:3067:b341/64 scope link stable-privacy
       valid_lft forever preferred_lft forever
x# ip r
default dev tun0 scope link
1.1.1.1 via 192.168.1.1 dev eth0 src 192.168.1.148
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.148
192.168.193.0/24 dev tun0 scope link
x# traceroute 2.2.2.2
traceroute to 2.2.2.2 (2.2.2.2), 64 hops max
  1   192.168.193.1  57.876ms  54.702ms  54.613ms
  2   1.1.1.2  60.110ms  61.155ms  54.659ms (это шлюз подключения роутера с OpenWRT)
  3   10.10.13.141  58.027ms  59.635ms  60.951ms
...
  7   2.2.2.2  75.710ms  75.648ms  73.530ms (это нормальный правильный сервер)все работает

роутер знает, что трафик от 192.168.1.9 к 2.2.2.2 надо перенаправлять на 192.168.1.148
вид с клиентской машины (192.168.1.9)

Код: [Выделить]

C:\Users\User\tracert -d 2.2.2.2
1   <1 ms      <1 ms     <1 ms      192.168.1.1
2   <1 ms      <1 ms     <1 ms      192.168.1.148
3     *               *             *           Request timed out.
4     *               *             *           Request timed out.
5     *               *             *           Request timed out.
...   
То есть, шлюз (192.168.1.1) свою задачу выполнил - трафик переслал на 192.168.1.148

тут была куча ненужного текста

Почему трафик не идет дальше 1.1.1.1?

Пользователь добавил сообщение 26 Января 2024, 09:07:03:Сам спросил - мне и отвечать

Ну что, всего-то выспался, и голова заработала, и туннель заработал

Для начала открыл https://ubuntu.com/server/docs/security-firewall раздел "ufw Masquerading"
Собственно, страницы дальше по тексту хватило для того, что бы все заработало.
Итого:
файл /etc/default/ufw change the DEFAULT_FORWARD_POLICY to “ACCEPT”:

Код: [Выделить]

DEFAULT_FORWARD_POLICY="ACCEPT"далее выполнил 3 команды:

Код: [Выделить]

# ufw route allow in on eth0 out on tun0
# ufw route allow in on tun0 out on eth0
# ufw allow in on eth0 from 192.168.1.0/24что добавило в файл /etc/ufw/user.rules перед "### END RULES ###" строки

Код: [Выделить]

...
### tuple ### route:allow any any 0.0.0.0/0 any 0.0.0.0/0 in_eth0!out_tun0
-A ufw-user-forward -i eth0 -o tun0 -j ACCEPT

### tuple ### route:allow any any 0.0.0.0/0 any 0.0.0.0/0 in_tun0!out_eth0
-A ufw-user-forward -i tun0 -o eth0 -j ACCEPT

### tuple ### allow any any 0.0.0.0/0 any 192.168.1.0/24 in_eth0
-A ufw-user-input -i eth0 -s 192.168.1.0/24 -j ACCEPT

### END RULES ###и в файл /etc/ufw/before.rules добавил в конец:

Код: [Выделить]

# nat Table rules
*nat
:POSTROUTING ACCEPT [0:0]

# Forward traffic from eth1 through eth0.
-A POSTROUTING -s 192.168.1.0/24 -o tun0 -j MASQUERADE

# don't delete the 'COMMIT' line or these nat table rules won't be processed
COMMIT
Теперь осталось либо самому сделать, либо найти скрипт, который будет проверять наличие туннеля, при его отсутствии перезапускать клиента N раз, при неуспехе переводить весь трафик до адреса 2.2.2.2 на основной маршрут (хм... а там на роутере, который основной шлюз, прописано правило, что весь трафик для 2.2.2.2 слать на роутер с туннелем (а туннеля нет)... надо подумать, как эту ситуацию разрулить)

Upd

хм... а там на роутере, который основной шлюз, прописано правило, что весь трафик для 2.2.2.2 слать на роутер с туннелем (а туннеля нет)... надо подумать, как эту ситуацию разрулить

Думаю что правило на роутере, который основной шлюз, надо изменить на "весь трафик для 2.2.2.2, КРОМЕ ТОГО, ЧТО ПРИШЕЛ С 192.168.1.148, перенаправлять на 192.168.1.148". Вот тогда, по идее, трафик по-любому уйдет, либо через туннель, когда он есть, либо через основной шлюз, когда туннеля нет.