LINUX.ORG.RU

История изменений

Исправление aidaho, (текущая версия) :

счётчики

Даже не знал, что они есть.

Да, на сервере iptables -I FORWARD -i eth0 -o $INTERFACE -j ACCEPT имеет нулевое значение, в то время как iptables -I FORWARD -i $INTERFACE -o eth0 -j ACCEPT — ненулевое.

Если на сервере сделать дамп пакетов на VPN-интерфейсе, будут пакеты от 178.248.233.6

Сделал, таких нет. Только пришедшие от клиента на 178.248.233.6.

Может на сервере нет маршрута к клиенту через VPN-интерфейс

Есть. Маршрут поднимает сам Tinc. Когда на клиенте активированы правила iproute для форвардинга, сервер по-прежнему остаётся доступен именно через VPN-интерфейс.

ваша маркировка пакетов срабатывает на идущие к клиенту пакеты и отправляет их в неправильный интерфейс

Маркировка точно должна срабатывать и на сервере, поскольку соответствующие правила входят в стартовый скрипт tinc'а.
Цепочка правил маркировки применяется так:

iptables -t mangle -A OUTPUT -j vpn-router  # outgoing packets
iptables -t mangle -A PREROUTING -j vpn-router  # incoming packets

Не знаю правда, зачем маркирую в PREROUTING, по-моему это лишнее.
Суть в том, что маркировка сама по себе ничего не делает, пока на сервере нет соответствующих правил iproute, никаких дополнительных эффектов от этого быть не должно.

Кстати, fwmark помечает пакеты просто в сетевом стеке машины или модифицирует сами пакеты?


В общем, из снятых дампов и счётчиков мне вполне понятно что происходит:


[1] После включения правил iproute траффик с клиента успешно заворачивается в VPN-интерфейс и идёт на адрес сервера
[1] Сервер успешно пересылает пакеты с подменой адреса источника в пункт назначения
[2] Сервер успешно получает ответ от пункта назначения и на этом хорошие новости заканчиваются
[3] Клиент не получает ответа от пункта назначания через сервер в установленный срок и перепосылает пакет, который мы видим как «TCP Spurious Retransmission»
[4] Пункт назначания получает перепосланный пакет и отвечает опять идентичным, мы видим «TCP Retransmission»

Не попадают пакеты принятые на eth0 сервера на vpn интерфейс. Почему — не понятно, и куда смотреть не понятно тоже.

Возможно есть инструменты для отсылки и отслеживания прохождения через сетевой стек пакетов с заданными свойствами?

Исходная версия aidaho, :

счётчики

Даже не знал, что они есть.

Да, на сервере iptables -I FORWARD -i eth0 -o $INTERFACE -j ACCEPT имеет нулевое значение, в то время как iptables -I FORWARD -i $INTERFACE -o eth0 -j ACCEPT — ненулевое.

Если на сервере сделать дамп пакетов на VPN-интерфейсе, будут пакеты от 178.248.233.6

Сделал, таких нет. Только пришедшие от клиента на 178.248.233.6.

Может на сервере нет маршрута к клиенту через VPN-интерфейс

Есть. Маршрут поднимает сам Tinc, когда на клиенте активированы правила iproute для форвардинга, сервер по-прежнему остаётся доступен именно через VPN-интерфейс.

ваша маркировка пакетов срабатывает на идущие к клиенту пакеты и отправляет их в неправильный интерфейс

Маркировка точно должна срабатывать и на сервере, поскольку соответствующие правила входят в стартовый скрипт tinc'а.
Цепочка правил маркировки применяется так:

iptables -t mangle -A OUTPUT -j vpn-router  # outgoing packets
iptables -t mangle -A PREROUTING -j vpn-router  # incoming packets

Не знаю правда, зачем маркирую в PREROUTING, по-моему это лишнее.
Суть в том, что маркировка сама по себе ничего не делает, пока на сервере нет соответствующих правил iproute, никаких дополнительных эффектов от этого быть не должно.

Кстати, fwmark помечает пакеты просто в сетевом стеке машины или модифицирует сами пакеты?


В общем, из снятых дампов и счётчиков мне вполне понятно что происходит:


[1] После включения правил iproute траффик с клиента успешно заворачивается в VPN-интерфейс и идёт на адрес сервера
[1] Сервер успешно пересылает пакеты с подменой адреса источника в пункт назначения
[2] Сервер успешно получает ответ от пункта назначения и на этом хорошие новости заканчиваются
[3] Клиент не получает ответа от пункта назначания через сервер в установленный срок и перепосылает пакет, который мы видим как «TCP Spurious Retransmission»
[4] Пункт назначания получает перепосланный пакет и отвечает опять идентичным, мы видим «TCP Retransmission»

Не попадают пакеты принятые на eth0 сервера на vpn интерфейс. Почему — не понятно, и куда смотреть не понятно тоже.

Возможно есть инструменты для отсылки и отслеживания прохождения через сетевой стек пакетов с заданными свойствами?