Проблема с маршрутизацией трафика

[Measurer]

Ситуация:
1. User_P - микротик с выходом в инет
2. Server_M - сервер, Ubuntu. Интернет через eth0. WireGuard сервер и wireguard клиент.
3. Server_N - сервер Ubuntu. Интернет через eth0. WireGuard сервер.



Задача: выпустить User_P в интернет через Server_N. Но при этом, сервер Server_M должен быть доступен через интернет со всеми сервисами.

На серввере Server_N wireguard сервер, NAT и всё прочее настроено и работает. Если к нему подключиться клиентом, то трафик в интернет ходит.

Весь затык в сервере Server_M.
Что делаю.
- маршрутизация настроена, все всех по адресам в тоннелях видят.
- создаю дополнительную таблицы маршрутизации

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

echo "400 table2"  >> /etc/iproute2/rt_tables- добавляю в неё маршруты

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

ip route add 10.66.67.0/24 dev wg0 table table2
ip route add 10.66.66.0/24 dev awg1 table table2
ip route add default via 10.66.66.1 dev awg1 table table2- создаю route rule

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

ip rule add from all fwmark 2 table table2- файервол

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

iptables -t mangle -A PREROUTING -i wg0 -s 10.66.67.3 -j MARK --set-mark 2- отключаю rpf

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

for i in /proc/sys/net/ipv4/conf/*/rp_filter ; do
  echo 0 > $i
done
На микротике Client_P запускаю

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

ping 8.8.8.8
Получаю:

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

309 10.66.67.1                                 84  64 26ms402us  host unreac...
Запускаю tcpdump на Server_M и интерфейсе wg0. Вижу:

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

18:23:34.468372 IP 10.66.67.3 > dns.google: ICMP echo request, id 4717, seq 27, length 36
18:23:34.468408 IP server_m > 10.66.67.3: ICMP host dns.google unreachable, length 64
Запускаю tcpdump на этом же сервере и интерфейсе awg1. Вижу:

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

18:24:18.559560 IP 10.66.67.3 > dns.google: ICMP echo request, id 4717, seq 71, length 36
18:24:19.562525 IP 10.66.67.3 > dns.google: ICMP echo request, id 4717, seq 72, length 36
Запускаю tcpdump на Server_N и интерфейсе awg0. Тишина...

При этом, пинги с сервера Server_M на Server_N и в обратную сторону ходят.

Пинги с Client_P на сервер Server_N тоже ходят

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

   3 10.66.66.1                                 56  63 67ms583us

ЧЯДНТ?

[ALiEN]

server_M

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

iptables -A POSTROUTING -s 10.66.67.3 -o awg1 -j SNAT --to-source 10.66.66.2

[Measurer]

Тогда, у меня сервер будет натить трафик. Мне этого не нужно.
Пользователь добавил сообщение 10 Декабря 2024, 19:10:11:Люди, вроде, решали подобные задачи без NAT
https://www.linux.org.ru/forum/admin/11115910
https://www.kryukov.biz/2008/11/open-vpn-i-hitryj-routing/

У меня никак не выходит.

[ALiEN]

Тогда, у меня сервер будет натить трафик. Мне этого не нужно.

И в чём проблема натить трафик?
Ну если сделаете без использования NAT - большая просьба опубликовать решение

Люди, вроде, решали подобные задачи без NAT

Да неужто? В первой ссылке у ТС в правилах уже есть MASQUERADE, во второй тоже явное указание прописать правило SNAT.

[Measurer]

Как минимум, по второй ссылке у человека скрипты без NAT. Пишет, что всё работает.

В моей ситуации я не понимаю несколько вещей:
1. Почему Server_M отвечает, что хост не доступен и тут же посылает пакет дальше? Он ведь явно не по таймауту отвечает судя по времени ответа.
2. Почему пакеты выходят в тоннель между Server_N и Server_M, но tcpdump на Server_N их не видит?

[ALiEN]

Как минимум, по второй ссылке у человека скрипты без NAT. Пишет, что всё работает.

С ЛОРа ссылка? Дык там у человека другая задача. А маскарад, видимо, прописан на постоянку.
По второй ссылке я скриптов не увидел.
И прекращайте верить тому, что написано в интернете. На заборе тоже написано.

1. Почему Server_M отвечает, что хост не доступен и тут же посылает пакет дальше? Он ведь явно не по таймауту отвечает судя по времени ответа.
2. Почему пакеты выходят в тоннель между Server_N и Server_M, но tcpdump на Server_N их не видит?

1. Куда дальше? Таймаут не показатель.
2. Потому что интерфейс awg0 server_N ничего не знаeт о сети 10.66.67.X.
Пакеты где IP_dst не соответствует 10.66.66.1 - предназначены не ему.

PS Маскарадинг

[Measurer]

С ЛОРа ссылка? Дык там у человека другая задача. А маскарад, видимо, прописан на постоянку.
По второй ссылке я скриптов не увидел.
И прекращайте верить тому, что написано в интернете. На заборе тоже написано.

Перепутал. Во второй ссылке скрипты.
В первой ссылке на сервере, названном "VPN клиент" ната нет. NAT только на втором сервере, который уже выпускает в интернет. Это и понятно.

Подобных статей я читал достаточно много. Везде примерно одинаково:
1. файерволом маркируем трафик
2. указываем route rule
Трафик идёт.

1. Куда дальше?

Ещё раз... На сервере Server_M, на интерфейсе awg1 запускаю tcpdump, чтобы посмотреть исходящие пакеты в сторону сервера Server_N. Исходящие пакеты есть.

2. Потому что интерфейс awg0 server_N ничего не знаeт о сети 10.66.67.X.

И ещё раз:
1. Server_N знает о подсети 10.66.67.0/24. Маршрут есть. Я писал, что по адресам тоннелей всё пингуется.
2. Если запустить tcpdump на сервере Server_N, на интерфейсе awg0 и пинговать с клиента ip 10.66.66.1, то я вижу трафик с IP клиента 10.66.67.3, и ответы на пинги есть. Если я с клиента буду пинговать 8.8.8.8, то то же самый tcpdump трафика не показывает. Хотя с обратной стороны тоннеля (с Server_M) трафик выходит.
3. Вы же понимаете, что если Server_M в ответ на пинг 8.8.8.8 отвечает unreachable, то даже если я наверну NAT, то ничего не изменится?
NAT работает на POSTROUTING, т.е. на ВЫХОДЕ трафика. А до туда явно ничего не доходит, т.к. Server_M по каким-то своим внутренним причинам решает, что 8.8.8.8 не доступен.

Пакеты где IP_dst не соответствует 10.66.66.1 - предназначены не ему.

Но у него есть своя таблица маршрутизации. Все пришедшие пакеты он будет обрабатывать в соответствии с ней, если не зарубит файервол.

[ALiEN]

server_N

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

ping 10.66.67.3?
Пользователь добавил сообщение 11 Декабря 2024, 01:03:06:

Server_M в ответ на пинг 8.8.8.8 отвечает unreachable

Да потому что 8.8.8.8 адресует ответ на внешний eth0, а не на 10.x.x.x. Естественно, unreachable.

NAT работает на POSTROUTING, т.е. на ВЫХОДЕ трафика.

Гуглите "цепочка iptables"

[Measurer]

server_N
Код: [Выделить]
ping 10.66.67.3
?

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

root@server_n:~/system_scripts/iptables# ping 10.66.67.3
PING 10.66.67.3 (10.66.67.3) 56(84) bytes of data.
64 bytes from 10.66.67.3: icmp_seq=1 ttl=63 time=159 ms
64 bytes from 10.66.67.3: icmp_seq=2 ttl=63 time=68.2 ms
64 bytes from 10.66.67.3: icmp_seq=3 ttl=63 time=68.3 ms
64 bytes from 10.66.67.3: icmp_seq=4 ttl=63 time=68.7 ms
mtr 10.66.67.3
                                                                                    My traceroute  [v0.95]

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

                                                                                    My traceroute  [v0.95]
                                        My traceroute  [v0.95]
server_n (10.66.66.1) -> 10.66.67.3 (10.66.67.3)                            2024-12-10T22:52:01+0000
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                              Packets               Pings
 Host                                                       Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 10.66.66.7                                               0.0%    81   42.5  60.3  40.9 1050. 118.6
 2. 10.66.67.3                                               0.0%    80   68.0  93.5  66.3 893.3 109.9


Да потому что 8.8.8.8 адресует ответ на внешний eth0, а не на 10.x.x.x. Естественно, unreachable.

Но ведь этот пакет на Server_M должен попасть во вторую таблицу маршрутизации и не уйти на внешний интерфейс.
А даже если бы ушёл, то пропал бы в инете, и этот сервер на отвечал бы через 25мс, а ждал бы таймаут.

Гуглите "цепочка iptables"

Ваша же цитата (кстати, немного неправильно. без указания таблицы не заработает)
iptables -A POSTROUTING -s 10.66.67.3 -o awg1 -j SNAT --to-source 10.66.66.2

[ALiEN]

Но ведь этот пакет на Server_M должен попасть во вторую таблицу маршрутизации и не уйти на внешний интерфейс.

Ну и как у вас обрабатываются входящие из 8.8.8.8? Никаких mark там нет и быть не может.

без указания таблицы не заработает

Да ошибочка. Копировал из своего iptables-save. -t nat пропустил.
Пользователь добавил сообщение 11 Декабря 2024, 02:20:19:

10.66.66.7

А это откуда? На вашей картинке нет такого IP

[Measurer]

А это откуда? На вашей картинке нет такого IP

Тааак... момент. Действительно. Надо посмотреть, что это?
Пользователь добавил сообщение 11 Декабря 2024, 14:58:55:В общем, сотрудники сменили IP. Сейчас не 10.66.66.2, а 10.66.66.7
Пользователь добавил сообщение 11 Декабря 2024, 20:22:40:И ещё один момент. Прошивка в том же самом микротике написана на основе ядра линукс. И эта фича вполне себе работает.
К тому же, там даже проще всё настраивается: в Routing rules указываешь с какого и на какой IP трафик маршрутизировать и по какой таблице маршрутизации. И всё.

[ALiEN]

К тому же, там даже проще всё настраивается: в Routing rules указываешь с какого и на какой IP трафик маршрутизировать и по какой таблице маршрутизации. И всё.

Залогиньтесь в ssh и подсмотрите его правила iptables. Почти уверен, что там найдете DNAT/SNAT)

[Measurer]

Да вашу мать... А ларчик просто открывался!
На сервере Server_M в конфиге интерфейса awg1 забыл прописать

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

AllowedIPs = 10.66.66.0/24,0.0.0.0/0
Было только

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

AllowedIPs = 10.66.66.0/24
Маршруты все были (в конфиге модифицированного WG было отключено изменение маршрутов), а вот разрешения посылать пакеты не было. Поэтому Server_M и отвечал Host unreachable

Всё работает!